interesting. I didn't know b.init would change b. I thought it would just
evaluate to b's initializer. To quote the spec:
.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 or field, it is the default initializer for that variable or
field.
Walter, can you make the doc more clear that b.init will change b? I assume
the way to get the initializer for b without changing b is to do
typeof(b).init? I'm not sure how this works with fields, though, since the
initializer for the field depends on exactly which field you are talking
about and not just the type of the field.

Why expected? .init is a property which, AIUI, isn't supposed to have
any side effect.
<snip>

interesting. I didn't know b.init would change b. I thought it would just
evaluate to b's initializer. To quote the spec:
.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 or field, it is the default initializer for that variable or
field.
Walter, can you make the doc more clear that b.init will change b?

Only if that's the intended behaviour, which it most certainly isn't.
Having .init do two completely different things depending on what it's
applied to is no good for anyone, and I doubt this is among the kinds of
warts that Walter would put into the language.

I assume the way to get the initializer for b without changing b is to do
typeof(b).init?

No.
The initialiser of a variable and the initialiser of a type are two
different concepts. Suppose you have
static int[2] a = [ 13, 42 ];
a[0] = 69;
writefln(a[0],",",a[1]);
writefln(a.init[0],",",a.init[1]);
writefln(typeof(a).init[0],",",typeof(a).init[1]);
writefln(a[0],",",a[1]);
then the output should be
69,42
13,42
0,0
69,42
whereas with what you're making out it would be
69,42
13,42
13,42
13,42

I'm not sure how this works with fields, though, since the
initializer for the field depends on exactly which field you are talking
about and not just the type of the field.

Why expected? .init is a property which, AIUI, isn't supposed to have any
side effect.
<snip>

interesting. I didn't know b.init would change b. I thought it would just
evaluate to b's initializer. To quote the spec:
.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 or field, it is the default initializer for that
variable or field.
Walter, can you make the doc more clear that b.init will change b?

Only if that's the intended behaviour, which it most certainly isn't.
Having .init do two completely different things depending on what it's
applied to is no good for anyone, and I doubt this is among the kinds of
warts that Walter would put into the language.

agreed. I'd prefer the spec behavior over the current compiler behavior if
given the choice.

Why expected? .init is a property which, AIUI, isn't supposed to have
any side effect.
<snip>

interesting. I didn't know b.init would change b. I thought it would just
evaluate to b's initializer. To quote the spec:
.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 or field, it is the default initializer for that variable or
field.
Walter, can you make the doc more clear that b.init will change b?

Only if that's the intended behaviour, which it most certainly isn't.
Having .init do two completely different things depending on what it's
applied to is no good for anyone, and I doubt this is among the kinds of
warts that Walter would put into the language.

This line looks a little odd to me:
assert(array.init==int.init);
Aren't these incompatible types (int[2] and int)?
Stewart.
--
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.

That would seem to be itself a bug.
http://www.digitalmars.com/d/property.html
doesn't give any indication of arrays being a special case. If it was,
then what would array.init be given this?
int[2] array = [3, 5];
Stewart.
--
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.

That would seem to be itself a bug.
http://www.digitalmars.com/d/property.html
doesn't give any indication of arrays being a special case. If it was,
then what would array.init be given this?
int[2] array = [3, 5];

Dynamic arrays are initialized as having zero elements.
This isn't that usefull for .init
Static arrays are initialized with a given element count, each element
is initialized with the .init of the element's .init.
Returning the element-init of each array element is the only usefull
information the array-init can provide.
All element types are equal, their inits are equal, thus the behaviour is
legal.
Thomas
-----BEGIN PGP SIGNATURE-----
iD8DBQFCOtSr3w+/yD4P9tIRAjanAJ43yo+tnPS2KfJ9lOcfuND/2EaxFACcD4ex
WmNFL8VMPkc0TJf0yteUId0=
=amtH
-----END PGP SIGNATURE-----

Static arrays are initialized with a given element count, each element
is initialized with the .init of the element's .init.
Returning the element-init of each array element is the only usefull
information the array-init can provide.

Exactly.

All element types are equal, their inits are equal, thus the behaviour is
legal.

What are you referring to as "the behaviour" exactly?
Stewart.
--
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.

Static arrays are initialized with a given element count, each element
is initialized with the .init of the element's .init. Returning the
element-init of each array element is the only usefull
information the array-init can provide.

Exactly.

All element types are equal, their inits are equal, thus the behaviour
is
legal.

