DMD 1.035 and 2.019 releases

[Denis Koroskin]

On Thu, 04 Sep 2008 15:44:30 +0400, Tomas Lindquist Olsen  
<tomas at famolsen.dk> wrote:

> Walter Bright wrote:
>> bearophile wrote:
>>> Walter Bright:
>>>> If there's any constructor defined for S, then S(args) is a
>>>> constructor call. If there's any opCall defined for S, then S(args)
>>>> is an opCall call. Otherwise, it's a struct literal.
>>>
>>> I haven't tried that in real code, so I can't be sure, but while it
>>> may work for the compiler, it sounds a bit too much complex for the
>>> person that later reads the code. Too many alternative possibilities
>>> may make the code more complex to follow.
>>>
>>> To reduce such ambiguity (ambiguity for the person, not for the
>>> compiler) may be to change the syntax of struct literals...
>>  I disagree, I think just the reverse. The S(args) syntax means that  
>> it's entirely up to the struct designer to say how it should work. The  
>> user needn't know or care, and the struct designer can change the  
>> design without affecting user code.
>>
>
> This is one of those things I really dislike about D :(
> It's really nice that we can override struct initialization, but the  
> fact that it eliminates the possibility to override it (with a nice  
> syntax) makes it much less appealing IMHO.
>
> The most important point to me, is that old thing about static struct  
> initializer and struct literals have different syntaxes, and that the  
> static variant is much more flexible.
>
> I would have loved to see the static struct initializer syntax become an  
> expression. If the problem is ambiguity, why not just prefix the {}  
> braces with the struct name?
>
> struct S
> {
>   int a;
>   float b;
> }
>
> const s = S{1, 2.0};
> const t = S{b:3.14};
>
> void foo()
> {
>   auto st = S{4,5.5};
> }
>

It may have problems with the q{}:

struct q
{
     float t;
}

auto foo = q{ t = 3.1415f };	// what's the type of foo?

But then, does anybody using it?

Other than that I agree, current solution is not very good.

> (also not that it's currently impossible to use type inference with the  
> current static struct initializers)
>
> This would eliminate the gripe most people have with this I think, as  
> well as making static and   non-static initializers consistent. like  
> they are *for all other types*.
>
> I can't help feel structs (like static arrays) aren't first class  
> citizens in D. Even with the latest additions in D2. It hurts, and is  
> just one of those small reasons why I sometimes regret I even joined  
> this community...
>
> My 2 cents on this, I think it's a big mistake going against the wishes  
> of the D community. If I'm wrong, let me know.
>
> -Tomas



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/