www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - var.init change

reply "Chris Miller" <chris dprogramming.com> writes:
"The .init property for a variable is now based on its type, not its  =

initializer."

Before this change,
    int i =3D 42;
int.init was 0 and i.init was 42. Now with the change, they're both 0.


This var.init change sucks, because it silently broke a lot of my code. =
 =

I'm not the only one. The change was even applied to D 1.x.

Yes I can grep for it, but that's not enough. I have a lot of D code  =

hiding in dark corners waiting to be used. If the compiler jumped out an=
d  =

told me I made a mistake, then I could at least see what's going on and =
 =

fix it; but as it is now, it just silently and happily continues, with  =

unintended values.

Plus, to work around it, I'll have to write a lot of constants that take=
  =

the place of the init and switch to them throughout the code.

The way I would have rather gone with .init is just keep the old way and=
  =

deny .init for variables that were initialized with non-constant  =

expressions.

A more code-friendly way, that fits in better with existing code that wa=
s  =

coded for both the old and new var.init styles, is to completely deny  =

.init for variables; only allow it on types. At least I can catch the  =

issues, in both var.init cases (e.g. if my code relied on i.init being 4=
2,  =

or if I relied on i.init being 0)!

Then, perhaps another property could be added specifically for variable =
 =

initializers, like the old style .init but just for constant initializer=
s.  =

The old behavior, or this new property proposal, is very handy; it lets =
 =

you avoid writing constants for many cases. Isn't this the spirit of D? =
I  =

believe some sample code even used to brag about this feature.

- Chris
Sep 05 2007
next sibling parent reply Myron Alexander <someone somewhere.com> writes:
Chris Miller wrote:

 the spirit of D? I believe some sample code even used to brag about this 
 feature.


The sample code in the D2.0 reference is based on the original concept 
and has not changed (scroll down to .init):

http://www.digitalmars.com/d/property.html

I am interested in the reason behind this change, if only to learn what 
problems were introduced by such a concept.

Regards,

Myron.
Sep 05 2007
parent reply mwarning <mwarning spam.no> writes:
Myron Alexander Wrote:

 I am interested in the reason behind this change, if only to learn what 
 problems were introduced by such a concept.


From:
http://www.digitalmars.com/webnews/newsgroups.php?compose=reply&mid=55170

Walter Bright Wrote:


 Deewiant wrote:

 It's not deadly - I found 14 instances of such in about 7000 LOC (wc -l), and
 they can be corrected - but it makes code noticeably uglier. This is one of
 those small, simple bits of syntactic sugar which make coding in D fun and
 productive. I want it back.


 
 I'll repost what I did earlier on this:
 

 Andrei made an argument that if one had:
 
     struct S
     {
         static int foo;
     }
 
     S s = ...;
     assert(s.foo == S.foo);
 
 then, analogously:
 
     T t = ...;
     assert(t.init == T.init);
 
 should hold as well. Consistency is a strong argument.


 
 
 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 think it's a nice feature, too.
But I'm doubtful about the inconsistency argument.
T t = ...; is initialized at run time, and it's value is also only known at
runtime.
Therefor the compile time value is always null (or undefined when void was
assigned at compile time).

So I would argue that there might be no inconsistency, only if you make the
meaning of .init broad enough, so that it undoubtfully causes inconsistencies.

Am I wrong?
Sep 05 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Here's a link to the whole thread:

http://www.digitalmars.com/d/archives/digitalmars/D/Public_outcry_against_new_.init_behaviour_55158.html#N55170
Sep 05 2007
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Walter Bright Wrote:


 Here's a link to the whole thread:
 
 http://www.digitalmars.com/d/archives/digitalmars/D/Public_outcry_against_new_.init_behaviour_55158.html#N55170


Any chance of getting the old behavior back as a different property? For
example:

int x = 42;
assert(int.init == 0);
assert(x.init == 0);
assert(x.starting == 42);

For what it's worth, I agree that the new .init does increase inconsistency,
but the old behavior had its uses, so it's a shame it went away forever.
Sep 05 2007
parent "Chris Miller" <chris dprogramming.com> writes:
On Wed, 05 Sep 2007 16:54:33 -0400, Robert Fraser  =

