On Fri, Jan 12, 2024 at 03:13:58AM +0000, Guillaume Piolat via Digitalmars-d wrote:
> On Friday, 12 January 2024 at 01:21:32 UTC, H. S. Teoh wrote:
> > 
> > The only way a library author can deal with this mess is (1) write in the most restricted language subset, i.e., betterC + @nogc, so that it's usable by everybody. But the GC crowd will be unlikely to use it, because it will lack the conveniences they're accustomed to, the API will have manual memory management paraphrenalia that doesn't fit well with the rest of user code. Plus this is also a much higher bar for the library author, so you're further limiting the already small number of people who are writing D libraries.  Or (2) be opinionated and write a GC-using library, in which case the betterC / @nogc people won't use it.  Either alternative leads to ecosystem fragmentation. Or write a @nogc library but the betterC people won't use it.  Etc..
> > 
> 
> Interesting post thanks. Describes the situation very well.
> I think more escape hatches (@localnogc?) may help with the delegate
> situation you related.

Escape hatches is not the answer.  What we need is (1) a consistent way of enabling/disabling an attribute, and (2) a way of treating them as first-class citizens, i.e., be able to express "this delegate's attributes is equal to the attributes of the parent function".  Timon already described this, I won't repeat the details.


T

-- 
Doubtless it is a good thing to have an open mind, but a truly open mind should be open at both ends, like the food-pipe, with the capacity for excretion as well as absorption. -- Northrop Frye

On 1/11/2024 4:57 PM, zjh wrote:
> You don't need to `hire` anyone, you just need to carefully explain the `structure` of the `'dmd'` code, and then list `countless tasks`. Similarly, `break down` the big tasks into `small ones`. Create a list that `every user` can see, and then create an `incentive mechanism`!


We do have a task list:

https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&list_id=246714&order=Bug%20Number&query_format=advanced

On 1/11/2024 3:05 PM, Timon Gehr wrote:
> The issue is, sometimes the piece of code that accepts lambdas is entirely unopinionated about what the right attributes are, but the callback and the calling code have a very strong opinion. There is no way to annotate this now that makes sense, you have to duplicate the code with different attribute annotations. I am not sure exactly how many overloads of `opApply` you need to cater to all use cases, but I think it is more than ten.


opApply was itself a mistake, I'd prefer it to be removed, but alas. The better method is to use a lambda as a template alias parameter, and let the compiler infer the right attributes for it.

On 1/11/2024 5:21 PM, H. S. Teoh wrote:
> 	void registerCallback(void delegate() cb);
> 
> Problem: @safe code can't call this. @nogc code can't call this. BetterC
> code can't call it either.

```d
extern(C) void registerCallback(void delegate() cb)
{
    cb();
}

void boo()
{
    extern (C) void delegate() cb;
    registerCallback(cb);
}
```
compiles with -betterC

On 1/11/2024 5:21 PM, H. S. Teoh wrote:
> 	void registerCallbackSystem(void delegate() @system cb) @system;
> 	void registerCallbackSafe(void delegate() @safe cb) @safe;
> 	void registerCallbackNoGc(void delegate() @nogc cb) nogc;
> 	void registerCallbackSafeNoGc(void delegate() @safe @nogc cb) @safe@ nogc;

To make it work with both @safe and @system code, use @trusted.

To make code usable with both -betterC and regular D, just don't use the gc in it. No need to put @nogc in it.

On Friday, 12 January 2024 at 01:21:32 UTC, H. S. Teoh wrote:
> On Fri, Jan 12, 2024 at 12:42:44AM +0000, max haughton via Digitalmars-d wrote:
>> [...]
>
> Exactly, it's causing D's already-small ecosystem to be fragmented even more.
>
> [...]

I don't understand why a library author needs to satisfy everyone.

If part of an IO library API is @safe @nogc, for example, I'm expecting the author cared about avoiding allocation in that part and cared about being safe _following a specific design target_, and aiming to praise application _following a similar design target for IO_.

That doesn't align with other design? Well, it's simply impossible to reach all goals at the same time, it's better to have different solutions (aka libraries) for different philosophy, and it's easier also.

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.

/P

On Friday, 12 January 2024 at 02:21:10 UTC, Guillaume Piolat wrote:
> On Thursday, 11 January 2024 at 20:03:36 UTC, Paolo Invernizzi wrote:
>>
>> I've no ideas how you can have a list or external created pthreads without horrible hack like hooking pthread_create.
>>
>
>
> Ocaml is exactly like D with that: https://v2.ocaml.org/manual/intfc.html#ss:c-thread-register

Yeah, I think every language is in the same D boat, if it doesn't hook pthread_create.

On 12/01/2024 10:11 PM, Paolo Invernizzi wrote:
> On Friday, 12 January 2024 at 02:21:10 UTC, Guillaume Piolat wrote:
>> On Thursday, 11 January 2024 at 20:03:36 UTC, Paolo Invernizzi wrote:
>>>
>>> I've no ideas how you can have a list or external created pthreads without horrible hack like hooking pthread_create.
>>>
>>
>>
>> Ocaml is exactly like D with that: https://v2.ocaml.org/manual/intfc.html#ss:c-thread-register
> 
> Yeah, I think every language is in the same D boat, if it doesn't hook pthread_create.

Yes.

I couldn't find a way to do it when I was building my thread abstraction for linux.

Real shame, Windows solution with the 4 functions of DllMain in PE-COFF is briliant.