Re: [RFC] struct field initialization and implicit constraints

[Dan Čermák]

Hi Jose,

"Jose E. Marchesi" <jemarch@gnu.org> writes:

> Hi Dan.
>
>> I know I'm a bit late to the party since you already pushed the changes,
>> but here are my 2cts anyway ;-)
>
> Nah, until we release, we can always change it :)
> Thanks for the feedback.
>
>> "Jose E. Marchesi" <jemarch@gnu.org> writes:
>>
>>> a) Do nothing, and document the workaround in 1).
>>>
>>> b) Add a new syntax like `:= VALUE' to mean initialization-only, and
>>>    keep the current semantics of `= VALUE'.
>>>
>>> c) Change the semantics of `= VALUE' to mean initialization-only, and
>>>    add a new syntax like `== VALUE' to always mean
>>>    initialization-and-implicit-constraint.
>>>
>>>    In this case, using `== VALUE' would forbid to also specify an
>>>    explicit constraint, i.e. this would not be permitted:
>>>
>>>      type Foo =
>>>        struct
>>>        {
>>>           uint<16> magic == 0xfeef : magic > 0; /* error */
>>>           [...]
>>>        };
>>>
>>> My preference at this point is c).
>>> Opinions?
>>
>> I must admit that I do not like c) too much, as it looks like a
>> comparison to me. I'd suggest to use either b) or maybe add something
>> like a decorator?
>
> Well, it _is_ a comparison...  it implies both a comparison and an
> initialization.

Let me rephrase it: when I see:
val == 0xdeadbeef : val > 1

then I expect a boolean value to be the outcome of this line (not sure
how this should work out in practice) and not an initialization +
constraint.

I would suggest to let = always either imply a constraint or not and add
something like a decorator to switch the behavior, e.g.:

@no_implicit_constraint
uint<16> magic = [...default collection of things...] : magic % 2;


Not sure if this fits into the poke syntax at all though.


Cheers,

Dan

signature.asc
Description: PGP signature