Deprecation message sources

[Steven Schveighoffer]

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