Proposal: real struct literals

[Jarrett Billingsley]

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

> But there will still be the problem that using call syntax for struct 
> construction gets in the way of using structs as functors.  There's no way 
> to distinguish between "I'm constructing" and "I'm calling this as a 
> functor".  If you're lucky construction parameters and functor parameters 
> don't overlap, but if you're unlucky you must contort your code.  Struct 
> construction should not use function call syntax.

Oo.  Nasty.

>> 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).

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!  :\

> 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 ;)

> 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.

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