www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10138] New: Regression (2.063 git-head): Using ReturnType with scoped no longer works

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10138

           Summary: Regression (2.063 git-head): Using ReturnType with
                    scoped no longer works
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: andrej.mitrovich gmail.com



19:38:35 PDT ---
-----
import std.traits;
import std.typecons;

class A
{
}

class B
{
    ReturnType!(scoped!A) a;  // L12

    this()
    {
        a = scoped!A();
    }
}

void main()
{
}
-----

2.062: ok
2.063 git-head:

test.d(12): Error: template instance ReturnType!(scoped) does not match
template declaration ReturnType(func...) if (func.length == 1 &&
isCallable!(func))

This is a breaking change. The workaround is to use 'typeof(scoped!A())'. This
workaround was not documented either.

Note that we should consider moving the inner Voldemort type to be a
module-scoped templated struct (e.g. 'Scoped'), so the API is easier to use if
you use scoped!() for member variables, e.g.:

-----
class B
{
    Scoped!A a;  // better API

    this()
    {
        a = scoped!A();
    }
}
-----

This is all based on the assumption that using scoped for member variables is
something that is supported. There are currently no unittests that try to
declare scoped variables, hence why this should either become an official
feature or it should be properly documented as disallowed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 22 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10138




That is changed by:
https://github.com/D-Programming-Language/phobos/pull/1215

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 22 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10138


Kenji Hara <k.hara.pg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



The code had a hidden bug with 2.062 dmd and earlier.

If class A has two ctors - one is default, another has arguments, and
initialize scoped value in B's ctor by calling argument version ctor, it had
caused errors.

import std.traits;
import std.typecons;

class A
{
    this() {}
    this(int) {}
}

class B
{
    ReturnType!(scoped!A) a;  // L12

    this()
    {
        a = scoped!A(1);    // L16
    }
}

void main()
{
}

Errors with 2.062:
test.d(16): Error: function
std.typecons.scoped!(A).scoped.Scoped!(A).Scoped.opAssign (Scoped!(A) p) is not
callable using argument types (Scoped!(A))
test.d(16): Error: cannot implicitly convert expression (scoped(1)) of type
Scoped!(A) to Scoped!(A)

In fact, the type you had extract by using ReturnType!(scoped!A) had not been
correct scoped value type. The bug has fixed by phobos/pull/1215, therefore the
OP code is invalid right now.

In conclusion, this is not a regression.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 27 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10138




06:16:05 PDT ---


 therefore the OP code is invalid right now.
 In conclusion, this is not a regression.


Ok, but we should at least add a comment somewhere. I think I'll add it to the
changelog perhaps..

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 27 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10138




14:51:41 PDT ---


 In fact, the type you had extract by using ReturnType!(scoped!A) had not been
 correct scoped value type. The bug has fixed by phobos/pull/1215, therefore the
 OP code is invalid right now.
 
 In conclusion, this is not a regression.


Here's the thing, though. In that phobos pull, monarchdodra commented with:

"Finally, I gave Scoped an  disabled this() to prevent our smarter users from
trying to build a Scoped using typeof."

It seems like he is actively trying to *disallow* using either ReturnType or
typeof in order to create a scoped field variable.

But, typeof still works. In 2.063 your example code will become:

-----
class A
{
    this() {}
    this(int) {}
}

class B
{
    typeof(scoped!A()) a;

    this()
    {
        a = scoped!A();   // ok
        a = scoped!A(1);  // ok
    }
}
-----

So now I can't tell whether we *support* using scoped field variables or is the
above just a hack? I need to know what to put in the changelog.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 27 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10138






 Here's the thing, though. In that phobos pull, monarchdodra commented with:
 
 "Finally, I gave Scoped an  disabled this() to prevent our smarter users from
 trying to build a Scoped using typeof."
 
 It seems like he is actively trying to *disallow* using either ReturnType or
 typeof in order to create a scoped field variable.
 
 But, typeof still works. In 2.063 your example code will become:


[snip]

You are confusing about  disable for `Scoped` struct default construction and
calling `scoped` function with zero argument.

If new A() is valid, scoped!A() is also valid. The latter is corresponding to
the former. It's the design of scoped utility.


 So now I can't tell whether we *support* using scoped field variables or is the
 above just a hack? I need to know what to put in the changelog.


The rejected case from 2.063 is this:

class A
{
    this() {}
    this(int) {}
}

class B
{
    typeof(scoped!A()) a;

    this()  // L12
    {
        //a = scoped!A();
        //a = scoped!A(1);
    }
}

Output:
test.d(12): Error: constructor test.B.this field a must be initialized in
constructor

The field B.a is must be initialized in constructor, comes from the  disable
this() defined in typeof(scoped!A()) struct.

However, getting the type of Scoped struct by using typeof is still allowed. So

typeof(scoped!A()) a;

is valid from 2.063.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 27 2013