Public outcry -- maybe not?

[kris]

Deewiant wrote:
> Sean Kelly wrote:
>> I generally use .init in a context where the change doesn't matter, so...
> 
> I'd find such code easier to read if you used typeof(foo).init, it's clearer if
> that's what you really mean. I've come across this in Tango once or twice: I was
> really bewildered to find out that "foo.nan" is equivalent to typeof(foo).nan, I
> was wondering if it had something to do with NaN payloads.

Shortcuts aside, I agree with Walter on this one (yeah, I know - hell 
just froze over). Sorry, Deewiant :(

It becomes clear once you start messing with declarations:

# struct S {int x=7; bool y = true;}
# typedef int Sock = -1;

In both cases, the assignment of a value is associated with a /type 
declaration/. This creates a .init value in an appropriate manner for S 
and for Sock.

On the other hand, the simple act of assigning a value to a /type 
instance/ should not be associated with .init values i.e.

# int x = 42;

Should not affect the .init of x in any manner, since it is not a type 
declaration. By doing simple assignment only, the compiler helps the 
programmer to avoid some latent bugs. For example, suppose I'm 
maintaining some code that looks like this:

# int x;
# x = 42;

and decide that those ought to be folded together while I'm cleaning up 
something else? Ouch! Potentially nasty bug

In other words, assigning .init values should be associated with 
type-declaration only, and not with type-instancing. This is a simple 
rule to comprehend - one that gravitates toward the principal of least 
surprise?