implicit construction operator

[aliak]

On Monday, 26 February 2018 at 19:32:44 UTC, ketmar wrote:
> WebFreak001 wrote:
>
>> Now before you would have only been able to do this:
>>
>> ---
>> Nullable!Foo a;
>> foo(a, Nullable!int(5));
>> ---
>>
>> but now you should also be able to do:
>>
>> ---
>> Nullable!Foo x = null;
>> Nullable!Foo y = 5;
>>
>> foo(null, 5);
>
> please no. such unobvious type conversions goes out of control 
> really fast. there is a reason why D doesn't have such thing, 
> this is not an oversight, but a design decision.

How if you don't mind me asking? Seems like many features can go 
out of control if used incorrectly, but that doesn't mean they're 
a bad idea. I can understand they're a slippery slope, but it 
seems some people think it's a completely bad idea.

It makes libraries *much* more intuitive and expressive (C++ just 
got it wrong by choosing the wrong default). If you allow library 
authors to opt in instead of opt out then it becomes a conscious 
decision for one.

But at the very least, shouldn't we put some thought in to 
allowing it for inherent sub-type relationships. Where an alias 
this is used, there's probably such a relationship. BigInt to int 
is another one. Algebraic types as mentioned falls under that 
category as well.

And if that's also a no no, how about char -> int. Or int -> 
float? Is ok?

Maybe there're some valid arguments, to disallow it *completely* 
though?

Cheers