Public outcry against new .init behaviour -- phobos.lib is broken in 1.017

[kris]

For example, you'll find that Phobos std.socket is borked due to this 
change. It's a subtle break, of the kind that is silent and nasty to 
track down. I guess phobos wasn't checked for impact from this change? 
If phobos /was/ checked, then perhaps this illustrates just how nasty, 
for developers, the change actually is

- Kris


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