On Thursday, 7 September 2023 at 18:31:10 UTC, ryuukk_ wrote:
>> Ideas for new features for D have been deferred for the time being
>
> This is the saddest thing ever, i've been waiting for tagged union / tuple since forever
>
> IVY = bureaucracy + religion, recipe for disaster, and we are already seeing the effects: the language is now in a deep freeze state

On a project of D's size and scope, there is no such thing as "no bureaucracy." The only choice is between explicit, formal bureaucracy that's been designed intentionally; and implicit, informal bureaucracy that's been designed by accident.

What we currently have is the implicit, informal kind of bureaucracy, which has all the disadvantages (hard to get things done) without any of the potential advantages (easy to keep track of what's being done and who's responsible). Moving away from this towards a more explicit system should be an easy win.

On Saturday, 9 September 2023 at 17:27:05 UTC, Paul Backus wrote:
> On Thursday, 7 September 2023 at 18:31:10 UTC, ryuukk_ wrote:
>>> Ideas for new features for D have been deferred for the time being
>>
>> This is the saddest thing ever, i've been waiting for tagged union / tuple since forever
>>
>> IVY = bureaucracy + religion, recipe for disaster, and we are already seeing the effects: the language is now in a deep freeze state
>
> On a project of D's size and scope, there is no such thing as "no bureaucracy." The only choice is between explicit, formal bureaucracy that's been designed intentionally; and implicit, informal bureaucracy that's been designed by accident.
>
> What we currently have is the implicit, informal kind of bureaucracy, which has all the disadvantages (hard to get things done) without any of the potential advantages (easy to keep track of what's being done and who's responsible). Moving away from this towards a more explicit system should be an easy win.

I don't buy any of this, this is just a way to distance yourself from the people who actually use the language and want to solve problems, what tools are in there for those who don't want to use EH/GC? nothing, does IVY has the answer? does IVY people know how to program in C, do they know what competition is doing?

Tuple DIP predates this IVY thing, what are the excuses

On Saturday, 9 September 2023 at 19:06:24 UTC, ryuukk_ wrote:
> On Saturday, 9 September 2023 at 17:27:05 UTC, Paul Backus wrote:
>>
>
> I don't buy any of this, this is just a way to distance yourself from the people who actually use the language and want to solve problems,

You seriously think that's what they are doing?

Why?

On Saturday, 9 September 2023 at 19:06:24 UTC, ryuukk_ wrote:
>
> Tuple DIP predates this IVY thing, what are the excuses

This is exactly my point. The Tuple DIP has been around for years under the pre-IVY system, with almost no progress. Clearly, the pre-IVY system is not doing a very good job here!

I have no attachment to IVY in particular, but we're going to have to try *something* new if we want things to change.

On Saturday, 9 September 2023 at 19:06:24 UTC, ryuukk_ wrote:
> On Saturday, 9 September 2023 at 17:27:05 UTC, Paul Backus wrote:
>> On Thursday, 7 September 2023 at 18:31:10 UTC, ryuukk_ wrote:
>>>> Ideas for new features for D have been deferred for the time being
>>>
>>> This is the saddest thing ever, i've been waiting for tagged union / tuple since forever
>>>
>>> IVY = bureaucracy + religion, recipe for disaster, and we are already seeing the effects: the language is now in a deep freeze state
>>
>> On a project of D's size and scope, there is no such thing as "no bureaucracy." The only choice is between explicit, formal bureaucracy that's been designed intentionally; and implicit, informal bureaucracy that's been designed by accident.
>>
>> What we currently have is the implicit, informal kind of bureaucracy, which has all the disadvantages (hard to get things done) without any of the potential advantages (easy to keep track of what's being done and who's responsible). Moving away from this towards a more explicit system should be an easy win.
>
> I don't buy any of this, this is just a way to distance yourself from the people who actually use the language and want to solve problems, what tools are in there for those who don't want to use EH/GC? nothing, does IVY has the answer? does IVY people know how to program in C, do they know what competition is doing?
>
> Tuple DIP predates this IVY thing, what are the excuses

For the moment EH is a problem, but it's known problem, and one that was discussed at length at DConf. From what I gathered Walter wants to move in the direction of a Herb Sutter style system where exceptions are returned up the stack silently via a shadow value in the return statement. It's actually a pretty elegant solution. It's not here now because of the pause, but it's coming because Walter wants it.

GC. Two points.

First there is @nogc and -vgc. Turn those on and the GC won't run. If your contention is that you want to use some parts of the language that use the GC, well, frankly, that's just too bad, your choices are either don't use those parts or submit a PR to rewrite those bits to not use the GC. Fortunately most of Phobos is available without the GC so I don't really see what the problem is.

Second, if your contention is that the GC *exists at all* and that's bad and it should be removed... I have bad news. I asked Walter whether or not he would ever sanction removing the GC and his answer was "Never. GC code is inherently memory safe code." which means that as memory safety is one of D's key selling points, the GC is here to stay. In fact there are efforts underway to improve the performance of the GC considerably.

Tools exist to disable the GC at runtime, if you don't want the GC, use them. The rest of us will happily go on using the GC and this is a non-issue.

On 10/09/2023 2:12 PM, Adam Wilson wrote:
> For the moment EH is a problem, but it's known problem, and one that was discussed at length at DConf. From what I gathered Walter wants to move in the direction of a Herb Sutter style system where exceptions are returned up the stack silently via a shadow value in the return statement. It's actually a pretty elegant solution. It's not here now because of the pause, but it's coming because Walter wants it.

I want it as well, and have done work towards it.

https://github.com/rikkimax/DIPs/blob/value_type_exceptions/DIPs/DIP1xxx-RC.md

It needs sumtypes to be a complete design, which is the current sticking point.

https://www.digitalmars.com/d/archives/digitalmars/D/D_has_become_unbearable_and_it_needs_to_stop_369162.html