Public outcry against new .init behaviour

kris foo at bar.com
Mon Jul 2 16:23:54 PDT 2007


Seems odd to break existing code via a semantic change that introduces 
latent bugs. Especially when the logic behind the change is itself 
flawed. There are what appear to be some good suggestions for resolving 
the problem, so can we please resolve this soon?

FWIW, Tango uses this idiom, so we'll stick will the compiler version 
that works for now. The change may be responsible for Derelict crashing 
on the recent compiler updates also?



Deewiant wrote:
> Walter Bright wrote:
>> I'll repost what I did earlier on this:
>>
>>> Andrei made an argument that if one had:
>>>
>>>     struct S
>>>     {
>>>         static int foo;
>>>     }
>>>
>>>     S s = ...;
>>>     assert(s.foo == S.foo);
>>>
>>> then, analogously:
>>>
>>>     T t = ...;
>>>     assert(t.init == T.init);
>>>
>>> should hold as well. Consistency is a strong argument.
> 
> Yes, I mentioned that in my post.
> 
>> I like the old behavior too, but with the increasing use of generic
>> code, I worry that the inconsistency is going to cause a lot of problems
>> in the future.
> 
> I don't see why such problems can't be avoided by just always using
> typeof(variable).init when that's what is really meant. Premature fixing of
> problems is a bad idea.
> 
> Regarding 1.0 and 2.0, this definitely shouldn't be incorporated into 1.0, but
> I'm also arguing against adding it to 2.0. We don't need an additional property
> since you can just keep the current behaviour and use x.init and typeof(x).init.
> Adding a property would just make it so that it's x.someproperty and (x.init or
> typeof(x).init). Needless duplication.
> 



More information about the Digitalmars-d mailing list