Beta 2.089.0

[FeepingCreature]

On Sunday, 27 October 2019 at 16:50:00 UTC, baz wrote:
> On Sunday, 27 October 2019 at 16:38:30 UTC, baz wrote:
>> On Sunday, 27 October 2019 at 15:04:34 UTC, drug wrote:
>>> 27.10.2019 17:20, baz пишет:
>>>> On Sunday, 27 October 2019 at 12:59:52 UTC, baz wrote:
>>>>> On Thursday, 17 October 2019 at 06:02:33 UTC, Martin Nowak 
>>>>> wrote:
>>>>>> As usual please report any bugs at
>>>>>> https://issues.dlang.org
>>>>>>
>>>>>> -Martin
>>>>>
>>>>> Hi, I've tested my old stuff and found 2 regs.
>>>>>
>>>>> One deprecation in phobos due to Nullable.get and that was 
>>>>> not detected and some weird linking errors, maybe due to 
>>>>> typeinfo.
>>>>>
>>>>> https://issues.dlang.org/show_bug.cgi?id=20327
>>>>> https://issues.dlang.org/show_bug.cgi?id=20328
>>>> 
>>>> Only 20328 is valid actually.
>>> I confirm the bugs related to Nullable.get (I have another 
>>> one). I have no the reduced case but there are definitly 
>>> issues with deprecated Nullable.get
>>
>> According to a little investigation the message would be 
>> caused by this unittest [1].
>>
>> I would suggest to disable it (using version(none)) or to 
>> extract it from the struct to the global scope. It's not 
>> recommended to add unittest blocks in templatized types 
>> anyway, because when the test is not dependent on the template 
>> params, like here, it's always the same that gets executed for 
>> each instance.
>>
>> [1]: 
>> https://github.com/dlang/phobos/blob/master/std/typecons.d#L2889-L2897
>
> BTW you're not allowed to do that
>
> // Issue 19799
> @safe unittest
> {
>     import std.format : format;
>
>     const Nullable!string a = const(Nullable!string)();
>
>     format!"%s"(a.get); // added .get here
> }
>
> because the Nullable is in a null state, .get call crash the 
> program in assert mode.
> Maybe you should revert the whole stuff ? What does the author 
> of the deprecation think about this case ("feep" IIRC ) ?

Yeah that's a non-fix. It's a blind replacement of "a" with 
"a.get" that ignores the fact that Nullable!string has its own 
toString, ie. this is one of the cases where the `a.get` is 
actually not triggered at runtime. The fact that the deprecation 
still triggers is an issue with traits that has no clear and 
obvious solution. (I advocate Adam's approach of just disabling 
deprecations in traits outright.)