On Friday, 12 January 2024 at 15:18:48 UTC, H. S. Teoh wrote:
> On Fri, Jan 12, 2024 at 09:02:24AM +0000, Paolo Invernizzi via Digitalmars-d wrote:
>> I don't understand why a library author needs to satisfy everyone.
> [...]
>
> They don't.  They cater to their own use case, leaving everybody else out.  That's why D's library ecosystem is fragmenting.  That was the point: things like @nogc, betterC, etc., are fragmenting the ecosystem.
>

This. Indeed, you can't expect people to bend over backward to accommodate everybody's use case. But, to grow an ecosystem, you want that one person catering to their own use case to, by default, cater to as many people's use case as possible.

Feature that work against this create a maintenance nightmare.

On Saturday, 13 January 2024 at 19:22:53 UTC, claptrap wrote:
>>> I'm saying I dont see lots of people who are confused about nogc.
>>
>> I see people who confuse it with an imaginary `@noAlloc` on a regular basis.
>
> What is it that they expect it to do?

Prevent allocations (e.g. in the hot paths of their code).

On Sunday, 14 January 2024 at 05:08:07 UTC, Elias (0xEAB) wrote:
> On Saturday, 13 January 2024 at 19:22:53 UTC, claptrap wrote:
>> What is it that they expect it to do?
>
> Prevent allocations (e.g. in the hot paths of their code).

Or prevent collections (which would be GC.disable(), in fact).

On Friday, 12 January 2024 at 01:21:32 UTC, H. S. Teoh wrote:
>
> Now instead of one library that works for all D code, you have libraries that use the GC so they're incompatible with betterC and @nogc projects, libraries that don't use GC but still use some D feature not in betterC, so the betterC people are left out, then you have @nogc libraries that the GC crowd wouldn't use because it requires you to pass allocators and all the rest of the spam associated with manual memory management.

I wonder how many people actually willingly use betterC. I feel like WASM is the main usecase for betterC, and if WASM worked in "normal D mode" betterC would mostly fade into obscurity for special cases when you need to interop with existing C code.

On Sunday, 14 January 2024 at 05:08:07 UTC, Elias (0xEAB) wrote:
> On Saturday, 13 January 2024 at 19:22:53 UTC, claptrap wrote:
>>>> I'm saying I dont see lots of people who are confused about nogc.
>>>
>>> I see people who confuse it with an imaginary `@noAlloc` on a regular basis.
>>
>> What is it that they expect it to do?
>
> Prevent allocations (e.g. in the hot paths of their code).
>
> or prevent collections (which would be GC.disable(), in fact).

So it's not that @nogc is hard to understand. It's that some newbies dont understand how GC works.

Maybe we should go through D.learn and find the top 3 features that confuse newbies and kill them. I wonder what they'd be?

On 1/11/2024 5:11 PM, zjh wrote:
> A very simple example is a user, like me, who really wants a `C++ class level private`. This' private 'can be achieved by adding a `keyword`, you only need to add one keyword, and then implement the corresponding function. Then, you get a bunch of `potential C++ users`. But `D` team refuse this `pr` , the user leaves. Originally, it could bring a bunch of its friends to enter D. In the end, D loses all and has nothing. There is `no function`, There are `no D users`.

What is the criteria for if a feature should be merged or not? I cannot think of one where somebody isn't going to be unhappy about the result.

For example, there are D users who want the GC removed from the language, and another group that want D focused on the GC. We have attempted to embrace both sets of users with BetterC, but there are people still unhappy with that.

It reminds me of a story my dad told me. He talked to the mayor of the small town he lived in, and asked the mayor "what's your biggest problem in managing the town?" The mayor replied "there are two groups of people - those who like dogs, and those who do not. They are each roughly half of the population. There is no reconciliation between those two groups. It's constant friction."

On 1/12/2024 1:02 AM, Paolo Invernizzi wrote:
> BTW, that's also because I'm skeptical about the success of editions, you can't have _everything_ in the compiler, and at the same time expect to have it simple and manageable. I'm expecting a big grow in complexity.

That is indeed a risk. We're going to have to be careful with that.