On Sunday, 2 February 2014 at 15:06:34 UTC, Idan Arye wrote:
I think it's safe to assume that you - being a supporter of the
non-null movement - write your own code in a way that tries to
avoid the usage of null as much as possible.
You'd be wrong - I was against the not null thing for a long
time, including while writing dom.d.
If I have a class\struct `Foo` with a member field `bar` of
type `Bar`, and an instance of `Foo` named `foo` that happens
to have no `Bar`, I'll not add an extra boolean field just to
indicate that `foo` has no `Bar` - I'll simply set `foo.bar` to
null!
Me too, that's exactly what I did with Element parentNode for
instance.
And I'll use the fact that UFCS works perfectly fine when the
first argument is null to build functions that accept `Bar` as
first argument and do the null checking internally(if it's
needed!) and safely call them on `foo.bar`.
Again. me too.
Some of my code would break with not null by default, but the
amazing thing is it really isn't the majority of it, and since
the compiler error would point just where it is, adding the
Nullable! to the type is fairly easy.
