Certain types are "null-unspecified", that is, we don't know enough about their null-ability to make an informed decision about how to map them. Swift uses force-unwrapped optionals which fit this purpose well, example.
For safety, we currently emit these as Option<...> in return position, and for flexibility we emit them as Option<...> in argument position.
However, I'm not sure that allowing optional types in argument position is a perfectly good idea, as it might make it harder to mark a method as safe, especially if we ever want to do that automatically? CoreFoundation seems to be pretty consistent in either crashing or returning NULL if it gets a NULL argument, but I'm not sure it always does that?
Certain types are "null-unspecified", that is, we don't know enough about their null-ability to make an informed decision about how to map them. Swift uses force-unwrapped optionals which fit this purpose well, example.
For safety, we currently emit these as
Option<...>in return position, and for flexibility we emit them asOption<...>in argument position.However, I'm not sure that allowing optional types in argument position is a perfectly good idea, as it might make it harder to mark a method as safe, especially if we ever want to do that automatically? CoreFoundation seems to be pretty consistent in either crashing or returning NULL if it gets a NULL argument, but I'm not sure it always does that?