Why is D unpopular, redux.

[deadalnix]

On Saturday, 21 May 2022 at 11:39:06 UTC, Timon Gehr wrote:
> Yes, probably needs a DIP. Seems somewhat tricky to get just 
> right. The mechanism should be simple and should e.g. allow the 
> wrapping of a built-in slice within a templated struct with the 
> same typing behavior.
>
> A pretty simple feature that seems to do the job would be 
> something like:
>
> ```d
> @structuralSubtyping
> struct Slice(T){
>     T[] payload;
> }
> ```
>
> Then whenever you need to evaluate a subtyping relationship 
> between multiple instantiations of the same 
> @structural-annotated templated type, you check that the field 
> layout matches (including field names) and that all field types 
> are subtypes of their new type.
>
> There should be a way to do custom introspection (subtype 
> constraints).
>
> ```d
> @structuralSubtyping!condition
> struct Slice(T){
>     T[] payload;
> }
> ```
>
> Where "condition" is passed both instantiated types with full 
> qualifiers and can do additional checks to possibly maintain 
> typing invariants that are not tracked by D's type system alone.
>
> There should also be an unsafe escape hatch to exclude certain 
> members from the automated field layout checks, but maybe void* 
> and void[n] are good enough for this.
>
> Finally, the magic "strip qualifiers when passing a slice to a 
> function" rule should be applied to template types with 
> `@structuralSubtyping`.

While this would allow to do the container thing, I do not 
believe this is the right way to go at it. It has an DIP "do the 
thing" flavor to it. I think not being able to do containers is a 
symptom of a missing piece in the type system, most notably type 
qualifier.

As far as I can tell, what's needed is a for of generics, at 
least for type qualifiers.

I don't pretend to have all the solutions, and I'm sure that the 
combined talent of the community can sort this out if, and that's 
a big if, we are willing to actually focus on what really matters 
here.