Public outcry against new .init behaviour

[Sean Kelly]

Deewiant wrote:
> Sean Kelly wrote:
>> For what it's worth, I actually had no idea that t.init was different
>> from T.init.  I must have simply overlooked it in the spec.  But while
>> it is an appealing idea, it presents tradeoffs that are perhaps not
>> ideal.  If the actual initialization value must be retained, then space
>> must be reserved for it in functions where "t.init" is used.  And it
>> seems like this behavior could possibly change based on scope?  ie.
>>
>>     void fnA() {
>>         int x = 5;
>>         assert( fnB( x ) == x.init );
>>     }
>>
>>     void fnB( inout int x ) {
>>         return x.init;
>>     }
>>
>> Will the above pass or fail?
>>
>> Alternately, if space is not reserved for the init value, then the
>> initializer must be run every time "t.init" is called.  But what if this
>> initializer has side effects?  This is clearly not an acceptable solution.
>>
> 
> The code will fail, because x.init here is the .init of x in that scope. Here,
> it's always typeof(x).init, but if the x in the parameter list were to have a
> default initializer (doesn't work in the case of inout), x.init would be that:
> 
> void fnB(int x = 3) { /+ x.init is 3 +/ }

Yeah, now that I'm aware of the old rule I think it makes total sense, 
and I'm not entirely sure why it has to be done away with--value.init 
was just an alias for the local initializer.  Since ctors (static or 
otherwise) are effectively not at class or global scope, there's little 
chance of losing an initialization in a huge pile of code.

> A good rule is that if a variable is initialized to a compile-time constant,
> variable.init is that constant. Otherwise, variable.init is
> typeof(variable).init. (My terminology might be a bit wrong: it's not the
> variable, it's the symbol of a variable in a scope? Whatever works so that it
> explains function parameters, too.)

I'm really fine with it either way.  I think the old approach was a neat 
trick and in hindsight made sense to me, but the new approach is 
consistent and straightforward.  I generally use .init in a context 
where the change doesn't matter, so...

> I wouldn't mind if variable.init were an error in the latter cases, but the
> above rule can be used to always figure out what it means.
> 
> (To be pedantic, your code will fail also because fnB returns void.)

Oops.


Sean