February 16

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.


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?

February 19

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


C++ has this, implicit conversion of structs. It looks great with simple cases. However, as overloading gets more complex, it becomes a source of mass confusion. I've had many C++ programmers tell me that nobody actually knows how C++ overloading works - they just try random things until they get the result they want. There was a lot of talk in the 90s about implicit conversion being a mistake, but by then it was too late and C++ has had to learn to live with it.

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;.

1 2 3 4 5
Next ›   Last »