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
