Bug 24233 – T[].canFind(Nullable!T()) returns true when it used to return false

Status
NEW
Severity
regression
Priority
P1
Component
phobos
Product
D
Version
D2
Platform
x86_64
OS
Linux
Creation time
2023-11-08T16:06:54Z
Last change time
2024-12-01T16:42:00Z
Assigned to
No Owner
Creator
FeepingCreature
Moved to GitHub: phobos#10536 →

Comments

Comment #0 by default_357-line — 2023-11-08T16:06:54Z
This is a result of the behavioral change that Nullable!T now acts as a range. (Thanks Herringway!) Previously, the `opEquals` overload would allow `T == Nullable!T()` to always be false. Now, instead the overload of `canFind` that takes a range is selected, to which `Nullable!T()` acts as an empty range, so that `canFind` is vacuously true. There is not really anything that can be done about this short of reverting the `Nullable!T` range change, which would at this point itself be a regression. Nonetheless, it *is* a regression, so might as well file it.
Comment #1 by default_357-line — 2023-11-08T16:07:50Z
To be clear, thanks Herringway for identifying the issue, not for changing Nullable.
Comment #2 by snarwin+bugzilla — 2024-03-07T22:51:14Z
This is arguably a design flaw in canFind (and find). Having different overloads of the same function take inputs with different "shapes" (range vs. element) seems like an open invitation for this kind of confusion. Perhaps something to think about for Phobos v3.
Comment #3 by issues.dlang — 2024-03-08T04:59:19Z
(In reply to Paul Backus from comment #2) > This is arguably a design flaw in canFind (and find). Having different > overloads of the same function take inputs with different "shapes" (range > vs. element) seems like an open invitation for this kind of confusion. > Perhaps something to think about for Phobos v3. Agreed. Regardless of the issues with Nullable, there are a variety of places in Phobos where things were made too liberal in what they accepted (be it originally or by expanding their functionality later to try to make them more useful), and it's caused subtle issues and confusion like this. A similar issue is with put on output ranges accepting both singular values and ranges. It works in most cases, but in others, it results in the wrong overload being used. Of course that doesn't necessarily mean that we shouldn't have any range-based functions accepting both elements and ranges, but it is definitely something that we need to carefully consider with each function where we're looking to do it so that we can hopefully provide the desired functionality without the subtle issues. We obviously won't catch everything, but we should be able to do better now that we know more from having used this stuff over time and folks reporting stuff like this.
Comment #4 by robert.schadek — 2024-12-01T16:42:00Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/phobos/issues/10536 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB