null [re: spec#]

[Jonathan M Davis]

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