Why is D unpopular, redux.

[Timon Gehr]

On 21.05.22 05:45, Walter Bright wrote:
> On 5/20/2022 4:28 AM, deadalnix wrote:
>> I'd like to remind everybody of a simple fact: it is impossible to 
>> write a high quality generic container in D, right now. This is 
>> because there is no way to explain to the compiler that a `const 
>> Vector!T` is the same as a `const Vector!(const T)`.
> 
> I don't recall anyone ever bringing it up before.

I brought it up a number of times. ;) I think the last time was here:
https://forum.dlang.org/post/sk4v9b$2apt$1@digitalmars.com

deadalnix has also talked about this multiple times over the years.

> Glad you did.
> 
> Want to write a proposal for it?

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