Oh wait I see what you mean.
-
-
Replying to @ManishEarth @Gankro
No, I don't. The rfc isn't actually about the semantics of what happens when you match on a ! value.
1 reply 0 retweets 0 likes -
Replying to @ManishEarth @Gankro
That is UB -- it's about letting the compiler make more assumptions about that never happening.
1 reply 0 retweets 0 likes -
Replying to @ManishEarth
ok but why is most of the RFC discussion about matching on !, and blocking the stabilization of !.
1 reply 0 retweets 0 likes -
-
-
Replying to @Gankro
(a) folks have used it to represent void (b) generic unsafe code idk
1 reply 0 retweets 0 likes -
Replying to @ManishEarth
those are *Void, and that's Different from &Void. Obviously *Void is valid because it can dangle.
2 replies 0 retweets 1 like -
Replying to @Gankro @ManishEarth
*Void could also just be assumed to be null, since that is its only valid value.
1 reply 0 retweets 0 likes -
Replying to @BRIAN_____ @Gankro
No, raw pointers are conceptually just integers with a phantom type parameter, all values are valid.
1 reply 0 retweets 0 likes
I mean when you dereference one, the compiler can just assume it's NULL, so UB, so deref should be statically rejected.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.