DIP52

Title:	Implicit conversions
DIP:	52
Version:	1
Status:	Draft
Created:	2013-12-11
Last Modified:	2013-12-11
Author:	Simen Kjærås
Links:	Related forum discussion #1 Related forum discussion #2 WalterAndrei.pdf - DConf 2007

Abstract

Implicit conversion to and from other types are useful, and is to some extent covered by existing language features. Some cases are currently not covered, but could be worthy additions to the toolbox.

Rationale

While too much implicit conversion can be a bad thing, so can too little. Today, some forms of implicit conversion are only available to built-in types, and it would prove fruitful for user-defined types to to have the same abilities.

In WalterAndrei.pdf, pages 21-22, a mechanism for implicit casting to a specified type (opImplicitCastTo) as well as from a specified type (opImplicitCastFrom) is outlined.

It can be argued that alias this provides the behavior of opImplicitCastTo, but there are some missing features that opImplicitCastTo could enable, and opImplicitCastFrom is simply not covered by the language today.

Problem

In a discussion on the forum, it was pointed out that while this code works perfectly:

Tuple!(int, int) foo() {
    import std.typecons;
    Tuple!(int, "x", int, "y") a;
    return a;
}

The following does not:

Tuple!(int, "x", int, "y") bar() {
    import std.typecons;
    Tuple!(int, int) a;
    return a;
}

The problem here is one of specificity. In the first example, the conversion goes from a specialized type to a less specialized one, and so the specialized type can provide an alias this returning the less specialized type.

However, given that this code compiles and works perfectly:

void baz() {
    import std.typecons;
    Tuple!(int, int) a;
    Tuple!(int, "x", int, "y") b;
    a = b; // Implicit conversion to less specialized type.
    b = a; // Implicit conversion to more specialized type.
}

It is clear that this limitation is not universal.

Solution

I propose that the functionality of opImplicitCastFrom be added to the language in the following form:

• When a value is returned from a function with a return type different from the returned value (e.g Foo fun() { Bar bar; return bar; }):
  • First attempt alias this.
  • If alias this fails, rewrite return bar; to return Foo.opImplicitCastFrom(bar);
  • If no match is found, give a compilation error.

• When a value is attempted assigned to a variable of a type different from that of the value (e.g. Foo foo; Bar bar; foo = bar;):
  • First attempt opAssign.
  • If opAssign fails, rewrite foo = bar; to foo = Foo.opImplicitCastFrom(bar);
  • If no match is found, give a compilation error.

• When a value is given as the sole argument to a constructor of a different type (e.g. Bar bar; Foo foo = bar;):
  • First attempt alias this.
  • If alias this fails, attempt constructor as per usual.
  • If constructor fails, rewrite foo = bar; to foo = Foo.opImplicitCastFrom(bar);
  • If no match is found, give a compilation error.

• When a value is an argument in a function call, and there's more than one function in the overload set (e.g. foo(bar, baz)):
  • First attempt regular overloading.
  • If no match is found, attempt to rewrite each subset of parameters where the type has defined opImplicitCastFrom to ExpectedType.opImplicitCastFrom(passedValue). This has a complexity (number of functions in overload set)*2^^(number of parameters that define opImplicitCastFrom)
  • If no match is found, give a compilation error.

Use cases

When defining a type it is often desirable to have some implicit conversion. An example currently being discussed on the forum is Option!T. With opImplicitCastFrom, the following would be made possible:

Option!T foo(T)(bool select, T value) {
    if (select) {
        return value;
    } else {
        return none;
    }
}

void bar(Option!int value) {}

bar(4);

std.complex is scheduled to replace built-in complex numbers. For it to be a full replacement, some new implicit conversions are necessary:

void foo(Complex!float arg) {}

foo(32.15);

Complex!int bar() {
    return 3;
}

For tagged unions (std.variant.Algebraic), the very same behavior is wanted:

void foo(Algebraic!(float, string, int, MyStruct) arg) {}

foo(32.15);
foo(12);
foo("empty string. No, really!");
foo(MyStruct(14, "foo"));

Algebraic!(int, string) bar() {
    return ""; // Actually empty string.
}

When a function's signature changes, and the changes are to a type for which an instance of the original type would be a valid value, no rewriting of calling code is needed:

// Was void foo(int n) {}
void foo(Nullable!int n) {}

foo(13);

// Was void bar(string arg) {}
void bar(Algebraic!(int, string) arg) {}

bar("testString");

Copyright

This document has been placed in the Public Domain.