Bug 20328 – [REG 2.089 beta] deprecation message about Nullable.get in isInputRange

Created attachment 1767 zipped folder to run the command in In the provided folder, run $ dub test --force to see /usr/include/dmd/phobos/std/range/primitives.d(174,38): Deprecation: function std.typecons.Nullable!string.Nullable.get_ is deprecated - Implicit conversion with alias Nullable.get this will be removed after 2.096. Please use .get explicitly. deprecations should not happen in the standard library as they may prevent compilation to complete because of code the user cant fix immediately.

reproduce without the whole iz library: --- #!dmd -unittest module runnable; void main(string[] args) { import std.json : parseJSON; parseJSON(""); } --- seems to be used in parseJSON and only when the -unittest switch is also used.

well just $ dmd -unittest typecons.d shows the deprecation

It seems to be triggered by the fix for Issue 19799. Suggestion add version(none) or extract this test from the Type to the global scope. It's not recommended to add unittest blocks in a templatized type anyway.

@clYd3r created dlang/phobos pull request #7256 "fix issue 20328 - deprecation message about Nullable.get in isInputRange" fixing this issue: - fix issue 20328 - deprecation message about Nullable.get in isInputRange https://github.com/dlang/phobos/pull/7256

Shorter repro: enum e = isInputRange!(Nullable!string); I think we need to think about how to handle the case where `alias this` triggers but doesn't change the outcome of the test. The problem is that `foo.front` doesn't exist, so dmd looks inside the deprecated alias get this ... where it also doesn't exist. This does become relevant for things like sticking `Nullable!(<range>)` into format(), which would previously have identified as an input range.

I realize it's a dirty no good very bad workaround, but the easiest way forward may be to (temporarily!) explicitly handle Nullable in `isInputRange`. That or walk back the `get` deprecation and do it via a transition switch instead? ... That or think a lot harder about how deprecations are supposed to work with templated code, because this is very very much a general problem.

adam_d_ruppe on IRC said to always suppress deprecations in traits… the more I think about it, the more I think this may actually be the right way to go.

Yeah maybe but in the meantime something has to be done for this message that's unrelated to the user code, just because an import is there while unit-testing. We (well I'm not so inside that we..) cant keep this until the end of the deprecation period.

@FeepingCreature created dlang/phobos pull request #7257 "Fix issue 20328: only check isInputRange when we've already excluded toString overload." fixing this issue: - Fix issue 20328: only check isInputRange when we've already excluded toString overloads https://github.com/dlang/phobos/pull/7257

And of course, I had it completely wrong - Nullable!string *is* actually an input range... because string is. Obviously! >.< So the deprecation was actually entirely valid aside the fact that it was total bunk because format doesn't ever hit that branch, it just uses Nullable's toString overload. So the fix was reordering the conditions in the format string check to match the order in the actual format code, ie. it notices that there's a toString function and doesn't even check for input rangeness.

dlang/phobos pull request #7257 "Fix issue 20328: only check isInputRange when we've already excluded toString overload." was merged into stable: - 0656d0683bbce88199471f6753b35997f16ec243 by Mathis Beer: Fix issue 20328: only check isInputRange when we've already excluded toString overloads https://github.com/dlang/phobos/pull/7257

*** Issue 20265 has been marked as a duplicate of this issue. ***