[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 #6 from Don <clugdbug at yahoo.com.au> 2013-09-13 03:15:04 PDT ---
(In reply to comment #5)
> (In reply to comment #3)
> > No, it's illegal. You're telling the compiler that you will initialize it. The
> > compiler attempts to detect cases where you failed to do so, but it isn't
> > always successful. For DMD, you need to compile with -O.
> > 
> > struct S {
> >    int x;
> > }
> > 
> > void main() {
> >    S s = void;
> >    s.x++;
> > }
> 
> 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).

> > $ dmd -O bug
> > bug.d(7): Error: variable s used before set
> > 
> > The reason it seemed to be legal in structs, is that the compiler historically
> > ignored the = void, and initialized it anyway! Now marking a field as void
> > actually has an effect... (at least in some cases).
> > 
> 
> I think this point (issuing not initialized error) is wrong. Regardless of what
> dmd does produce in runtime (technically speaking dmd didn't ignored void
> initializer for fields - its presence actually affected behavior),

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).

> there should
> be statically known default value of any type - that's why during CTFE dmd
> should produce some default value even for structs having void initialized
> fields. So, if dmd accepts this feature, it should produce some value. Not
> initialized type does not make much sense.
> 
> 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!

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

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.

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