Current sentiment on Nullable.get

[aliak]

On Saturday, 15 December 2018 at 15:44:25 UTC, Jonathan M Davis 
wrote:
> It's quite possible for the code to simply be passing it 
> around. And if you want a simple case where it would make sense 
> to call get on a Nullable after assigning it a value, then 
> consider a struct that has member that's a Nullable. A member 
> function could then have code like
>
> auto foo(T t)
> {
>     ...
>     if(member.isNull)
>         member = t;
>     bar(member.get);
>     ...
> }
>
> If T were a class or pointer, and t were null, then that code 
> would fail the assertion in get if nullable types were treated 
> differently.

Yes. You're accessing get without checking isNull first. Bad 
code, bad practice, should not pass code review. Not sure I see 
how that's a bad thing.

Sounds like you want a type that's called HasBeenAssignTo. Not an 
optional type.

Where is this code that accesses get without checking isNull 
first? I've never seen it and it just sounds like bad code.

> On the other hand, any code that is generically passing values 
> around and uses Nullable is going to have serious problems if 
> Nullable treats pointers differently whenever it's given a 
> value that's null.

What serious problems? Asserting when not checking isNull before 
calling .get? Hardly a serious problem.

>
> So, I suppose that an argument could be made that in the case 
> where null is not a valid value, Nullable could treat a null 
> value as the same as not having been given a value, but in any 
> situation where null is a valid value, that does not work at 
> all. And if the code is not generic, having Nullable use a 
> separate bool can be extremely useful, whereas having it treat 
> null the same as not having a value would make Nullable useless 
> for pointers, because its semantics would be the same as if you 
> used the pointer directly.

And how is null a valid value for a class?

>
> Nullable!(T*) is basically the same as T**. All of this arguing 
> about trying to make Nullable treat pointers differently is 
> like arguing that T** is useless, because T* can already be 
> null. That extra level of indirection means something and can 
> have real value. In the cases where it doesn't, you just don't 
> use that extra level of indirection, but making it so that that 
> extra level of indirection isn't possible reduces what you can 
> do.

Not arguing to change T*. Like I already said I agree with you 
when it comes to raw pointers.

Anyway, it's fine if Nullable doesn't change. It is what it is, 
which is a wrapper type that tells you if something was assigned 
to. It's usage as an optional is quite lacking though. No bind 
function, and even if there was it'd have to special case if 
because Nullable!Class = null is a valid value. You can't map it 
because it's not a range. You're left with all the same holes as 
using raw pointers to check for existence with no compile time 
enforceable checks. And you have to special case your Nullable if 
you want to call functions on the T that Nullable is wrapping. 
Which is actually a Much bigger use case for optionals (i.e. 
optionals that wrap actual types that you want to perform 
operations on).

Cheers,
- Ali