On 9/17/19 8:14 PM, Jonathan M Davis wrote:
On Tuesday, September 17, 2019 2:34:00 PM MDT Steven Schveighoffer via
Digitalmars-d-learn wrote:
On 9/17/19 4:16 PM, Anonymouse wrote:
On Tuesday, 17 September 2019 at 19:31:53 UTC, Steven Schveighoffer
wrote:
I'd hate to say the answer is to special case Nullable for so many
functions, but what other alternative is there?

-Steve

Nullable isn't alone, std.json.JSONType causes a literal wall of text of
deprecation warnings.

import std.stdio;
import std.json;

void main()
{

      writeln(JSONValue.init.type);

}

https://run.dlang.io/is/J0UDay

I mean, I'm OK with the idea, but having these deprecation messages is
helping nobody. I can't figure out if there's something I'm supposed to,
or can, change in order to get rid of them.

There are quite a few places where it is flagging my code for Nullable
usage without get, and I'm fixing those. But I'll still be left with
this mess of deprecation messages from Phobos and vibe.d. I don't even
know where or if it will break once the alias this is removed.

I ran into problems along those lines with dxml recently, and I couldn't
figure out why one of the deprecation messages was being triggered. It
seemed to have to do with isInputRange, but I couldn't figure out where in
my code was resulting in that problem. I tried to track it down by compiling
Phobos with the alias this outright removed from Nullable (with the idea
that I'd then hopefully get some decent error messages wherever the real
problem was), and dxml's tests then compiled and ran just fine with no
deprecation messages. So, I don't know what to do about it. I suspect that
deprecation messages are being triggered simply by code trying to use
Nullable in template constraints rather than just when it's actually used in
proper code, but I don't know.

I too, think that it's really the template constraints that are causing so much grief. Not only that, but it's impossible to find the code that's actually triggering the usage.

Maybe the best idea then is to use a version. In other words, you compile your code with version=nullableRequiresGet, and then it aliases Nullable to a new type (to avoid symbol conflicts) that requires get without the deprecation? After the deprecation, just replace the alias with the real Nullable. Then at least you can update your code to get rid of all the deprecation messages.

-Steve

Reply via email to