Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)

[Timothee Cour]

Although I agree that having a default constructor would be convenient, I
think the problem is that S.init should be known at compile time by the
spec.

Maybe we could support the following syntax, with a static this instead of
this :

struct S
{
    int x=11;
    int y = void;

    static this()  // hypothetical
    {
        // x would already be initialized to int.init here
        assert(x == int.init);
        // y is left uninitialized here
       y=x*x;
    }
}

On Fri, May 17, 2013 at 2:34 PM, Andrej Mitrovic <andrej.mitrovich at gmail.com
> wrote:

> On 5/17/13, Walter Bright <walter at digitalmars.com> wrote:
> > I oppose this. D has a lot of nice features because of the .init
> property.
> > Default constructors wreck that.
>
> Would they? I'm thinking the process would be:
>
> struct S
> {
>     int x;
>     int y = void;
>
>     this()  // hypothetical
>     {
>         // x would already be initialized to int.init here
>         assert(x == int.init);
>
>         // y is left uninitialized here
>     }
> }
>
> Maybe that's already clear. But why is .init actually such a big
> problem? If it becomes arbitrarily expensive to call .init of a
> struct, well it's because it has to be - if the user really provided
> an expensive default ctor. But it's entirely the user's
> responsibility. So then .init can even throw, but throwing exceptions
> isn't a big deal. Is there some other problem?
>
> A custom default ctor in a struct is one of the most asked for
> features. Just yesterday we spent several hours explaining to a C++
> user why a default ctor doesn't work, and what .init is for. The whole
> conversation could have been avoided if D had support for custom
> default ctors for structs. This topic comes up very often in IRC and
> the forums.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130517/401c4428/attachment.html>