On Friday, March 29, 2013 23:57:56 Timothee Cour wrote:
> version(good) works.
> version(bad) does not.
> Can we make std.conv.to work for out-of-class opCast?
> Use case: same reason as UFCS, where we don't wanna define all methods
> inside class def, leading to possible extensions later.
> Currently this IS a problem when class A is in a library over which we
> have no control and a user defined class B wants to cast from A.
> 
> ----
> import std.conv;
> struct B{ int x;}
> struct A{
>     int x;
>     version(good)
>     auto opCast(T)() {return B(x);}
> }
> version(bad)
> auto opCast(T)(A a) {return B(a.x);}
> void main(){    auto b=to!B(A.init); }
> ----

If that's what you want to do, create a constructor on B which takes an A. As long as you're in control of one of the types, you can either declare the appropriate opCast or the appropriate constructor (which one depending on which direction you're trying to do the conversion in and which one you have control over). The only time that you're out of luck is when you don't have control over the API of either type.

- Jonathan M Davis

yes, that was precisely the case I was concerned about: two types for
which I don't have control over. That's a  common enough case.
My current workaround is to use a
----
T1 to2(T1,T2)(T2 a)
----
which is ugly as it only works for *that* conversion and doesn't play well with the rest of phobos (eg: won't work recursively, if I want to convert a vector of A to a vector of B).

I could also reimplement a whole std.conv.to (say, to2) that also checks for out of class opCast, but I don't see what's so bad about having it in std.conv.to.

>> This was discussed many times, even recently enhancement request was created in bugzilla

Do you have any link? Thanks!



On Sat, Mar 30, 2013 at 12:21 AM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> On Friday, March 29, 2013 23:57:56 Timothee Cour wrote:
>> version(good) works.
>> version(bad) does not.
>> Can we make std.conv.to work for out-of-class opCast?
>> Use case: same reason as UFCS, where we don't wanna define all methods
>> inside class def, leading to possible extensions later.
>> Currently this IS a problem when class A is in a library over which we
>> have no control and a user defined class B wants to cast from A.
>>
>> ----
>> import std.conv;
>> struct B{ int x;}
>> struct A{
>>     int x;
>>     version(good)
>>     auto opCast(T)() {return B(x);}
>> }
>> version(bad)
>> auto opCast(T)(A a) {return B(a.x);}
>> void main(){    auto b=to!B(A.init); }
>> ----
>
> If that's what you want to do, create a constructor on B which takes an A. As long as you're in control of one of the types, you can either declare the appropriate opCast or the appropriate constructor (which one depending on which direction you're trying to do the conversion in and which one you have control over). The only time that you're out of luck is when you don't have control over the API of either type.
>
> - Jonathan M Davis

On Saturday, 30 March 2013 at 07:57:38 UTC, Timothee Cour wrote:
>>> This was discussed many times, even recently enhancement request was created in bugzilla
>
> Do you have any link? Thanks!
>

Discussion on bugzilla: http://d.puremagic.com/issues/show_bug.cgi?id=9786

Here there were several discussions, use search.

P.S. Forum needs fixing with respect to thread splitting but please do not make the situation even worse with merging different comments and please respond below the text. Different people use different software to read discussions, so making text consistent makes sense.