On Monday 08 November 2010 20:10:42 Walter Bright wrote: > 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.
We definitely want to avoid the nastier issues, but the lack of default constructors continually pops up as being a major problem. The QtD folks in particular were have a lot of problems because of it as I understand. I've certainly had problems with it my code. Even a restricted default constructor would be better than none. > > 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. Okay. Yes init is the state prior to the constructor being run, which is fine - you have the same with classes except that there is no init that you can directly access. The problem is when you can have init _without_ calling a constructor. If we could have default constructors on structs but have it so that any struct with a default constructor cannot be used where you have to have a bare init with no constructor call, then that at least seems like it would mostly solve the problem. In the few places where it's a problem - such as array construction - some kind of library solution could probably solve it (for dynamic arrays at least). - Jonathan M Davis
