Bug 5715 – Contradiction in spec: meaning of variable.init

Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dlang.org
Product
D
Version
D2
Platform
All
OS
All
Creation time
2011-03-07T06:58:00Z
Last change time
2015-06-09T05:11:35Z
Keywords
spec
Assigned to
nobody
Creator
smjg
Blocks
677

Comments

Comment #0 by smjg — 2011-03-07T06:58:04Z
"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 by bugzilla — 2012-01-19T11:08:33Z
Changed to: If applied to a variable or field, it is the default initializer for that variable or field's type.