Why is D unpopular, redux.
Timon Gehr
timon.gehr at gmx.ch
Sat May 21 11:39:06 UTC 2022
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`.
More information about the Digitalmars-d
mailing list