On Sunday, 14 July 2013 at 15:28:26 UTC, bearophile wrote:
> Namespace:
>
>> The warning comes from:
>> http://dlang.org/changelog.html#staticfields
>
> But is "void" an initializer?
>
> Bye,
> bearophile

Technically - yes, but I think it should be an exclusion from general rules mentioned there because of special semantics it has. Until then you can safely just ignore this warning, it exists only as part of behavior change process.

On Sunday, 14 July 2013 at 15:17:43 UTC, bearophile wrote:
> test.d(4): Error: slice x[] is not mutable

This is almost 100% a bug. I have played a bit with this snippet and seems like void initialization breaks usual rule that you can cook const/immutable field in constructor (which is kind of guaranteed by TDPL). Simple test case:

class A
{
	immutable int x; // works
	// immutable int x = void; // works not

	this()
	{
		x = 42;
	}
}

On 07/14/13 18:24, Dicebot wrote:
> class A
> {
>     // immutable int x = void; // works not

`void` is special - yes. But keep in mind that this currently does
not actually do what it intuitively appears to, and what the code
posted in this thread apparently expects. IOW void-initialization
of aggregate fields does *not* actually disable initialization;
the result can be /worse/ codegen (blitting of `.init` instead of
bzero'ing). At least this was how it worked last time i tried this,
months ago; had to use ugly template mixins to avoid the expensive
useless copy (`x` was a static array). Handling it properly requires
supporting holes in .init.

artur

Ugh, rly? As far as I understand spec it should work like this:

T x; // sets x to T.init
T x = void; // don't initialize x at all, leave garbage

What hole in .init are you referring to?

On Sunday, 14 July 2013 at 16:49:13 UTC, Artur Skawina wrote:
> ...

On 07/14/13 18:59, Dicebot wrote:
> Ugh, rly? As far as I understand spec it should work like this:
> 
> T x; // sets x to T.init
> T x = void; // don't initialize x at all, leave garbage

"void-initialization of aggregate fields does *not* actually disable initialization":

   struct S {
      T x = void;
   }

   S s; // Copies S.init -> s; including s.x.

The initialization of s.x is *not* skipped.
When T==ubyte[100_000] etc adding the '=void' initializer can
make things /worse/ (blit instead of bzero).

> What hole in .init are you referring to?

See above - handling this properly means treating every `void` initialized field as a hole. Also, '=void' alone should not result in copying of T.init when it is just a zero-filled chunk.

artur

Still can't find this in the spec but I see what you are getting at, makes sense. I think this actually is yet another case where CTFE-able default constructor for structs would have been a major win.

On Sunday, 14 July 2013 at 17:41:35 UTC, Artur Skawina wrote:
> On 07/14/13 18:59, Dicebot wrote:
>> Ugh, rly? As far as I understand spec it should work like this:
>> 
>> T x; // sets x to T.init
>> T x = void; // don't initialize x at all, leave garbage
>
> "void-initialization of aggregate fields does *not* actually disable
> initialization":
>
>    struct S {
>       T x = void;
>    }
>
>    S s; // Copies S.init -> s; including s.x.

On 07/14/2013 07:51 PM, Dicebot wrote:
> Still can't find this in the spec but I see what you are getting at,
> makes sense. ...

(This is a QOI issue.)

On Sunday, 14 July 2013 at 18:12:07 UTC, Timon Gehr wrote:
> On 07/14/2013 07:51 PM, Dicebot wrote:
>> Still can't find this in the spec but I see what you are getting at,
>> makes sense. ...
>
> (This is a QOI issue.)

Is it really? I see certain conflicting interests between bit-wise T.init copy for structs and void initialization of a field. At least given the fact void initialization is considered to be a performance optimization tool. Currently there does not seem to be a away to create a struct by running postblit on top of garbage.

void initialization is for stack variables only. It doesn't make sense for fields as they're initialized with init.