dmd 1.070 and 2.055 release

Jonathan M Davis jmdavisProg at gmx.com
Sun Sep 11 14:18:58 PDT 2011


On Sunday, September 11, 2011 18:57:03 Ali Çehreli wrote:
> On Sun, 11 Sep 2011 10:57:12 -0700, Walter Bright wrote:
> > On 9/11/2011 9:08 AM, Max Samukha wrote:
> >> This test case
> >> 
> >> struct S
> >> {
> >> @disable this();
> >> this(int x)
> >> {
> >> }
> >> }
> >> 
> >> class C
> >> {
> >> S s;
> >> this()
> >> {
> >> s = S(42);
> >> }
> >> }
> >> 
> >> void main()
> >> {
> >> auto c = new C;
> >> }
> >> 
> >> yields Error: default construction is disabled for type C
> >> 
> >> Is it a bug?
> > 
> > No, it's a feature!
> 
> class C
> {
>     S s = S(0);      // <-- initial value provided
> 
>     this()
>     {
>         s = S(42);
>     }
> }
> 
> Since C doesn't use any default constructed S, I would expect at least
> the above to compile.
> 
> Could you please explain why the disabled default constructor of S
> affects C in that case (and even in Max's case).

Your case should work (if it doesn't it's a bug, I believe), but Max's won't, 
because using

S s;

isn't legal when S is a struct whose default constructor has been disabled. 
Actually, what worries me is what happens when you try and use S.init (I 
haven't tried it, so I don't know what happens). S.init has effectively been 
made non-existent by this @disable this(); but there's plenty of templated 
code out there that would try and use the init value for checking stuff. I 
would assume that such code would fail, but I don't know. Assuming that such 
code can actually work with a struct whose default initializer has been 
disabled, such template constraints are going to have to be written differently 
now.

- Jonathan M Davis


More information about the Digitalmars-d-announce mailing list