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

--- Comment #1 from FeepingCreature <default_357-line@yahoo.de> ---
To be clear, thanks Herringway for identifying the issue, not for changing Nullable.

--

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

Paul Backus <snarwin+bugzilla@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |snarwin+bugzilla@gmail.com

--- Comment #2 from Paul Backus <snarwin+bugzilla@gmail.com> ---
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.

--

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

Jonathan M Davis <issues.dlang@jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang@jmdavisProg.co
                   |                            |m

--- Comment #3 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
(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.

--