| |
 | Posted by Richard (Rikki) Andrew Cattermole in reply to Lance Bachmeier | Permalink Reply |
|
Richard (Rikki) Andrew Cattermole 
Posted in reply to Lance Bachmeier
| On 22/06/2025 3:06 AM, Lance Bachmeier wrote:
> On Friday, 20 June 2025 at 18:15:17 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> I've gone back to the drawing board on sumtypes, and I had some ideas yesturday based upon feedback from the last couple of years.
>
> It would be useful to include a comparison with std.sumtype. Explicitly state the new functionality this enables and the improvement in cases it overlaps.
std.sumtype has to work around a lot of problems in the type system, that will continue to exist.
It can't introduce new concepts like naming, although I'm wondering if that should go (which I hate having to do).
Making it first class is also a win for usability.
I've thought about it, however this isn't a full DIP just enough to evaluate it, and I've already found a couple things that I want to explore.
>> void main() {
>> Animal animal = Animal(Cat());
>>
>> animal.dog = Dog();
>> cast(Cat)animal = Cat();
>>
>> writeln(cast(Cat)animal);
>>
>> animal.None = true;
>> assert(animal is None);
>> }
>>
>> void someFunc(Animal animal) {
>> import std.stdio;
>> writeln(animal.tag); // some hash number
>> }
>> ```
>
> Could it do this?
>
> ```
> double fun(Dog d) {
> // Operations specific to Dog
> }
>
> double fun(Cat c) {
> // Operations specific to Cat
> }
>
>
> auto a1 = Animal(Cat());
> fun(a1);
>
> auto a2 = Animal(Dog());
> fun(a2);
> ```
>
> Just one example where this is useful is with dates. You might have an int, two ints, or a string. Handling those cases with templates or structs is less than an optimal experience in terms of verbosity, ugliness, and complexity.
No.
Modifying overload and symbol resolution to understanding matching like this would make Walter a very unhappy person. He already complains about how complex it is.
I for one do not wish to poke that nest of problems that is symbol resolution.
|