Thread overview
Is there any news about issue 5710?
Sep 19, 2022
victoroak
Sep 19, 2022
Ali Çehreli
Sep 19, 2022
Abdulhaq
Sep 20, 2022
Vladimir Panteleev
Sep 20, 2022
Sebastiaan Koppe
Sep 21, 2022
Tejas
Sep 21, 2022
Sebastiaan Koppe
September 19, 2022

From what I understand the fix was reverted but looking at the github discussion someone said they would take a look at how to do this but it passed some time after that and no news about this issue. I hit this issue the first day I tried D and it's sad to see that this is still open.

September 19, 2022
For convenience:

  https://issues.dlang.org/show_bug.cgi?id=5710

Ali


September 19, 2022
On Monday, 19 September 2022 at 16:57:55 UTC, Ali Çehreli wrote:
> For convenience:
>
>   https://issues.dlang.org/show_bug.cgi?id=5710
>
> Ali

The names in this thread read like a Who's Who of prominent dlang developers (past and present)
September 20, 2022

On Monday, 19 September 2022 at 16:27:21 UTC, victoroak wrote:

>

From what I understand the fix was reverted but looking at the github discussion someone said they would take a look at how to do this but it passed some time after that and no news about this issue. I hit this issue the first day I tried D and it's sad to see that this is still open.

I think the issue is really that D and the standard library should not have invested so much into using context-ful aliases for predicates, as they're inherently limited. Functors (which can be stateful and/or context-ful) are just better (though the D syntax isn't as good).

https://github.com/cybershadow/ae/blob/next/utils/pred/algorithm.d

September 20, 2022

On 9/20/22 12:04 PM, Vladimir Panteleev wrote:

>

On Monday, 19 September 2022 at 16:27:21 UTC, victoroak wrote:

>

From what I understand the fix was reverted but looking at the github discussion someone said they would take a look at how to do this but it passed some time after that and no news about this issue. I hit this issue the first day I tried D and it's sad to see that this is still open.

I think the issue is really that D and the standard library should not have invested so much into using context-ful aliases for predicates, as they're inherently limited. Functors (which can be stateful and/or context-ful) are just better (though the D syntax isn't as good).

https://github.com/cybershadow/ae/blob/next/utils/pred/algorithm.d

I agree with this. Perhaps having versions of algorithms which don't use aliases but rather functors would be a good addition?

It goes beyond just the dual-context problem. Functors don't need to allocate closures.

-Steve

September 20, 2022

On 9/20/22 12:14 PM, Steven Schveighoffer wrote:

>

On 9/20/22 12:04 PM, Vladimir Panteleev wrote:

>

On Monday, 19 September 2022 at 16:27:21 UTC, victoroak wrote:

>

From what I understand the fix was reverted but looking at the github discussion someone said they would take a look at how to do this but it passed some time after that and no news about this issue. I hit this issue the first day I tried D and it's sad to see that this is still open.

I think the issue is really that D and the standard library should not have invested so much into using context-ful aliases for predicates, as they're inherently limited. Functors (which can be stateful and/or context-ful) are just better (though the D syntax isn't as good).

https://github.com/cybershadow/ae/blob/next/utils/pred/algorithm.d

I agree with this. Perhaps having versions of algorithms which don't use aliases but rather functors would be a good addition?

It goes beyond just the dual-context problem. Functors don't need to allocate closures.

Looking closer at the examples there, I think this is far superior -- and provides the same possibilities as using the alias, with the pred template.

A worthy thing to look at for phobos v2 (if that ever happens)

-Steve

September 20, 2022

On Tuesday, 20 September 2022 at 16:04:25 UTC, Vladimir Panteleev wrote:

>

On Monday, 19 September 2022 at 16:27:21 UTC, victoroak wrote:

>

From what I understand the fix was reverted but looking at the github discussion someone said they would take a look at how to do this but it passed some time after that and no news about this issue. I hit this issue the first day I tried D and it's sad to see that this is still open.

I think the issue is really that D and the standard library should not have invested so much into using context-ful aliases for predicates, as they're inherently limited. Functors (which can be stateful and/or context-ful) are just better (though the D syntax isn't as good).

https://github.com/cybershadow/ae/blob/next/utils/pred/algorithm.d

Agreed. Your pred looks a lot like lambdas that capture by value.

As for ranges, they should be redesigned because of the priming problem (and others).

September 21, 2022

On Tuesday, 20 September 2022 at 20:29:21 UTC, Sebastiaan Koppe wrote:

>

On Tuesday, 20 September 2022 at 16:04:25 UTC, Vladimir Panteleev wrote:

>

On Monday, 19 September 2022 at 16:27:21 UTC, victoroak wrote:

>

[...]

I think the issue is really that D and the standard library should not have invested so much into using context-ful aliases for predicates, as they're inherently limited. Functors (which can be stateful and/or context-ful) are just better (though the D syntax isn't as good).

https://github.com/cybershadow/ae/blob/next/utils/pred/algorithm.d

Agreed. Your pred looks a lot like lambdas that capture by value.

As for ranges, they should be redesigned because of the priming problem (and others).

I'm sorry, what is the priming problem? Google isn't helping 😓

And what are the other problems with ranges?

September 21, 2022

On Wednesday, 21 September 2022 at 02:42:02 UTC, Tejas wrote:

>

I'm sorry, what is the priming problem? Google isn't helping 😓

And what are the other problems with ranges?

I came up with the term, it refers to the fact that it is not always clear where to prime a range.

Ideally you have empty be const, but in a lot of cases that is an ideal place to prime the range.

You can do it in the constructor as well, but that can come at the cost of laziness.


As for other problems, there is an issue with attribute inference in combination with type erasure, effectively making all range interfaces (like std.range.interfaces.ForwardRange) have @system members.

I remember people complaining about cornercases with ref ranges as well.