D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 5715 - Contradiction in spec: meaning of variable.init
Summary: Contradiction in spec: meaning of variable.init
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dlang.org (show other issues)
Version: D2
Hardware: All All
: P2 normal
Assignee: No Owner
URL: http://www.digitalmars.com/d/1.0/prop...
Keywords: spec
Depends on:
Blocks: 677
  Show dependency treegraph
 
Reported: 2011-03-07 06:58 UTC by Stewart Gordon
Modified: 2015-06-09 05:11 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Stewart Gordon 2011-03-07 06:58:04 UTC
"If applied to a variable or field, it is the default initializer for that variable or field. For example:

int a;
int b = 1;
typedef int t = 2;
t c;
t d = cast(t)3;

int.init	// is 0
a.init		// is 0
b.init		// is 0
t.init		// is 2
c.init		// is 2
d.init		// is 2"

According to the prose, b.init == 1.  But this claims it is 0.  Similarly with d.

I recall the semantics being changed at some point from the initial value of the variable to that of its type.  This matches the examples, but not what the statement actually says.  Possible rewrite of that paragraph:

".init produces a constant expression that is the default initializer. If applied to a type, it is the default initializer for that type. If applied to a variable, it is the default initializer for the variable's type.  If applied to a field, it is the default initializer for that field.  For example:"

Moreover, is the meaning for a field meant to apply only to type.field constructions, or to object.field constructions as well?
Comment 1 Walter Bright 2012-01-19 11:08:33 UTC
Changed to:

        If applied to a variable or field, it is the
        default initializer for that variable or field's type.