On Saturday, 20 May 2023 at 20:41:31 UTC, Richard (Rikki) Andrew Cattermole wrote:

>
> It makes a lot of sense looking at it in hindsight.
>
> The GC is just a fancy pants memory allocator after all.
>
> So the fact that we use the "GC language extensions" in CTFE is kinda irrelevant. It could just as easily work with malloc + free if somebody wanted to implement it.

Translation of Walters claim:

CTFE is much easier when you don't need to worry about life times.

A follow up question is if it would be just as easy with a GC based on RAII.

On Saturday, 20 May 2023 at 20:32:02 UTC, Walter Bright wrote:
>
> ImportC didn't go through the DIP process because it is not a D language feature - it's a compiler feature!

Even for the compiler, a new feature as significant as ImportC - that can have a profound effect on the 'use' of the language - should have gone through some process...at least.. before finding its way into the official source code respository.

Not to mention all the time and attention that has been directed to it as well, by so many people, including yourself, likely at the expense of other things. Sure, some would find the feature useful, I guess, but most people had to direct their attention to it because it just appeared and had to be dealt with.

'some kind' of approval process should have been followed (in relation to ImportC).

That seems self-evident to me.

I'm still bewildered why it's not self-evident to you as well.

On Monday, 22 May 2023 at 06:22:02 UTC, FeepingCreature wrote:
>
> I think people are modelling the DIP process as a "democratization" of the language. This is simply not the case. (And thank goodness!) For instance, there would be little point in having Walter file a DIP, as Walter is the person who decides whether to accept DIPs. What's he gonna do, reject his own feature?

That's very misleading. I never suggested using the DIP for ImportC.

That probably would not have made sense at the time, nor now.

Given that impact ImportC would have on both the compiler, the broader use of ImportC, and the level of attention that both would subsequently require by maintainers/contributerts, it could have been brought up at one of their meetings, and discussed, instead of just appearing one day in the source tree as a PR with little significance, just wanting approval.

I accept that Walter holds a unique position, and I respect that as well.

But in the end, Walter is not the only one who has to deal with the addition of ImportC into the compiler, or the widespread use of ImportC. I think that is what he failed to contemplate at the time. I hope such a thing would not happen again. Of course, I also hope that those at these 'meetings' have come up with a way to ensure it doesn't happen again.

On 27/05/2023 1:28 AM, Max Samukha wrote:
> On Friday, 26 May 2023 at 12:42:41 UTC, FeepingCreature wrote:
>> Go is an unusually atrocious implementation. In a not terrible language, it just looks like `foo()?.bar()?.baz`.
> 
> The whole point of exceptions was to remove that kind of syntactic noise. I still don't understand why people want to throw away the convenience instead of fixing problems it has.

Replacement of the exception mechanism does not imply replacing exception syntax.

You can still have throw/try/catch syntax and use sumtypes to return a value or exceptions structs.

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