• victoroak (5/5) Sep 19 2022 From what I understand the fix was reverted but looking at the
• =?UTF-8?Q?Ali_=c3=87ehreli?= (3/3) Sep 19 2022 For convenience:
• Abdulhaq (3/6) Sep 19 2022 The names in this thread read like a Who's Who of prominent dlang
• Vladimir Panteleev (7/12) Sep 20 2022 I think the issue is really that D and the standard library
• Steven Schveighoffer (6/20) Sep 20 2022 I agree with this. Perhaps having versions of algorithms which don't use...
• Steven Schveighoffer (6/27) Sep 20 2022 Looking closer at the examples there, I think this is far superior --
• Sebastiaan Koppe (5/17) Sep 20 2022 Agreed. Your pred looks a lot like lambdas that capture by value.
• Tejas (4/20) Sep 20 2022 I'm sorry, what is the priming problem? Google isn't helping 😓
• Sebastiaan Koppe (14/16) Sep 21 2022 I came up with the term, it refers to the fact that it is not

victoroak <jackpboy gmail.com> writes:

 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.

=?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:

For convenience:

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

Ali

Abdulhaq <alynch4048 gmail.com> writes:

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)

Vladimir Panteleev <thecybershadow.lists gmail.com> writes:

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

Steven Schveighoffer <schveiguy gmail.com> writes:

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

Steven Schveighoffer <schveiguy gmail.com> writes:

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

Sebastiaan Koppe <mail skoppe.eu> writes:

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).

Tejas <notrealemail gmail.com> writes:

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?

Sebastiaan Koppe <mail skoppe.eu> writes:

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.