Public outcry -- maybe not?

[Bruno Medeiros]

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

I was mostly undecided on this issue, as Walter/Andrei's argument didn't 
convince me much (I didn't see that as a consistency breach), but kris's 
post on the other hand makes a very good case for current .init behavior.
The only way I see to satisfy both sides would be to have two 
properties, for these two different concepts: the type's default 
initializer (current .init), and the variable declaration initializer 
(old .init). Additionally the second property should not exist on types, 
only on variables (ie, 'Foo.oldinit' is illegal), and maybe it should 
also be illegal for variables which do not have an initializer (ie, 'int 
foo; foo.oldinit;' is illegal).



-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D