null [re: spec#]

[Jonathan M Davis]

On Tuesday 09 November 2010 02:22:31 Simen kjaeraas wrote:
> Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > 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.
> 
> In my experience, disabling the default constructor would be enough.
> That way the compiler warns you that 'this object has no valid default
> state, so use a constructor.'

Except that I _want_ to have default constructors for structs. Sure, having a 
struct which can't be used without constructing it (i.e. just using init) and 
which has no default constructor can be useful, but having default constructors 
would be _huge_.

> > 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
> 
> And where is that? Currently no such thing exists, as we have no default
> constructors for structs. That means we could interpret any use of .init
> as a constructor call. Disabling default constructors has this same
> advantage, while avoiding the problems. The only problem is you will have
> to use a constructor explicitly.

There has been discussion in the nullable reference thread of making @disable 
this() {} for structs disable init so that you can only use such structs by 
constructing them, and any place that would use init (such as a static array) 
would not be legal for such a struct. I'm suggesting that we do something 
similar to that except that we make it so that having a default constructor 
disables init and constructing the struct with the default constructor is then 
one of the legal ones to construct the struct.

- Jonathan M Davis