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