I know there's a language theorist out there that thinks having typed Nullables confers some sort of linguistic purity, but I think it's a royal pain. Every function needs to know whether Nullable is possible from all of it's callers? What you gain in semantic purity, you pay for in the configuration back end. I thought the whole point of the language was write what you mean. Typed Nullables seem counter to that strategic objective.
On Mon, Feb 8, 2016 at 7:11 PM, Erik Schnetter <[email protected]> wrote: > You need to write > > LeapDay(yr) = isLeapYr(yr) ? Nullable(Date(yr,2,29)) : Nullable{Date}() > > so that the return value is always a Nullable{Date}. > > -erik > > On Mon, Feb 8, 2016 at 10:08 PM, Michael Landis > <[email protected]> wrote: > > I'm so confused.... > > > > I thought this would be cool: > > isLeapYr(yr::Int64) = yr % 400 == 0 || (yr % 4 == 0 && yr % 100 != 0) > > LeapDay(yr) = isLeapYr(yr) ? Date(yr,2,29) : Nullable{Date}() > > > > lp15 = LeapDay(2015) --> Nullable{Date}() > > lp16 = LeapDay(2016) --> 2016-02-29 > > > > no surprises there, but when I test the return values ... > > > > isnull( lp15 ) --> true > > isnull( lp16 ) --> MethodError: `isnull` has no method matching isnull( > > ::Date ) > > > > What IS the secret Nullable{Date} formulation? > > > > -- > Erik Schnetter <[email protected]> > http://www.perimeterinstitute.ca/personal/eschnetter/ >
