www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - static initialization of structs

reply "Dan" <dbdavidson yahoo.com> writes:
In the thread on compiling DSSS and build tools someone mentioned 
a format for initializing environment data of a struct:

   Environment env = {
        tests: true,
        verbose: true,
        importDirs: ["../deimos"]
   }

A followup comment says "isn't that syntax intended to be 
deprecated?"

Is this accurate - that the nice json-esque syntax for 
initializing structs will be deprecated? If so, can someone give 
color on why/when?

Also, for this and other issues regarding features going away, is 
there a central place where these items are being tracked? How 
can we know what is on the chopping block?

Thanks
Dan
Dec 01 2012
next sibling parent "Rob T" <rob ucora.com> writes:
On Saturday, 1 December 2012 at 18:36:35 UTC, Dan wrote:
 In the thread on compiling DSSS and build tools someone 
 mentioned a format for initializing environment data of a 
 struct:

   Environment env = {
        tests: true,
        verbose: true,
        importDirs: ["../deimos"]
   }

 A followup comment says "isn't that syntax intended to be 
 deprecated?"

 Is this accurate - that the nice json-esque syntax for 
 initializing structs will be deprecated? If so, can someone 
 give color on why/when?

 Also, for this and other issues regarding features going away, 
 is there a central place where these items are being tracked? 
 How can we know what is on the chopping block?

 Thanks
 Dan

There's another thread very much related to your question, Breaking D2 language/spec changes with D1 being discontinued in a month http://forum.dlang.org/thread/svkdolzzcqotdmifcawh forum.dlang.org Which resulted in this effort D Stable Proposal http://forum.dlang.org/thread/k99coi$1q5e$1 digitalmars.com There's another thread concerning the way planned depreciations are handled by the compiler, but I'm not sure where that one is. Supposedly there's a pending pull request waiting to be approved by Walter. The change is intended to significantly improve how the compiler treats depreciations, making them much more meaningful and useful to the compiler user. --rt
Dec 01 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, December 01, 2012 19:36:34 Dan wrote:
 In the thread on compiling DSSS and build tools someone mentioned
 a format for initializing environment data of a struct:
 
    Environment env = {
         tests: true,
         verbose: true,
         importDirs: ["../deimos"]
    }
 
 A followup comment says "isn't that syntax intended to be
 deprecated?"
 
 Is this accurate - that the nice json-esque syntax for
 initializing structs will be deprecated? If so, can someone give
 color on why/when?
 
 Also, for this and other issues regarding features going away, is
 there a central place where these items are being tracked? How
 can we know what is on the chopping block?

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. - Jonathan M Davis
Dec 01 2012
prev sibling parent "Dan" <dbdavidson yahoo.com> writes:
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
Dec 01 2012