digitalmars.D.learn - Can someone explain to me the design choices for this function
- e-y-e (38/38) Sep 22 2016 The function in question is std.algorithm.searching's until [1].
- Lodovico Giaretta (12/16) Sep 22 2016 Runtime evaluation is more flexible. The reason to have
- e-y-e (7/11) Sep 22 2016 Ok, I suspected this might be the case. I might work on a pull
- Jonathan M Davis via Digitalmars-d-learn (5/9) Sep 22 2016 until predates Flag by a considerabl margin. And even after Flag was
The function in question is std.algorithm.searching's until [1]. Here are the definitions: Until!(pred, Range, Sentinel) until(alias pred = "a == b", Range, Sentinel) (Range range, Sentinel sentinel, OpenRight openRight = OpenRight.yes) if (!is(Sentinel == OpenRight)); and: Until!(pred, Range, void) until(alias pred, Range) (Range range, OpenRight openRight = OpenRight.yes); Now the first thing that came to mind was that it seemed odd to have openRight be a runtime flag instead of a compile-time flag. But that didn't hinder my usage of it, so I went ahead and called the function like so: range.until!(e => e > f)(No.openRight) and I got an error saying the function could not be deduced, so I went looking in the source code and found: enum OpenRight { no, yes } But I had assumed OpenRight was an alias for a Flag type [2], so I had called it wrong. Does anyone have any idea why the function is defined this way? 1. Why is openRight a runtime flag? Is there really a use case for this? 2. Why is openRight not a Flag type? here is the definition I was expecting: alias OpenRight = Flag!"openRight"; auto until(alias pred = "a == b", OpenRight openRight = Yes.openRight, Range, Sentinel) (Range range, Sentinel sentinel); auto until(alias pred, OpenRight openRight = Yes.openRight)(Range range); [1] https://dlang.org/phobos/std_algorithm_searching.html#until [2] https://dlang.org/phobos/std_typecons.html#.Flag
Sep 22 2016
On Thursday, 22 September 2016 at 20:35:13 UTC, e-y-e wrote:[...]Disclaimer: my answers are just early guesses.1. Why is openRight a runtime flag? Is there really a use case for this?Runtime evaluation is more flexible. The reason to have compile-time evaluation is to allowed aggressive specialization, highly tuned codegen and different attribute inference. If that flag is going to add a single very cheap branch (compared to the total cost), then it may not be worth to have it as a compile-time argument, as this would increase the number of instantiations and slightly reduce the flexibility. But there is a second possible explanation, see below.2. Why is openRight not a Flag type?It may be that until is quite old, predating the extensive usage of Flag, and maybe also the extensive use of compile-time flags.
Sep 22 2016
On Thursday, 22 September 2016 at 21:41:38 UTC, Lodovico Giaretta wrote:Ok, I suspected this might be the case. I might work on a pull request for the enum -> Flag item, as I can't think of any reason not to. Off the top of my head I don't think it would break any existing uses. Thanks,2. Why is openRight not a Flag type?It may be that until is quite old, predating the extensive usage of Flag, and maybe also the extensive use of compile-time flags.
Sep 22 2016
On Thursday, September 22, 2016 21:41:38 Lodovico Giaretta via Digitalmars-d- learn wrote:On Thursday, 22 September 2016 at 20:35:13 UTC, e-y-e wrote:until predates Flag by a considerabl margin. And even after Flag was introduced, it wasn't used much for quite a while. - Jonathan M Davis2. Why is openRight not a Flag type?It may be that until is quite old, predating the extensive usage of Flag, and maybe also the extensive use of compile-time flags.
Sep 22 2016