Do you have any plans to support implicit conversion between types?

I have some code like this:

struct Foo
{
	this(int i)
	{
		//do something useful
	}
}

void bar(Foo f)
{
	//do something else
}

void main()
{
	Foo f = 5;//works
	
	bar(f);//works
	
	bar(Foo(5));//works
	
	bar(5);//Error: function app.bar (Foo f) is not callable using
argument types (int)
}

So, D can't use constructor to convert "int" to "Foo" implicitly.
Can we add "implicit" keyword to allow do this:

struct Foo
{
	implicit this(int i)
	{
		//do something useful
	}
}

C++ allows this, but have "explicit" keyword.
C# doesn't allow this, but have operator overloading for both implicit and explicit cases.

Am 06.09.2013 12:33, schrieb ilya-stromberg:
> Do you have any plans to support implicit conversion between types?
>
> I have some code like this:
>
> struct Foo
> {
>      this(int i)
>      {
>          //do something useful
>      }
> }
>
> void bar(Foo f)
> {
>      //do something else
> }
>
> void main()
> {
>      Foo f = 5;//works
>
>      bar(f);//works
>
>      bar(Foo(5));//works
>
>      bar(5);//Error: function app.bar (Foo f) is not callable using
> argument types (int)
> }
>
> So, D can't use constructor to convert "int" to "Foo" implicitly.
> Can we add "implicit" keyword to allow do this:
>
> struct Foo
> {
>      implicit this(int i)
>      {
>          //do something useful
>      }
> }
>
> C++ allows this, but have "explicit" keyword.
> C# doesn't allow this, but have operator overloading for both implicit
> and explicit cases.

I also made almost the same suggestion some time ago. I would support a feature like this.

-- 
Kind Regards
Benjamin Thaut

On Friday, 6 September 2013 at 10:33:07 UTC, ilya-stromberg wrote:
> Do you have any plans to support implicit conversion between types?

Implicit conversions open up a whole can of worms for the sake of a small amount of convenience.

I'm not sure it's a fair trade.

On Friday, 6 September 2013 at 11:04:31 UTC, Peter Alexander wrote:
> Implicit conversions open up a whole can of worms for the sake of a small amount of convenience.
>
> I'm not sure it's a fair trade.

Agreed. It was quite common source of troubles in my C++ days and have never offered much convenience.

Am 06.09.2013 13:27, schrieb Dicebot:
> On Friday, 6 September 2013 at 11:04:31 UTC, Peter Alexander wrote:
>> Implicit conversions open up a whole can of worms for the sake of a
>> small amount of convenience.
>>
>> I'm not sure it's a fair trade.
>
> Agreed. It was quite common source of troubles in my C++ days and have
> never offered much convenience.

Its only a source of troubles in C++ because it is the default behavior. But if you design a library it can make the usage of your api easier and also you have a few more options to stay backwards compatible with your old api.

On Friday, 6 September 2013 at 11:04:31 UTC, Peter Alexander wrote:
> On Friday, 6 September 2013 at 10:33:07 UTC, ilya-stromberg wrote:
>> Do you have any plans to support implicit conversion between types?
>
> Implicit conversions open up a whole can of worms for the sake of a small amount of convenience.
>
> I'm not sure it's a fair trade.

I think we should be able to do it, but in unconvenient ways.

Like alias this + a property.

Am 06.09.2013 13:44, schrieb deadalnix:
> On Friday, 6 September 2013 at 11:04:31 UTC, Peter Alexander wrote:
>> On Friday, 6 September 2013 at 10:33:07 UTC, ilya-stromberg wrote:
>>> Do you have any plans to support implicit conversion between types?
>>
>> Implicit conversions open up a whole can of worms for the sake of a
>> small amount of convenience.
>>
>> I'm not sure it's a fair trade.
>
> I think we should be able to do it, but in unconvenient ways.
>
> Like alias this + a property.

But that doesn't work for construction. Also its not possible to do it for primitive types (especially string comes to mind)

On Friday, 6 September 2013 at 11:32:11 UTC, Benjamin Thaut wrote:
> Am 06.09.2013 13:27, schrieb Dicebot:
>> On Friday, 6 September 2013 at 11:04:31 UTC, Peter Alexander wrote:
>>> Implicit conversions open up a whole can of worms for the sake of a
>>> small amount of convenience.
>>>
>>> I'm not sure it's a fair trade.
>>
>> Agreed. It was quite common source of troubles in my C++ days and have
>> never offered much convenience.
>
> Its only a source of troubles in C++ because it is the default behavior. But if you design a library it can make the usage of your api easier and also you have a few more options to stay backwards compatible with your old api.

Totally agree. The default implicit conversion in C++ is a mistake.

The conversion must be explicit by default (like in D now).
The programmer should use implicit conversion ONLY IF IT SAFE (like ftom "int" to "long"). For any other cases programmer should use explicit conversion (default).

Actually, this simple rule comes from C#: it have explicit conversions by default and ability to explicitly add implicit conversion. And I never had problems with it.

On Friday, 6 September 2013 at 11:32:11 UTC, Benjamin Thaut wrote:
> Its only a source of troubles in C++ because it is the default behavior. But if you design a library it can make the usage of your api easier and also you have a few more options to stay backwards compatible with your old api.

It's not just that single arg constructors are by default implicit. Implicit conversions complicate things, like template argument deduction and overload resolution.

On Friday, 6 September 2013 at 11:32:11 UTC, Benjamin Thaut wrote:
> Its only a source of troubles in C++ because it is the default behavior. But if you design a library it can make the usage of your api easier and also you have a few more options to stay backwards compatible with your old api.

Probably. But what is the gain? `foo(Foo(5))` looks better than `foo(5)` to me in every possible way.

For example, use case that justifies operator overloading (despite the danger) in my eyes is ability to replace built-in types with custom ones. What is the similar rationale for implicit conversion?