On 1/12/24 08:10, Walter Bright wrote:
> 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.

Well, I have wished for an `opApply` with template alias sometimes, but this does not always work. E.g., `opApply` may be a virtual function (which comprises quite a lot of my own `opApply` use cases). Anyway, `opApply` is just one example that happens to be particularly familiar to many D programmers. Do you think virtual methods and runtime delegates were a mistake in general?

On Fri, Jan 12, 2024 at 09:02:24AM +0000, Paolo Invernizzi via Digitalmars-d wrote:
> 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.
[...]

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.


T

-- 
Gone Chopin. Bach in a minuet.

On Friday, 12 January 2024 at 15:18:48 UTC, H. S. Teoh wrote:
>
> 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.

It does, but it's not like the cases where people want to use betterC or @nogc aren't valid, like claptrap said. A static guarantee is really helpful here all the time.

The most restricted sort of D can be used almost anywhere, such as the (pretty much un-D in spirit) nothrow @nogc no-exceptions betterC-compatible struct-only subset.
So in large parts it is possible to not fragment some of the low-level unopinionated libraries.

When this is done, the biggest issue left is plain old manual handling, as bad as ever.

The "true fix" for that is a druntime that can go anywhere in any situation (statically linked, with GC hooks) and this is it seems the call of "OpenD" afaik, but that's not what we have now.

Even if possible there are cases where you may just want a C runtime, such as was highlighted by the Mir project. Or Inochi2D planning to go @nogc for portability reasons. What's really new here is Hipreme being able to run a sizeable D subset with a custom runtime, that only requires no-exception AFAIK.

On 1/12/2024 3:02 AM, Monkyyy wrote:
> Ive seen poeple say a todo list with 10 items lack priorities, the bug list is very very very much longer.

The buglist is indeed very long. But it can be sliced and diced into subsets in many ways, such as by content, by severity, by keyword, etc.

It's not necessary to read it all, just read till you find something that you want to fix.

On 1/12/2024 6:54 AM, Timon Gehr wrote:
> Do you think virtual methods and runtime delegates were a mistake in general?

I don't like opApply() because it does a hidden rewrite of the statements in the function that makes the semantic analysis fragile, ugly and clumsy.

I'm a bit amazed it works at all :-/

Virtual methods and runtime delegates don't have this problem.

On Friday, 12 January 2024 at 20:49:36 UTC, Walter Bright wrote:
> On 1/12/2024 3:02 AM, Monkyyy wrote:
>> Ive seen poeple say a todo list with 10 items lack priorities, the bug list is very very very much longer.
>
> The buglist is indeed very long. But it can be sliced and diced into subsets in many ways, such as by content, by severity, by keyword, etc.
>
> It's not necessary to read it all, just read till you find something that you want to fix.

that will obviously lead to the wack-a-mole people complain about and will make matching your bug report to whatever search query you use be this silly game

On 1/12/24 21:52, Walter Bright wrote:
> On 1/12/2024 6:54 AM, Timon Gehr wrote:
>> Do you think virtual methods and runtime delegates were a mistake in general?
> 
> I don't like opApply() because it does a hidden rewrite of the statements in the function that makes the semantic analysis fragile, ugly and clumsy.
> 
> I'm a bit amazed it works at all :-/
> 
> Virtual methods and runtime delegates don't have this problem.

My own `opApply` implementation is relatively straightforward:

https://github.com/tgehr/d-compiler/blob/master/semantic.d#L8868-L8915
https://github.com/tgehr/d-compiler/blob/master/semantic.d#L9174-L9227
https://github.com/tgehr/d-compiler/blob/master/semantic.d#L9882-L9889
https://github.com/tgehr/d-compiler/blob/master/semantic.d#L9972-L9985
https://github.com/tgehr/d-compiler/blob/master/semantic.d#L10037-L10047
https://github.com/tgehr/d-compiler/blob/master/semantic.d#L10059-L10064