If there's any correct behaviour, it's that array1.init is an int[]
containing the (length, pointer) tuple to which array1 was initialised.
It follows that, if a given dynamic array's .init reference is used,
then the GC must hold on to the initialisation data. Since the array's
static, this could be done by keeping the initial data in the static
data segment.

I guess it's debatable whether it makes sense to talk of the initialiser
of an element or slice of a dynamic array. But the result is certainly
wrong.
Intuitively, it could defined such that array1[0].init ==
array1.init[0], which would be 1 in this case.

array1.length = 4
array1[].init.length = 0

I don't get quite what DMD is making of this. But again, whatever it's
doing is certainly bogus.

<snip>
These should behave in precisely the same ways as for the static case.
But the fact that the array's initialiser is null in this case makes for
a few differences. For once, array3.init.length is reported correctly,
but array3[0].init should throw an ArrayBoundsError if it should be
allowed at all.
Stewart.
--
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.

If there's any correct behaviour, it's that array1.init is an int[]
containing the (length, pointer) tuple to which array1 was initialised.

Indeed. I was beginning to suspect at this point that DMD was replacing
"array1.init" with "[1,2,3,4]" so my line:
typeid(typeof(array2.init))
actually reads:
typeid(typeof([5,6,7,8]))
which is why it gives the error "array initializers as expressions are not
allowed"
This seems to be supported by the docs:
file://localhost/C:/Library/D/dmd/html/d/property.html
".init produces a constant expression that is the default initializer."
Walter can you verify/deny this and/or explain the error message?

It follows that, if a given dynamic array's .init reference is used,
then the GC must hold on to the initialisation data. Since the array's
static, this could be done by keeping the initial data in the static
data segment.

This is what I expected it to do, it appears to instead replace x.init
with "a constant expression that is the default initializer."

Indeed. It seems to think array4.init is an 'int'. I would have expected
an int[], or null reference.
It could be argued that "int[4] array4" is the same as "int[4] array4 =
0", as arrays are initialised to 0. In which case the init value "0" is
technically an 'int'.

<snip>
These should behave in precisely the same ways as for the static case.
But the fact that the array's initialiser is null in this case makes for
a few differences. For once, array3.init.length is reported correctly,

I think that's a fluke given the previous behaviour :)

but array3[0].init should throw an ArrayBoundsError if it should be
allowed at all.

Indeed. I was beginning to suspect at this point that DMD was replacing
"array1.init" with "[1,2,3,4]" so my line:
typeid(typeof(array2.init))
actually reads:
typeid(typeof([5,6,7,8]))
which is why it gives the error "array initializers as expressions are
not allowed"
This seems to be supported by the docs:
file://localhost/C:/Library/D/dmd/html/d/property.html

None of us can access the files on your hard drive.
<snip>

It could be argued that "int[4] array4" is the same as "int[4] array4 =
0", as arrays are initialised to 0. In which case the init value "0" is
technically an 'int'.

Obviously 0 is an int. But we can't sensibly have the type of .init
dependent on the syntax that was used to initialise it. All type.init
properties should be of that type, and all variable.init properties
should be the same type as the variable.
<snip>

Since static arrays are contained by value, their elements/slices are
in effect variables in their own right, so it follows that all should
be valid. But again, the zeros are wrong.

Perhaps it is simply returning the .init value of the 'type' involved
i.e. 'int'. Rather than the .init value of the instance of the int?

<snip>
Yes, that is probably the essence of the bug. We could experiment with
it further.
Stewart.
--
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.

Indeed. I was beginning to suspect at this point that DMD was
replacing "array1.init" with "[1,2,3,4]" so my line:
typeid(typeof(array2.init))
actually reads:
typeid(typeof([5,6,7,8]))
which is why it gives the error "array initializers as expressions are
not allowed"
This seems to be supported by the docs:
file://localhost/C:/Library/D/dmd/html/d/property.html

It could be argued that "int[4] array4" is the same as "int[4] array4
= 0", as arrays are initialised to 0. In which case the init value "0"
is technically an 'int'.

Obviously 0 is an int. But we can't sensibly have the type of .init
dependent on the syntax that was used to initialise it. All type.init
properties should be of that type, and all variable.init properties
should be the same type as the variable.

I agree.. I was playing devils advocate again.

<snip>

Since static arrays are contained by value, their elements/slices are
in effect variables in their own right, so it follows that all should
be valid. But again, the zeros are wrong.

Perhaps it is simply returning the .init value of the 'type' involved
i.e. 'int'. Rather than the .init value of the instance of the int?

<snip>
Yes, that is probably the essence of the bug. We could experiment with
it further.

I rather hoped to attract Walters attention and save us the trouble.
Regan