What is the case against a struct post-blit default constructor?

[Jonathan M Davis]

On Wednesday, October 10, 2012 12:45:20 Don Clugston wrote:
> Of course there would be no point.
> You have not answered the question. The issue is, WHY can we not
> guarantee that that the struct default constructor is called?
> 
> I have a vague memory that Walter mentioned a technical difficulty once
> but I don't remember anything about what it was.
> 
> I can't imagine what it would be.

I know that one of the issues was exceptions, though that could be solved by 
forcing them to be nothrow. There were others, but I don't remember the 
details. Certainly, from what I recall, the situation is such that you'd have 
to restrict a default construtor so thoroughly that it would be pretty much 
pointless to have one at all.

> Even in the worst case, it would be
> possible to run CTFE on the default constructor in order to create
> .init. This would limit the default constructor to things which are
> CTFEable, but even that would still be useful for templated structs.

Of what real value is a default construct that must be CTFEable? If you can 
construct everything at compile time, then you can directly initialize each of 
the member variables. It's being able to run a default constructor at runtime 
that's useful, and since init must be known at compile time, you get into the 
whole issue of needing init when you can't use a default constructor. For 
default constructors to be of any real value, it would have to be possible to 
replace all instances of init with a call to the default constructor _at 
runtime_. As long as you're restricted to CTFE, you might as well just 
directly initialize the member variables to set the values appropriately in 
the init property.

- Jonathan M Davis