4 ms·
Hm... not really. Say you have a function, `f : (bool, T) -> Option<T>`. function f<T>(cond : bool, value : T) : Option<T> { if cond { retur
by tomp 11y ago
Hm... not really.
Say you have a function, `f : (bool, T) -> Option<T>`.
function f<T>(cond : bool, value : T) : Option<T> {
if cond {
return value // equivalent: Some(value)
} else {
return null // equivalent: None
}
}
let x = f(false, f(false, 1)) // equivalent: None
let y = f(true, f(false, 1)) // equivalent: Some(None)
There is no way to tell apart `x` and `y`.
- dllthomas 11y agoYou are confusing types and representations, and your function is not well typed.
- tomp 11y ago> You are confusing types and representations Hm... not sure if I am. Or, at least, `null or T` is not a valid representation for type `Option<T>`. It's all very confusing. > and your function is not well typed. How so?
- dllthomas 11y agoThe `value` you are returning has type T. T is not the same type as Optional<T>. With AnimalMuppet's approach, you would need to return a pointer to a T (so, `&value` in something Cish). Note that this is not the same thing as a nullable reference in, for instance, C#. `null or T` is a valid representation only when T is a non-nullable reference. It doesn't work when T is optional, and it also doesn't work when T is a primitive type, a struct, &c. That said, there's obvious reasons it might be wanted an optimization where it's possible. For that specific case, `Just value` could be specialized to `value`, but that can be done by the compiler (akin to automatic unboxing, elsewhere).