Public outcry -- maybe not?

[Deewiant]

kris wrote:
> 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.

It shouldn't affect the .init of typeof(x). The .init of a type and a variable
is different, it's only when no initializer is explicitly specified that the
.init of the variable is equivalent to that of the type.

> 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

The bug is in your code, for using x.init instead of typeof(x).init when that's
what you really meant.

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

I think disallowing "x.init" when x has no explicit initializer would be the
clearest. It invalidates bugs such as the above, because you're forced to use
typeof(x).init. And we get to keep both behaviours for use as necessary, without
some oldinit property.

-- 
Remove ".doesnotlike.spam" from the mail address.