static initialization of structs

[Dan]

On Sunday, 2 December 2012 at 01:50:08 UTC, Jonathan M Davis 
wrote:
> On Saturday, December 01, 2012 19:36:34 Dan wrote:

> That syntax is from C. There was definitely a push to deprecate 
> it, and
> personally I definitely think that it should go, but I don't 
> recall that it was
> definitively decided that it would be removed. Certainly, it's 
> not particularly
> necessary, because if Environment doesn't declare a 
> constructor, you can
> already do the much more D-esque
>
> auto env = Environment(true, true, ["../deimos"]);
>
> Neither the C syntax nor that syntax work if Enviroment 
> declares a
> constructor.

Why do you think it should go and what was the reason behind its 
potential deprecation?

As others have pointed out, a nice effect is it is more robust in 
terms of changes in the fields of the struct. If there is no 
constructor and a field is added in the middle, existing client 
code can break silently. Or even changes in layout of the 
members. For example, here switching a member from public to 
private with the common convention of public goes at the top of 
the struct - would silently break the C syntax for existing 
static initializations:

Original:
    struct MyPersonalData {
      public int weightInPounds;
      public Date birthDate;
      public Date weddingDate;
      private int netWorth;
    }
Updated:
    struct MyPersonalData {
      public int weightInPounds;
      public Date weddingDate;
      private Date birthDate;
      private int netWorth;
    }

In this case the named parameter syntax prevents a subtle bug. Go 
has similar syntax support for composite literals and I believe 
they recommend the named field approach for this reason.

What is the best way to find out if this will or will not be 
deprecated? Is it just wait until Walter decides, or is there 
some voting process?

This kind of issue is important to know up front. If you knew the 
named field syntax were going away, you might provide all field 
initializing constructors just so the order is determined by 
function signature and not field placement in the struct.

Thanks
Dan