June 22
On 22/06/2025 12:58 AM, MrSmith33 wrote:
> On Friday, 20 June 2025 at 18:15:17 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> The tag is a hash of the fully qualified name of the type + name.
> 
> * What happens in the case of collision?
> * Can collision be detected at compile-time?

I see no reason it can't be detected.

However in practice the hash is so large compared to the elements in the set, that the chances of it hitting something when AA's don't is pretty low.

June 22
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.

June 23

On Saturday, 21 June 2025 at 20:01:13 UTC, Richard (Rikki) Andrew Cattermole wrote:

>

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

The only reason std.sumtype can't introduce naming is due to backward compatibility requirements. In principle, there is nothing stopping a library sum type from having named members.

1 2
Next ›   Last »