Public outcry against new .init behaviour

Deewiant deewiant.doesnotlike.spam at gmail.com
Mon Jul 2 12:05:17 PDT 2007


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.

-- 
Remove ".doesnotlike.spam" from the mail address.



More information about the Digitalmars-d mailing list