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.)

Reply via email to