You're right: there's no reason to allow people to set the NA Boolean for options. In fact, I don't think I should expose the non-NA constructor at all, just the Some function.
Originally, that constructor was exposed because I was providing tools for working on Option types directly: doing arithmetic, for example, where the NA flag was being set appropriately. But this minimal implementation is meant to provide a much more simplified wrapper than must be converted to a non-NA value as soon as possible. -- John On Jul 31, 2014, at 8:01 AM, Stefan Karpinski <[email protected]> wrote: > This looks quite promising. The `get` interface looks like a very nice way to > generically deal with missing values – provide a default or get an error. > Automatic conversion of the default to the type of the Option value is > particularly nice. This seems like it will be a pleasant and efficient API. > > Minor question: how come the non-NA constructor for Option takes both the > `na` and `value` arguments? Doesn't supplying a value imply that it's not NA > while not supplying a value implies that it is NA? > > On Thursday, July 31, 2014, John Myles White <[email protected]> wrote: > At JuliaCon, I described the idea of using Option types instead of NAtype to > make it easier to write type-stable code that interacts with NA’s. To help > facilitate a debate about the utility of this approach, I just wrote up a > minimal package that implements Option types: > https://github.com/johnmyleswhite/OptionTypes.jl > > Essentially, an Option type is a scalar version of a DataArray: it contains a > value and a Boolean mask indicating whether that value is NA or not. Because > Option types are parametric, they allow us to express the variants of NA that > R has, such as a Float64 specific NA and an Int64 specific NA. > > — John >
