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?

On Saturday, 3 February 2024 at 03:19:00 UTC, Walter Bright wrote:

There's another way: Template parameter deduction. Just like IFTI infers template types from function call parameters, we could have a rule that if an eponymous template is assigned to something which has unambiquous type, that type is inferred for the variable, enum or function return value that is being assigned. Something like:

void fun(string);

T enum(T) enumT = /+...+/;
T funT(T)(T[]) => /+...+/;

fun(enumT); // fun(enumT!string)
fun(funT([])); // fun(funT(cast(string[]) []))

This would, as I understand it, mean that std.conv.to could be called without the template parameter when it is assigned to something with an unambiguous type: int x = 13.4.to;.