David Anthoff

I think the C# spec essentially gets this right by not following the SQL model. 3VL is really confusing and I think keeping it out as much as possible from...

Alright, I've read through all of these issues, and I still think the C# way of handling this is a really reasonable approach. > C# may not be the best...

Having said all of this, I think @johnmyleswhite got it right when he said we need to try out different implementations and especially see how things actually work in situations...

> > The most tricky one is probably whether comparison operators like == and friends should return a Nullable{Bool} or just a Bool. SQL and R opt for the former,...

> AFAICT they respect 3VL. What do you mean exactly? `Nullable(true) | Nullable{Bool}()` returns `Nullable{Bool}()` right now, and that is not 3VL semantics, it should return `Nullable{Bool}(true)`. Same for the...

> We could move lifted operators outside of NullableArrays, but the existence of competing definitions of these methods in the wild will make things confusing. Why not experiment with different...

> What if 3 == Nullable{False}() returned Nullable(false)? I assume you meant `3 == Nullable{Bool}()`? That should just be an error, i.e. there shouldn't be a method defined for these...

Actually, I take that back, I guess we do need that method defined... I think it should just return `false`, not a `Nullable(false)`.

> Err, I guess I meant 3 == Nullable{Int}() or whatever type the original NA was supposed to be of in your original example. According to the C# spec that...

This is probably also effected by the discussion in #85? I.e. the semantics for `==` should be the same for scalar and arrays, right?