[Issue 10995] CTFE failures for structs with void initialized members

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=10995



--- Comment #8 from Maxim Fomin <maxim at maxim-fomin.ru> 2013-09-13 06:06:19 PDT ---
(In reply to comment #6)
> (In reply to comment #5)
> >
> > This is irrelevant to the issue because it is a different case.
> 
> It illustrates that it is illegal to read a value initialized to void.
> It is the same case, unless .init is magical. (And maybe it should be magical,
> see below).

In case of particular variable void initialization there is no questions
regarding default value of type per se, its semantic is clear and there is
consensus regarding it. However in case of field initialization, usecase
affects not some variable but type of variable (which is essential point here)
and as consequence, all instances of that type. And there is no consensus on
what does this feature mean. That's why I ask to concentrate on field void
initialization.

> That's only because it's been generating extremely bad code.
> Intuitively, initializing a struct should be the same as initializing each
> member individually.
> 
> struct S { 
>    int a = 2;
>    int b = void;
> }
> 
> S s;
> 
> should mean:
> S s = void;
> S.a = S.a.init;
> S.b = S.b.init;
> and only the S.a case should generate any code.
> 
> In fact, if it doesn't behave in that way, it's a completely pointless feature.
> (It's not an optimization).

Yes, this behavior makes sense. There is one question left - what is default
value of type S in CT, in particular what static assert(S.init.a == ??) should
be.

> > It looks like initializing some field with void is a weird idea which doesn't
> > fit into design, so it should be probably removed from language.
> 
> Quite possibly. It's a fight: .init gives what it was initialized with. 'void'
> says it's not initialized! They can't both be true!
> 

Yes.

> Certainly the current runtime behaviour (blitting zeros onto the struct) is
> useless.

Yes. 

> Another possible resolution would be to define .init to mean "the value the
> object would be initialized to, with = void treated as the default initializer.
> This would however mean that:
> S s;
> and
> S s = S.init;
> would not be the same, in the case where a void initializer is present.
> Of course they are different anyway, if a constructor is present.

I think this is better option than current situation. Init value of aggregate
with void field should give default value of respective type. If it does
provide in CT zeroes irrespective of type, it is useless, if it doesn't yield
anything at all, than it badly integrates into language design and should not
be supported at all.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------