Public outcry against new .init behaviour

[kris]

(removed earlier post on this topic)


Seems like there's more subtlety to this than Walter has explained? From 
the description of the change, I'd asserted that the following code 
would be impacted:

# typedef int socket_t = -1;
# ...
# socket_t sock;
# ...
# if (sock is sock.init)
# ...

However, upon inspection, the codegen for v1.017 is actually this:

# if (sock is sock.init)
# 004044E6 83 7D 08 FF cmp dword ptr [sock],0FFh

meaning that the typedef value has been respected, just like v0.016

Either this means that Walter missed typedef in his changes, or that 
typedef is intended to remain as it was.

Which is it?





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