Hi,

I just upgraded my compiler from 2.084 to 2.088, and I'm getting scores of deprecation messages. One thing I've realized is that most of these messages are generated by calls outside my code. These deprecation messages are intended to tell you where you are calling them, but end up telling you where phobos, or vibe.d, or whatever, is calling them.

For example, I get messages like:

home/steves/.dvm/compilers/dmd-2.088.0/linux/bin/../../src/phobos/std/traits.d(3687,61): 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.

The line in question is commented below:

template hasElaborateAssign(S)
{
    static if (isStaticArray!S && S.length)
    {
        enum bool hasElaborateAssign = hasElaborateAssign!(typeof(S.init[0]));
    }
    else static if (is(S == struct))
    {
/***** the line below ****/
        enum hasElaborateAssign = is(typeof(S.init.opAssign(rvalueOf!S))) ||

is(typeof(S.init.opAssign(lvalueOf!S))) ||
            anySatisfy!(.hasElaborateAssign, FieldTypeTuple!S);
    }
    else
    {
        enum bool hasElaborateAssign = false;
    }
}

I'm not calling hasElaborateAssign from anywhere in my code. So 1. how am I supposed to know where this call is being generated from, and 2. I'm assuming this is happening inside a static if buried deep somewhere in library code, so how am I supposed to fix it?

I'd hate to say the answer is to special case Nullable for so many functions, but what other alternative is there?

-Steve

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

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.

-Steve

On Tuesday, 17 September 2019 at 20:16:12 UTC, 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

Wow. How come this is not caught by the CI testing?

-Johan

On 9/17/19 3:31 PM, Steven Schveighoffer wrote:
> Hi,
> 
> I just upgraded my compiler from 2.084 to 2.088, and I'm getting scores of deprecation messages. One thing I've realized is that most of these messages are generated by calls outside my code. These deprecation messages are intended to tell you where you are calling them, but end up telling you where phobos, or vibe.d, or whatever, is calling them.

Bug in compiler?

void foo(int y)
{
}

void main()
{
  Nullable!int x = 5;
  assert(x > 0); // No deprecation warning
  foo(x); // deprecation warning
}

Using -vcg-ast, it is indeed calling the _get function in both cases.

-Steve

On Tue, Sep 17, 2019 at 08:55:27PM +0000, Johan Engelen via Digitalmars-d-learn wrote: [...]
> Wow. How come this is not caught by the CI testing?
[...]

Is the CI setup to detect deprecations and flag them as failures?

It's either that, or many cases are not tested because Phobos has a lot of templates, not all of which are instantiated with the specific combination of template arguments that triggers deprecation messages.


T

-- 
Without outlines, life would be pointless.

On Tuesday, September 17, 2019 5:28:33 PM MDT H. S. Teoh via Digitalmars-d- learn wrote:
> On Tue, Sep 17, 2019 at 08:55:27PM +0000, Johan Engelen via Digitalmars-d-learn wrote: [...]
>
> > Wow. How come this is not caught by the CI testing?
>
> [...]
>
> Is the CI setup to detect deprecations and flag them as failures?
>
> It's either that, or many cases are not tested because Phobos has a lot of templates, not all of which are instantiated with the specific combination of template arguments that triggers deprecation messages.

Yes. Seb made druntime and Phobos compile with -de a while back in order to make sure that all cases where deprecations pop up actually get fixed - but of course, that's only going to catch the cases that are in the tests, and it probably wouldn't be hard to trigger a bunch of deprecations in Phobos by doing something like using a range of Nullable, since implicit conversions would probably get triggered all over the place - especially if it's the case that the deprecation message gets triggered by stuff like static if tests and template constraints (I'm not sure that it does in this case, but I have seen problems in the past where template constraints triggered deprecation messages; last time I tried to deprecate TickDuration, I ran into a bunch of problems like that, which is why it hasn't been deprecated yet).

- Jonathan M Davis

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 ran into problems along those lines when I last tried to deprecate TickDuration (which is why it's not yet deprecated). Template constraints were triggering deprecation messages when I didn't think that they should be, but unfortunately, I didn't have time to narrow down what was going on so that I could create a proper bug report for it, and I haven't gotten back to it.

- Jonathan M Davis

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

On Wed, Sep 18, 2019 at 10:48:27AM -0400, Steven Schveighoffer via Digitalmars-d-learn wrote:
> On 9/17/19 8:14 PM, Jonathan M Davis wrote:
[...]
> > 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.

That's really annoying.  Why are constraints triggering deprecation messages?  Shouldn't it be actual usage that trigger them?

I've also seen similar in my own projects, and it's an eyesore, esp. since it was Phobos code that was triggering the messages, not actually anything in my own code.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher