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

[Alexandru Ermicioi]

On Monday, 29 November 2021 at 12:47:35 UTC, Nick Treleaven wrote:
> On Monday, 29 November 2021 at 11:34:41 UTC, bauss wrote:
>> Pretty much anything can be solved in a library, except for 
>> things that requires AST/macros.
>
> There is no way to implicitly convert from other types 
> (particularly built-in types) to a struct, and I think Walter 
> is opposed to introducing that. This means no null -> Slice or 
> null -> AA and other implicit conversions.

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.

any ops could then be implemented in terms of operator 
overloading.

I mean, the purpose of operator overloading was added to allow 
user types to simulate built in ones, but what if this is 
inverted?
i.e. have the slices, arrays and aas, be implemented using 
structs with operator overloading for defining their behavior. 
This imho should make the compiler code and arch more decoupled 
and easy to manage compared to current situation. i.e. you won't 
need all tightly coupled magic hook for aas, arrays, etc. and 
could focus on improving operator overloading to support built in 
types behavior (not talking about classes here).