On 17/01/2024 3:42 AM, ikod wrote:
> On Tuesday, 16 January 2024 at 10:13:15 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>> I'd start from defining event loop API to decouple interface from implementations.
>>
>> I have done this in the past. You end up defining the user experience in the process.
>>
>> Unless you go out of your way with something like coroutines, or fibers, you're pretty much stuck with callbacks of some kind and that is not going to fly.
> 
> I had no problems implementing a common API for select, poll, epoll, kqueue event loops (never tried Linux io-uring or Windows completion ports). This API can be declared and used for independent implementations of current and future OS event systems.
> 
> On top of this implementations for tasks, timeouts, and so on can be created.
> 
> Are there any reasons why this won't work?

You may have misunderstood me.

I suggested to design the user experience first, and only then build the event loop itself to fulfill its needs.

Anything other than that, will produce undesirable user experience because you did not intentionally design it. It was shoehorned on to the implementation of the event loop (which is the wrong way round).

On Tuesday, 16 January 2024 at 10:33:13 UTC, Dibyendu Majumdar wrote:
> On Tuesday, 16 January 2024 at 00:14:50 UTC, GrimMaple wrote:
>>
>>> P.S. We also have some contributors who have a long track record of superb contributions. They also have a consistent commitment to promptly fixing anything that goes wrong with it down the road. Yes, they get a lot less scrutiny. They've earned it.
>> Care to give a few names?
>>
>
> What is your contribution to D?
>
> As Walter says forks are good. But please go work on your fork and make it great, rather than complaining here.
>
> If OpenD is good, it will be good competition to D and help spur things. But on the other hand, it requires full time dedicated & knowledgeable people to maintain a language, so it remains to be seen whether anything comes out of the fork.

Yet another person telling "don't complain, just do things", I got tired from these, nothing works that way. Complaining is needed for improve.

> What is your contribution to D?

The fork, OpenD is pretty enough, contribution doesn't have to be directly change in original code.

> But please go work on your fork and make it great, rather than complaining here.

Do you think all people do here is just sit and complain? Do you even check OpenD's codebase for updates?

On Tuesday, 16 January 2024 at 02:33:32 UTC, Mike Shah wrote:
> On Tuesday, 16 January 2024 at 01:37:40 UTC, claptrap wrote:
>> On Tuesday, 16 January 2024 at 01:11:16 UTC, Mike Shah wrote:
>>> [...]
>>
>> yeah but D pretty much only has to get Walter and Atila to agree on it. It's not like there's vast amount of stakeholders, or committee members that you need to get on board like with C++.
>>
>> It should actually be an advantage for D but somehow its not.
>
> Pros and cons I imagine to that that, though I'm not trying to push any DIPs,
>
> I think we also need to think about how to grow the team and get them more help. Many other language foundations have money behind them to back a few full-time developers.

And it didn't fly down from the sky. Donors are humans too so without a social side to D management, your aren't getting much financial support either. Most open source projects (Gnome, Linux, Rust, PHP, Node.js, Gimp, Inkscape, Krita, ...)  have ways to draw support and funding. We only have niche Dconf which has only been about code, the other equally important part of any foundation is severely lacking.


I'll do what I
> can on advocacy around D, because I think it's a wonderful language and community -- that's why we're all here! :)

👍

On 1/16/2024 12:23 AM, Richard (Rikki) Andrew Cattermole wrote:
> However on that topic, I was going to do a Unicode talk for DConf Online this year, but alas that kinda depended upon UAX31 identifiers, and you haven't been too keen to approve that line of work so I haven't done it.

I have actually approved it. My mistake it was not properly communicated to you.


> Anyway regarding my stuff, a lot of the lessons learned from it have gone into other work like PhobosV3 and Paul's work on allocators. Its going to show up at DConf at some point I expect.

Good

> Now if only I could convince you about having reference counting... that's another lesson that came from it. Good chance I'm going to have to drop DIP1000/scope if that cross behavior isn't resolved tbh. I can bare the pain, but I can't ask others to.

We've investigated ref counting several times, but never figured out a way to make it both efficient and memory safe.

In general, we've been much more willing to accept PRs that we can back out of if they don't turn out well.

For example, improvements to debug support, better code generation, stdatomic.d, fixing bugs, adding statistics to dmd's output, things like that.

Language changes, though, have a much higher bar. The risk there is people rely on it, and then we're stuck with it forever.

For example, `alias this` for classes. The semantics of it were never defined properly, and with many attempts at figuring what the correct semantics must be, never found one that anybody could defend. Worse, many people were using it for classes, and and relied on whatever the compiler did for it.

Hence, we did not want to deprecated it. Instead, we froze its current behavior, and I opposed any further additions to it and/or attempts to fix it. All I can do is just recommend people not use `alias this` in classes.

Rikki's proposal to do UAX31 identifiers I was initially opposed to, but upon reflection realized there was more risk in not doing it than doing it, and so full speed ahead, Rikki!