The problem with that proposition is that it introduces type instability.
i.e. the user would be tempted to write code like Michael's original
example like
LeapDay(yr) = isLeapYr(yr) ? Date(yr,2,29) : Nullable{Date}()
where the function `LeapDay` can actually return two different, distinct
types: `Date` or `Nullable{Date}`. Those familiar with efficient codegen
know that these kinds of type instabilities kill code performance.
-Jacob
On Mon, Feb 8, 2016 at 8:55 PM, Christopher Alexander <[email protected]>
wrote:
> I really like that construction!
>
>
> On Monday, February 8, 2016 at 10:49:41 PM UTC-5, Greg Plowman wrote:
>>
>> If only Nullables can be null, could we formally define this?
>>
>> isnull(x::Nullable) = x.isnull # already defined in nullable.jl
>> isnull(x) = false # extra definition for everything else
>>
>>
>>
>>> isnull( lp15 ) --> true
>>> isnull( lp16 ) --> MethodError: `isnull` has no method matching isnull(
>>> ::Date )
>>>
>>
>>
