www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Where are we on getting rid of Nullable's alias this? Was that

reply aliak <something something.com> writes:
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
May 30 2019
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
May 30 2019
next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
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). :)
Jun 03 2019
prev sibling next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
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.
Jun 03 2019
prev sibling parent FeepingCreature <feepingcreature gmail.com> writes:
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`.
Jun 05 2019