Jonathan M Davis wrote:
Well, if it's a default constructer which has to be nothrow and maybe pure or nothing, I'll take the default constructor. Now, if there's a better way to handle this which would result in full-blown, arbitrary default constructors, then that would be better, but something is better than nothing.
I just hate to get into the complex, buggy quagmire C++ has with this.
Another thought relates to the discussion of @disable on a struct's default constructor to disable init. What if we allowed default constructors but disabled init in the same way that we'd be doing with @disable? So, a struct uses init if it has no default constructor, but if it has one, then you can't use it where init would be required. Would that help fix things? It certainly would make some sense given that when using a default constructor, you don't really want init anyway. It could just be annoying with static arrays and the like (though = void should make it possible to make that work I think, if you really need to).
Actually, you do as init takes care of most of the initializations, and ensures the fields have predictable values before the ctor starts.
