[RFC] struct field initialization and implicit constraints

[Jose E. Marchesi]

Hi people!

While writing Poke code I noticed something that is annoying, and I was
wondering how to best fix the annoyance :)

As you probably know, in struct type fields it is possible to use the
following construct to specify an initialization value:

  type Foo =
    struct
     {
        uint<16> magic = 0xfeef;
        [...]
     };

When constructing new values of type Foo, they will have the right magic
number:

  (poke) Foo {}
  Foo {
    magic=0xfeefUH
    [...]
  }

Also, the '= VALUE' construct also introduces an implicit constraint
'FIELD == VALUE'.  So if we try to map a Foo on some IO space and the
magic field is not 0xfeef, we get a constraint error.

If we specify _both_ an initialization value and an explicit constraint,
like in:

  type Foo =
    struct
     {
        uint<16> magic = 0xfeef : magic > 0;
        [...]
     };

Then there is no implicit constraint implied by the initialization
value.

I think this is problematic for two reasons:

1) When we desire to specify a default value for some struct field, but
   we don't want the resulting implicit constraint.  An example:

     type Collection =
       struct
       {
         Thing[] = [...default collection of things...];
         ...
       };

   We can use the following workaround in this case, which consists on
   adding an explicit constraint that always evaluates to `true' to
   inhibit the implicit constraint that would be introduced by the
   initialization value:

     type Collection =
       struct
       {
         Thing[] = [...default collection of things...] : 1;
         ...
       };

   This works well, but it is very ugly.

2) The semantics of `= VALUE' in this context vary depending whether an
   explicit constraint is also specified or not.  This can definitely be
   confusing to people.

So, how to fix this.

I see three possibilities:

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?