This has probably been brought up before, but given that the lack of default constructors for structs was a major problem for the QtD folks, I've been thinking about the problem again, and I was wondering whether it would work to have default constructors for structs as long as they were pure? Isn't the main problem with having default constructors for structs that the default constructor must result in the same value every time so that the compiler can set init appropriately? Or is there something else to it? It does seem to me that we should get default constructors for structs to work if we can. It's obviously been causing a problem in real code, including for major projects like QtD.

- Jonathan M Davis

On Fri, 08 Oct 2010 03:31:54 +0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> Isn't the main
> problem with having default constructors for structs that the default
> constructor must result in the same value every time so that the compiler can
> set init appropriately?

Problem is that requirement is too restrictive. If ctor is pure, doesn't access globals and results in perfectly same objects, then why can't you do the initialization at compile-time? You usually can, that's not the issue.
The issue is that sometimes you need to call external functionals that are not pure in general (e.g. allocate some resources, initialize fields with unique values, register itself somewhere etc).

On Thursday, October 07, 2010 16:42:47 Denis Koroskin wrote:
> On Fri, 08 Oct 2010 03:31:54 +0400, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> > Isn't the main
> > problem with having default constructors for structs that the default
> > constructor must result in the same value every time so that the
> > compiler can
> > set init appropriately?
> 
> Problem is that requirement is too restrictive. If ctor is pure, doesn't
> access globals and results in perfectly same objects, then why can't you
> do the initialization at compile-time? You usually can, that's not the
> issue.
> The issue is that sometimes you need to call external functionals that are
> not pure in general (e.g. allocate some resources, initialize fields with
> unique values, register itself somewhere etc).

With the relaxed purity rules (which should be in the next release of dmd), that problem should be somewhat mitigated. But you still won't be able to call globals.

- Jonathan M Davis