On Friday, 20 May 2022 at 11:28:38 UTC, deadalnix wrote:
> On the other hand, this will yet again break many tools, setting the ecosystem back once again.

Yeah, it'll take like an hour to update our custom parsers.

On Friday, 20 May 2022 at 12:01:17 UTC, Tejas wrote:
> Isn't that a consequence of transitive const though?

No, it works for built-in arrays. Just the language doesn't let you express that for user-defined types.

There's a lot of little gaps the built-in things use magic to fill.

On 20/05/2022 11:28 PM, deadalnix wrote:
> Apparently, we are getting named argument soon. I have no opinion whether this is good or bad, I haven't even read he proposal. But I don't need to to know this is pretty bad for D, even if the proposal is really good.

As a previous author of a named parameter DIP, I can say its a good DIP but it doesn't solve a pretty important thing. The ability to access template parameters as if they were a member externally.

As Max discovered, its a lot of work to implement. So much technical debt and so little refactoring going on. Oh well.

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

The things that concern me wrt. data structures are:

I can't ``@disable const;`` and stop the outer type being able to become const. It is a lot of work to prevent it.

Why can't I support const? To iterate, you need to be able to mutate state. This includes an iterator (for concurrent iteration + mutation support). And of course reference counting.

For data structures, because they must be able to mutate state, const is effectively immutable. You can't know if the state is in read only memory or not. So the only thing you can do is throw up your hands and go, nope not my problem!

This of course becomes a pain if you need to return say a list of strings that was computed at the start of a program that will never change. But once you return it, anyone can change it. I'm now considering copy on write for them wholesale.

All this before we consider lifetime issues *sigh*.

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. Glad you did.

Want to write a proposal for it?

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!

On 21/05/2022 3:45 PM, Walter Bright wrote:
> I don't recall anyone ever bringing it up before. Glad you did.

Cross referencing:

https://forum.dlang.org/post/nnkuxoiawyvgyrnuesxu@forum.dlang.org

https://forum.dlang.org/post/umekbkvomyixeiksgzfd@forum.dlang.org

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