Public outcry against new .init behaviour

[Sean Kelly]

Kristian Kilpi wrote:
> On Mon, 02 Jul 2007 21:04:09 +0300, Walter Bright 
> <newshound1 at digitalmars.com> wrote:
>>
>> 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 fail to see how this is a matter of consistency. To me, it's a matter 
> of definition:
> 't.init' means the initialization value of the *variable* 't'.
> 'T.init' means the initialization value of the *type* 'T'.

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.

> Now 't.init' is meaningless.

Not at all.  It's simply a shorthand for "typeof(t).init".

> Well, if one wants consistency ;) , lets consider the following:
> 
>   struct Z {
>     static int x;
>     int y;
>   }
>   Z a, b;
> 
> Because 'a.x == b.x' holds, 'a.y == b.y' should hold too? <g>

This is not a valid analogy.


Sean