Implicit type conversion

[Jonathan M Davis]

On Saturday 08 January 2011 13:16:54 Michal Minich wrote:
> Use case:
> 
> import std.variant;
> 
> void foo (Variant v) {}
> 
> void main () {
>     Variant v = 3; // ok, this (....) called
>     v = 3;         // ok, opAssing  called
>     foo (v);       // ok, struct copy, this(this) called
>     foo (3);       // error
> }
> 
> I'm trying to understand what is needed to make this work from language
> design perspective. Is there already known/proposed solution to make this
> work? What comes to my mind as first - Variant constructor should be
> called on last line, the same way as on the first. But maybe to solve
> this, another operator is needed, opImplicitConvertFrom ...

There are definitely folks who want opImplicitCast (I think that it's pretty much 
going to be necessary to get std.typecons.Rebindable to work entirely 
correctly), and there's at least a decent chance that it will get added, but in 
general, D avoids implicit casting in order to avoid issues where you call 
functions which you don't really want to call (see http://is.gd/ksVli ). 
Regardless, opImplicitCast wouldn't help you here anyway, because you need to 
cast from an int to a Variant rather than the other way around, and it's not 
like int is going to have opImplicitCast defined, even if it did exist. 
Generally, you just need to give the correct type, which in this case would 
presumably mean foo(Variant(3)). It might be a bid annoying, but it avoids 
problems where you end up calling a function overload that you didn't intend to. 
If you really don't want to do that, then I believe that you're going to have to 
create another function overload for Foo which takes an int and deals with the 
conversion to Variant for you.

> Second question. Why is needed to have both - strut constructor (this)
> and opAssing. In variant case, constructor just forwards to opAssing.
> From high level point of view, I don't see any reason both should behave
> differently...

There could be a difference of efficiency depending on the type. It could be more 
efficient to do something differently in one. For instance, that's why we have both 
opAssign and opOpAssign. Technically, you could just not have opOpAssign and use 
the combination of opAssign and opBinary to do it, but then you're likely to end 
up with extra heap allocations and the like. It could be the same with a 
constructor and opAssign, depending on the type.

For the most part, D has tried to reduce how many operators you have to declare 
when they're related (such us using opCmp() to give you <, <=, >=, and >), but 
it does create extra ones in cases where there's a good chance that it's more 
efficient to have separate definitions (such as using opEquals() for == and != 
rather than using opCmp() for that).

- Jonathan M Davis