Just ran in to this awesome bug

import std;

struct Foo {
    Nullable!string a;
}

void main() {
    string a;
    auto app = appender(&a);
    formattedWrite(app, "%s", Foo());
}

Because this: https://github.com/dlang/phobos/blob/master/std/format.d#L3448

Because "StringTypeOf!(Nullable!string) = Nullable!string()" calls get implicitly, which assers :/

I'm not sure if there's a workaround. I remember there was talk of removing alias this in Nullable? But I also remember there was no consensus?

Cheers,
- Ali

On Thursday, May 30, 2019 8:39:05 AM MDT aliak via Digitalmars-d wrote:
> Just ran in to this awesome bug
>
> import std;
>
> struct Foo {
>      Nullable!string a;
> }
>
> void main() {
>      string a;
>      auto app = appender(&a);
>      formattedWrite(app, "%s", Foo());
> }
>
> Because this: https://github.com/dlang/phobos/blob/master/std/format.d#L3448
>
> Because "StringTypeOf!(Nullable!string) = Nullable!string()"
> calls get implicitly, which assers :/
>
> I'm not sure if there's a workaround. I remember there was talk of removing alias this in Nullable? But I also remember there was no consensus?

I don't think that there was ever a consensus on it (mostly just one person being really vocal about IIRC). But regardless, IIRC, what prevented it from going any further was that deprecating the alias resulted in deprecation messages when the alias was checked by the compiler even if it wasn't actually used in the code, meaning that you got a lot of extraneous deprecation messages. I believe that the bug was reported, but I don't know what its status is.

- Jonathan M Davis

On Thursday, 30 May 2019 at 18:23:54 UTC, Jonathan M Davis wrote:
> On Thursday, May 30, 2019 8:39:05 AM MDT aliak via Digitalmars-d wrote:
>> I'm not sure if there's a workaround. I remember there was talk of removing alias this in Nullable? But I also remember there was no consensus?
>
> I don't think that there was ever a consensus on it (mostly just one person being really vocal about IIRC). But regardless, IIRC, what prevented it from going any further was that deprecating the alias resulted in deprecation messages when the alias was checked by the compiler even if it wasn't actually used in the code, meaning that you got a lot of extraneous deprecation messages. I believe that the bug was reported, but I don't know what its status is.
>
> - Jonathan M Davis

I've tried to make a PR for it just now, and there don't seem to be any outstanding issues preventing deprecating `alias get this` aside issue 19936, for which I have a PR on stable and which should hopefully be merged soonish. As soon as that's done, I'll start a PR to deprecate `alias get this` to hopefully spur discussion about why this is definitely the right way to go forward and why all the people who like `alias get this` are wrong (if there are any). :)

On Thursday, 30 May 2019 at 18:23:54 UTC, Jonathan M Davis wrote:
> I don't think that there was ever a consensus on it (mostly just one person being really vocal about IIRC). But regardless, IIRC, what prevented it from going any further was that deprecating the alias resulted in deprecation messages when the alias was checked by the compiler even if it wasn't actually used in the code, meaning that you got a lot of extraneous deprecation messages. I believe that the bug was reported, but I don't know what its status is.
>
> - Jonathan M Davis

Addendum: let me just copypaste my reasoning from an ongoing github conversation about what's wrong with `alias get this`.

We're using `Nullable` as a stdlib-provided "optional" type, and we keep running into issues where we accidentally use `Nullable!T` as `T`, or make some field `Nullable` and forget to add `isNull` checks, and instead of a nice informative compile error we get a runtime crash, potentially arbitrary time later, potentially in production.

As I keep semi-joking, "`Nullable` adds pointer semantics to arbitrary types, up to and including the null pointer crash". It's just bad design. If the compiler can tell that an error may occur, it should require it to be handled, _especially_ if the alternative is only guarded by an `assert` (which should only be for things that really _logically_ cannot happen). Certainly it should not silently opt you into an implicit conversion that may crash at runtime.

On Thursday, 30 May 2019 at 18:23:54 UTC, Jonathan M Davis wrote:
> On Thursday, May 30, 2019 8:39:05 AM MDT aliak via Digitalmars-d wrote:
>> I'm not sure if there's a workaround. I remember there was talk of removing alias this in Nullable? But I also remember there was no consensus?
>
> I don't think that there was ever a consensus on it (mostly just one person being really vocal about IIRC). But regardless, IIRC, what prevented it from going any further was that deprecating the alias resulted in deprecation messages when the alias was checked by the compiler even if it wasn't actually used in the code, meaning that you got a lot of extraneous deprecation messages. I believe that the bug was reported, but I don't know what its status is.
>
> - Jonathan M Davis

https://github.com/dlang/phobos/pull/7060

I've put up a PR for it just to see where we'll go from here.

There don't seem to be any active language issues preventing deprecation of `alias get this`.