<fraserofthenight gmail.com> wrote:


 Any chance of getting the old behavior back as a different property? F=


or  =


 example:

 int x =3D 42;
 assert(int.init =3D=3D 0);
 assert(x.init =3D=3D 0);
 assert(x.starting =3D=3D 42);

 For what it's worth, I agree that the new .init does increase  =



 inconsistency, but the old behavior had its uses, so it's a shame it  =



 went away forever.


Other ideas:
    x.varinit
    x.thisinit
    x.iinit (instance init)
    x.decl (declaration)
    x.declvalue
    x.firstvalue
    x.myinit


Another idea, the -v1 switch could make var.init an error (but keep  =

Type.init as it is the same) as back then it meant the variable's  =

initializer. If you have code with the old .init use, compile with -v1 t=
o  =

catch the issues.

Either way, I still would like something that represents the variable's =
 =

initializer if it is constant. Without it, even if I catch all my .init =
 =

issues, I'll have to write a bunch of constants and replace throughout t=
he  =

code.
Sep 05 2007
prev sibling parent Jason House <jason.james.house gmail.com> writes:
Walter Bright wrote:

 Here's a link to the whole thread:
 
 http://www.digitalmars.com/d/archives/digitalmars/D/Public_outcry_against_new_.init_behavio
r_55158.html#N55170 
 


As far as I can tell, that thread suggests that the old var.init 
functionality not be lost but rather get some other name.  Is there a 
plan to implement that? or has it been done already?
Sep 05 2007
prev sibling next sibling parent "Chris Miller" <chris dprogramming.com> writes:
By the way, I don't think this is a valid argument against the old  =

var.init:

    int x =3D 42;
    void foo(inout int x)
    {
       // x.init !=3D 42
    }

The var.init just doesn't apply to parameters; just Type.init does. It  =

especially doesn't apply when you use the updated var.init feature reque=
st  =

where it errors if it's a runtime initializer; for parameters it's alway=
s  =

runtime (setting aside the new static ones or templates).

I very much love and miss the old var.init. It's so much simpler to  =

compare and reset variables with their initial values using the old  =

var.init, not having to define separate constants for something the  =

compiler can remember (and used to just fine).
Sep 09 2007
prev sibling parent Max Vohra <RandomMan gmail.com> writes:
It seems from that post that the change caused more problems than it fixed, I
thought it was a very good feature of D, and one should really by using
typeof(x).init if that's what is meant. It's far more logical to have int.init
return the default initialization value of the int type, and have variable.init
return the value in which the variable was initialized as. In any case, whether
new way is here to stay, the page http://www.digitalmars.com/d/property.html
should really be changed to reflect the standard, since inconstancy between
documentation and implementation is annoying to say the least.

~Max

Chris Miller Wrote:


 "The .init property for a variable is now based on its type, not its  
 initializer."
 
 Before this change,
     int i = 42;
 int.init was 0 and i.init was 42. Now with the change, they're both 0.
 
 
 This var.init change sucks, because it silently broke a lot of my code.  
 I'm not the only one. The change was even applied to D 1.x.
 
 Yes I can grep for it, but that's not enough. I have a lot of D code  
 hiding in dark corners waiting to be used. If the compiler jumped out and  
 told me I made a mistake, then I could at least see what's going on and  
 fix it; but as it is now, it just silently and happily continues, with  
 unintended values.
 
 Plus, to work around it, I'll have to write a lot of constants that take  
 the place of the init and switch to them throughout the code.
 
 The way I would have rather gone with .init is just keep the old way and  
 deny .init for variables that were initialized with non-constant  
 expressions.
 
 A more code-friendly way, that fits in better with existing code that was  
 coded for both the old and new var.init styles, is to completely deny  
 .init for variables; only allow it on types. At least I can catch the  
 issues, in both var.init cases (e.g. if my code relied on i.init being 42,  
 or if I relied on i.init being 0)!
 
 Then, perhaps another property could be added specifically for variable  
 initializers, like the old style .init but just for constant initializers.  
 The old behavior, or this new property proposal, is very handy; it lets  
 you avoid writing constants for many cases. Isn't this the spirit of D? I  
 believe some sample code even used to brag about this feature.
 
 - Chris
Dec 06 2007