Public outcry -- maybe not?

[Kristian Kilpi]

On Wed, 04 Jul 2007 13:45:28 +0300, Bruno Medeiros  
<brunodomedeiros+spam at com.gmail> wrote:
> 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).

I agree. The current initializer (.init) is safer and simpler than the old  
one (.oldinit).
However, having .oldinit too would be handy sometimes. And with Bruno's  
rules above,
using .oldinit should be ok.

Changing code from "int x = 42;" to "int x; x = 42", and vice versa, can  
still cause
problems (code fails to compile). What if one must define .oldinit in a  
variable
declaration in order to use it?

   int x.oldinit = 42;
   v = x.oldinit;  //ok

   int y = 42;
   v = y.oldinit;  //error

This way the programmer will clearly see which value is 'assigned' to  
.oldinit (and where).

Or we could have the following syntax instead:

   int x = oldinit 42;

(or maybe we should just stick with the current .init behaviour... :| )