var.init change

Chris Miller chris at dprogramming.com
Wed Sep 5 01:20:53 PDT 2007


"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



More information about the Digitalmars-d mailing list