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