Also removes a redundant one from the setter of `Current`. If the set to
current comes with an associated value change, the bind-unbind flow that
`BindableWithCurrent` implements will handle that change anyway.
A null there indicates a deserialisation error and therefore due to the
catch block immediately succeeding the changed line everything will
continue to work as intended.
They're mostly used in extensibility scenarios, so everything happens in
runtime. There is no better resolution than to crash with a null
reference exception.
There are seemingly no C#-side compile-time guarantees that it is safe,
but if the task's state is `Faulted` (as is checked right before), the
exception cannot be null as per the documentation.
As it turns out, C# 8 provides an attribute that allows annotating that
an `out` parameter's nullability depends on the method's return value,
which is exactly what is desired here.
Uses the usual pattern of two `ReferenceEquals` checks against `this`
and `null` before proceeding to inspect field values. Doing this causes
the compiler to infer that at the point that field values are checked,
`other` can no longer viably be `null`.
`SerializationReader` is not written in a form that would support
turning nullability checking on for the entire class. The biggest
problem there is the inner `DynamicDeserializer` static class, whose
members are initialised via an `initialize()` method, which the compiler
knows nothing about.
For this reason, just opt to suppress the single inspection about
returning a `null` from a method with a return type of `string` (rider
expects `string?`). It would have been also viable to enable nullability
checking for this one method, but that's pretty much the same thing and
adds no safety anyways, so just disable the warning to minimise
surprise.
