Proposal: real struct literals

[Bill Baxter]

Jarrett Billingsley wrote:
> "Bill Baxter" <dnewsgroup at billbaxter.com> wrote in message 
> news:g3rs3g$11ub$1 at digitalmars.com...
> 

>>> They have completely different syntax and features.  Static struct 
>>> initializers are far more powerful: you can name members, initialize them 
>>> out of order, and skip arbitrary members.
>> This is the only place where I disagree with you.  Static struct 
>> initializers are more powerful in the ways you list, but in other ways 
>> they are less powerful.  With the static opCall you can make the 
>> parameters be whatever you want them to be -- they don't necessarily have 
>> to correspond to an actual member of the struct.  And you can also put 
>> arbitrary extra construction logic inside a static opCall.
> 
> I'm proposing them precisely because I _don't_ like that currently struct 
> literals and struct constructions overlap syntactically ;)  I was thinking 
> that struct literals would not be interceptible, they would be like integer 
> or string literals.  And if you want struct construction, use.. the 
> constructor (and whatever syntax that implies).

Ok.  Yeh, I can see some benefit in that too.  A POL, Plain Old Literal, 
to go with your POD, Plain Old Data.

> But you do bring up a good point with not being able to distinguish static 
> opCall vs. construction.  Still, then you have the reverse problem of what 
> we have now -- S{1, 2, 3}, while not looking like a function call, actually 
> might be!  :\

I suppose D structs could just do without a static opCall.  Actually I 
think the only real problem is that right now "aninstance()" could be a 
call to either "void static opCall()" or "void opCall()" when both are 
defined, and so the compiler gives a conflict message.  But if instead 
of static opCall you had a "constructor" then it wouldn't be considered 
a candidate for a call like "aninstance()".

So hopefully that is basically what Walter has planned for the struct 
constructors.

>> Yeh, then maybe you could even extend that to the declaration of the 
>> function too with an anonymous struct as the parameter:
>>
>> void memcopy(struct{void *src, void *dest, size_t num});
> 
> I seem to remember you being interested in this idea before ;)

Oh, yeh.  No wonder it seemed to resonate. :-)

>> Seems possible, though not necessarily easy for Mr. Compiler Writer.
>> Main problem is overloading.  How do you pick the right version of memcopy 
>> if there are several when presented a call like:
>>
>>     memcopy(src: a, dest: b, num: a.length);
> 
> Tricky, but I'm sure that some (reasonable) constraints could be put on this 
> type of function to make it easier to disambiguate.

One thing that's lacking is that you wouldn't be able to tell which 
named parameters were set vs which not set.

> Failing using structs as named parameters, there's certainly nothing 
> stopping the compiler from allowing named parameters with functions as they 
> are now.  They have the names right there :P 

Except 36 years of experience with C and C++ that makes people expect 
that the names of formal parameters don't matter.  I think the only way 
to make such a big change palatable at this point is to require some 
special syntax to use it.

--bb