On Saturday, 21 May 2022 at 09:08:10 UTC, Dukc wrote:
> I believe, from what he said in other thread, that in his opinion D should bundle changes that require tooling updates so that they happen only once per every few years.
>
> I personally don't agree with that. I fear that having to wait for the biannual or so release day to have any significant language improvements released would frustate contributors. And it would drastically slow the feedback loop, with regards to experience with the new features.

I think maybe the better answer is, make tooling part of D's CI pipelines.

We have the project tester to make sure we don't break D projects, and it does a pretty good job. If we care about tooling, it stands to reason that we should have a tooling tester too.

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

On Saturday, 21 May 2022 at 03:55:41 UTC, Walter Bright wrote:
> On 5/20/2022 4:28 AM, deadalnix wrote:
>> What stroke me in there is that almost everybody is missing the point, but maybe that isn't so surprising, as there is a self selection bias at play.
>
> But you don't say what the point is!

I do. I have done so repeatedly for a decade now.

There are holes in the foundations of the languages. These hole prevent basic things from being possible at all. For instance, containers.

But the focus has consistently been on other feature which are nice to have. The problem, is that it doesn't matter how much nice to have things you have - and I'll grant you that D has more than most on this front - if there are holes in the foundations.

Lately, the focus has been on named argument, tuples, ImportC, and a few other things. All good things. There are a couple of these holes, but really, the limus test shoudl be: can i write a custom container class that behaves lice builtin slice do? If so, then we are probably in good shape. If not, then literally anything else we add to the language is a net negative as it increase complexity without tackling the bottleneck.

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.

On 5/21/2022 4:54 AM, deadalnix wrote:
> There are holes in the foundations of the languages. These hole prevent basic things from being possible at all. For instance, containers.


Ok, can you please provide a comprehensive list of these holes?

On 5/21/2022 4:39 AM, Timon Gehr wrote:
> https://forum.dlang.org/post/sk4v9b$2apt$1@digitalmars.com

That's a good list, thank you!


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

I'm afraid there's not enough here for me to understand it.

On 5/21/2022 6:02 AM, deadalnix wrote:
> We've got a ton of good stuff in D, but we keep adding more rather than making sure that what we have is really good.

I can't help but think this is a bit of a quixotic quest. In mathematics, of course, one strives for 100%. But in engineering, one goes for the 95% that is at the center, not the edges.

For example, ImportC can *never* be 100% for various reasons. That doesn't mean it can't still be immensely useful.

Windows isn't 100%, my iPhone isn't 100%, my car isn't 100%, etc. But they're still very usable.

There isn't any software in active use on the planet that is 100%, that's why there are endless updates to it.

We have only so many chips we can play. We can place them on fixing bugs, adding new stuff, improving old features, etc. I try to prioritize them by what is most effective for the most number of people. Inevitably, some people will find we choose wrongly.

All I can suggest is keep making a case for the things you want, and most importantly, *why* they are important.

On 5/21/2022 4:26 AM, Paul Backus wrote:
> We have the project tester to make sure we don't break D projects, and it does a pretty good job. If we care about tooling, it stands to reason that we should have a tooling tester too.

The project tester has indeed been very successful.

https://issues.dlang.org/show_bug.cgi?id=23133