Which language constructs could be done as a library if we accept some breaking changes?

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Mon Nov 29 14:57:04 UTC 2021


On Monday, 29 November 2021 at 13:22:34 UTC, Nick Treleaven wrote:
> On Monday, 29 November 2021 at 13:11:47 UTC, Alexandru Ermicioi 
> wrote:
>> But isn't a slice basically a struct with pointer and length?
>> Therefore you can consider that a slice is never null, but 
>> rather internal ptr field is, while length is 0.
>> The assoc array could follow same logic, i.e. point to null 
>> node.
>
> For slices we could just stop supporting null and require `[]` 
> instead, but I expect it would break quite a lot of code. For 
> AAs, `null` is part of its design as a reference type. I'm not 
> sure how you would get around that elegantly.

Yes, that would make a lot of sense.

Or you could make the current behaviour more general and add 
support for "dependent typing" of null-pointers.

So, this would work like this: you can specify that an operator 
is "value dependent", meaning there are two or more 
implementations that will be selected based on the value of the 
argument.

Is this sufficient to cover the current implementation?



More information about the Digitalmars-d mailing list