What is the reasoning behind the lack of conversions when passing parameters

[Carl Sturtivant]

Further to the above, examination of the documentation of 
std.variant shows that it also contains the definition of an 
algebraic type `Algebraic` that has now been deprecated in favor 
of `SumType` in std.sumtype. Still, the intended purposes of 
std.variant are made clear both directly and by implication from 
what functionality is provided, and I strongly agree with those 
purposes.

https://dlang.org/phobos/std_variant.html

Specifically, `Algebraic` is (like `SumType`) for creating a type 
broadly speaking consisting of a finite number of alternative 
types, and `Variant` is a type whose alternatives are essentially 
the infinity of all types possible in D.

It has been recognized that a sum type cannot be defined in a 
library in a way that a value of one of the alternative types 
composing it can be passed as an argument to a function with a 
parameter of that sum type without an explicit conversion.

Similarly a function returning a value of such a sum type cannot 
return a value of one of the alternative types composing it 
without an explicit conversion.

Since the decision to disallow all implicit conversions via 
constructors in function calls and returns has been permanently 
made, the only option for a simple sum type is to be a part of 
the D language itself. How that interacts with overloading has 
then to be decided.

The exact same difficulties exist for Variant. So I am suggesting 
that for the same reasons that led to std.variant as a first shot 
at finite and an infinite sum type, that a replacement for 
Variant be added to the D language itself.

I don't purport to suggest the name of this new type, but propose 
a working name of `Any` for discussion purposes. How `Any` 
interacts with overloading then has to be decided. Since it is a 
language feature, this can be made quite restricted.

Surely there's a way that the target shot at by std.variant can 
at last be properly demolished?