My reasoning for Nullable{T} is that it is type stable. Taking your
example, None and Int would be different type objects, introducing a type
instability and potential performance penalty. But Nullable{T} is always
type Nullable{T} and get(Nullable{T}) is always type T. Allowing
Nullable{T} to decay into T would re-introduce the type instability.
Cheers
Lex
On Tuesday, January 6, 2015 12:03:24 PM UTC+10, Seth wrote:
>
> I'm trying to figure out how (and under what circumstances) one would use
> Nullable. That is, it seems that it might be valuable when you don't know
> whether the value/object exists (sort of like Python's None, I guess), but
> then something like "Nullable(3) == 3" returns false, and that sort of
> messes up how I'm thinking about it.
>
> The code I'd imagine would be useful would be something like
>
> function foo(x::Int, y=Nullable{Int}()) # that is, y defaults to python's
> "None" but is restricted to Int
> if !isnull(y)
> return x+y # x + get(y) works, but why must we invoke another
> method to get the value?
> else
> return 2x
> end
> end
>
> I'm left wondering why it wasn't reasonable to allow y to return get(y) if
> not null, else raise a NullException, and the conclusion I'm coming to is
> that I don't understand the concept of Nullable yet. Any pointers?
>
