www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5747] New: cannot cast away shared if opCast defined

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

           Summary: cannot cast away shared if opCast defined
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: ntrel-public yahoo.co.uk



06:36:07 PDT ---
struct S {
    int opCast() {return cast(int)this;}
}

shared S s;

void main() {
    auto u = cast(S)s;
}

shared.d(8): Error: function shared.S.opCast () is not callable using argument
types ()
shared.d(8): Error: cannot implicitly convert expression (s.opCast()) of type
int to S

Also happens if opCast returns other types, e.g. void[], etc.
Removing 'shared' compiles OK. Tested with dmd v2.051.

This code adapted from a newsgroup post about casting away shared from
BitArray:
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=132066

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 17 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5747


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com



PDT ---
It's not just a question of shared. If you declare opCast on a struct, you can
cast to that _exact_ type (so S can be cast to S and const S can be cast to
const S), but you can't cast cast to any other version of that type (so, S
can't be cast to const S, and shared S can't be cast to S). As a workaround,
you can declare an opCast which returns those types, but it shouldn't be
necessary to declare an extra opCast to do what works when you haven't declared
opCast.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 26 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5747


Nick Treleaven <ntrel-public yahoo.co.uk> changed:

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



05:10:12 PDT ---
It seems this might not be a dmd bug then, possibly a Phobos issue with shared
BitArray. Sorry for the noise.

Marked as invalid.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 07 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5747


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
           Platform|Other                       |All
         Resolution|INVALID                     |
         OS/Version|Linux                       |All



PDT ---
This is most definitely a dmd bug. Once you overload opCast, you can only cast
that type to the types that you've overloaded to cast to with opCast and the
_exact_ type that the variable already is. So, if it's S, you can cast to S but
not const S, shared S, or immutable S. If it's shared S, then you can cast to
shared S, but not S, shared S, or immutable S.

I don't know why you would think that this is not a dmd bug. Your original
example doesn't include BitArray at all.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 07 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5747


monarchdodra gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra gmail.com



Just hit this. IMO, this is a bug: The presence of an opCast should not prevent
"qualification-cast", which don't actually change the type. In particular, the
problem is that *even* trying to hand write it, it's not possible:

//----
import std.traits;

struct S
{
    int* p; //prevent implicit cast
    T opCast(T:bool)() pure const
    {
        return false;
    }
    T opCast(T)() const
    if (is(Unqual!T == S))
    {
        return this; //This fails
        return cast(T) this; //This overflows
    }
}

void main()
{
    immutable(S) s;
    auto b = cast(S)(s); //How to do this?
}
//----

IMO, a cast to the *same* type (but different quals) should always be defined
by the compiler, even if another opCast is defined, unless the use explicitly
overrides *that* opCast.

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