DMD 1.014 release (struct literal syntax and keywords)

[Bill Baxter]

Jarrett Billingsley wrote:
> "Jarrett Billingsley" <kb3ctd2 at yahoo.com> wrote in message 
> news:f0svs3$1u13$1 at digitalmars.com...
>> Is there any ambiguity to the syntax:
>>
>> S s = S{a : 1, c : 3, b : 2};
>>
>> That is, just an Ident followed by a static struct initializer?
> 
> Do you have _any_ thoughts on this? 
> 
> 

I like your suggestion better.  Walter's way takes us back to the 
error-prone, fragile, mystery-meat way of constructing structs that they 
tossed out in C99.  Ok, not "tossed out" but "provided an alternative to."

Walter's way, however, gives you a way to transition from quick and 
dirty usage like
   struct Coord{ float x; float y; }
   func(Coord(xval,yval));
to something more complex via static opCall.  Say you realize you should 
have been using polar coordinates internally, then you can just add an 
opCall and some properties to do that:

   struct Coord{
     float r; float theta;
     float x() { return r*cos(theta); }
     float y() { return r*sin(theta); }
     static Coord opCall(float x, float y) {
          Coord it; with(it) {
            r = hypot(x,y);
            theta = atan2(y,x);
          }
          return it;
   }

   // This still works
   func(Coord(xval,yval));

Not extremely realistic, because if you have a polar coord struct 
probably you'll want the (float,float) opCall to take (r,theta) instead 
of (x,y), but well, the above is the best defense of Walter's approach I 
could come up with.

Keyword Arguments:

On the other hand, it would be potentially very cool if we could write 
member function to override the behavior of S s = S{a:1,c:3,b:2} as 
well.  But we need functions with keyword arguments for that to work.  I 
think we're not so far away.  If you treat a keyword function as 
functions of one anonymous struct then you're pretty much there.  For 
instance this:

    void a_keyword_func({int a=10, int b=4, int c=20}) {. . .}

    a_keyword_func(c:10, a:1);

could be treated as

    struct _S { int a=10; int b=4; int c=20; }
    a_keyword_func( _S ) { . . . }

    a_keyword_func( _S{c:10, a:1} );  //using your struct literals

Not sure what to do about out/inout/ref args.  That's the kicker I supposed.
But I think this approach to keyword args differs from the previous 
proposals by myself and others in that it makes keyword functions 
different from regular functions.  That means the programmer has to 
decide whether to make it a keyword function or not, but it also means 
fewer backwards compatibility issues.

The times I've seen keyword args suggested the rejoinder was always -- 
if you have so many arguments then just make a struct to hold them all. 
  Well that's exactly what this does, except it doesn't require the 
library desiger to litter his code and namespaces with structs that only 
serve the purpose of calling one function, and it doesn't make the user 
think about creating useless one-time structs to call that function 
either.  It's still what happens under the hood, just no one has to 
think about it.

I think the desire to limit the scope of such an argument struct to the 
function that requires it, is very similar to the desire to have inner 
functions.  The goal is to keep information specific to a particular 
function local to that function.  In the case of inner functions that 
means a function is created with a specially mangled name.  In the case 
of these automatic parameter structs for keyword arguments, you'd have a 
specially mangled struct name automatically generated.

--bb