[BUG] Version 14.1.1 WhenAny.. now returns observable to a nullable regardless of parameter type

[kgday]

Describe the bug
As a result of upgrading to version 14.1.1 with nullable references enabled in a .net 5.0 wpf project, regardless of the input type,
whenAny.. now returns a nullable reference type. This means regardless of the input parameters, we have to use WhereNotNull() everywhere or bangs (I reserve them for last resort). I believe this change came through in issue 2760

Expected behavior
The return type should reflect the input value types.

[glennawatson]

Pending fix #2808

[csmager]

I've updated to 14.2.1, which I believe contains the fix for this in #2809. I now have the opposite problem. The signature for e.g. WhenAnyValue is now this:

public static IObservable<TRet> WhenAnyValue<TSender, TRet>(
    this TSender? sender,
    Expression<Func<TSender, TRet?>> property1)

Meaning I can select a nullable property, and thus the value could be null. But as the return type is not nullable, all the tooling claims it can't be null and I don't have to check for it. If I fix these warnings I get runtime errors.

I think if the ? is removed from TRet? (i.e. back to what we had in <= 13.x) the nullability will just flow through as you would expect.

[ChrisPulman]

Thanks for explaining your findings, I will check this functionality, it should allow you to select a nullable parameter/property from the sender and return a stream of values while the parameter/property is not a null value. The TRet? in the expression allows you to select a nullable property without any further markup.

Out of interest are you expecting to receive null values when it is null?

[csmager]

The TRet? in the expression allows you to select a nullable property without any further markup.

It lets you select a nullable property, but then it claims to return a stream of non-nullable values. This isn't the case, however. It will return null if that property value is null.

Out of interest are you expecting to receive null values when it is null?

Yes, as that's how it has always behaved (as far as I'm aware). For example, when observing a SelectedItem property, null (nothing is selected) is of interest.

I'd expect, in this example, that selecting a property of type T? would return IObservable<T?> and selecting a property of type T would return IObservable<T>.

[ChrisPulman]

I have run a few tests and the key differences between V13 and V14.1 was that a nullable parameter could be selected without further nullable notation and the result was always nullable too, V14.2 does the same but returns a non nullable value type instead but can still return null.
The exception to this in all cases is for value types where you must check your result has a value and use x.Value in a Select for example .Where(x => x.HasValue).Select(x => x!.Value) or assign to a nullable result without this.

If you are able to provide a sample that demonstrates your issue it would be very helpful in understanding and resolving this if required.

[kgday]

An example of what I have encountered:

private readonly ObservableAsPropertyHelper<string?> _orwnerName;

public string? OwnerName => _ownerName.Value;

Let's see that we have a sub class with a name property declared as:

public string? Name  { get => _name; set => this.RaiseAndSetIfChanged(ref _name, value); }

So I am expecting nullables all the way through
but the below gets warnings of nullability mismatches. This is because the WhenAnyValue has converted the
nullable to a non-nullable.

_name = this.WhenAnyValue(x=>x.Owner)
  .WhereNotNull()
  .Select(owner => owner.WhenAnyValue(x=>x.Name))
  .Switch()
  .ToProperty(this, x=>x.Name);

I honestly think that with WhenAnyValue, and ToProperty the nullability should be left out of it - let the caller specify the nullability.

[ChrisPulman]

Thanks very much for your patience and assistance.
The issue is with ToProperty rather than with WhenAny / WhenAnyValue.
Unfortunately none of the existing tests flag this issue and it has gone unseen.

We will update this and add additional tests into ReactiveUI to ensure that this combination always has the desired result.
V13

both have compiler issue without using .WhereNotNull

V14.1.1

possible runtime issue as Owner may be null

compiler issue

V14.2.1


the only option that works with this code (opposite of V13)

V14.x.x - proposed works with all three scenario's

[kgday]

@chris,
Thanks to your hard efforts, as well as all the other contributors.

[ChrisPulman]

Thanks, we do our best with the information we have, its hard to cover all the possibilities.
We have been trying to add more tests into ReativeUI and related projects to ensure that these issues are avoided. The more snippets we have of different use cases the easier it is to build tests to ensure we maintain compatibility.
There will always be a point when something has to change or perhaps even be removed to cater for external changes.

[csmager]

This is my issue (which I think is with WhenAny):

This code, in 14.2, shows no warning that value could be null, as its type is string not string?. It will throw a NullReferenceException at runtime.

public class ViewModel : ReactiveObject
{
    public ViewModel()
    {
        this.WhenAnyValue(x => x.Prop)
            .Subscribe(value => Console.WriteLine(value.Length)); // no warning
    }

    public string? Prop { get; set; }
}

If I add my own WhenAnyValue helper with the correct signature, then I get a warning where expected:

public class ViewModel : ReactiveObject
{
    public ViewModel()
    {
        WhenAnyValue(this, x => x.Prop)
            .Subscribe(value => Console.WriteLine(value.Length)); // warning: dereference of a possibly null reference
        
        WhenAnyValue(this, x => x.PropNotNullable)
            .Subscribe(value => Console.WriteLine(value.Length)); // no warning
    }

    public string? Prop { get; set; }
    
    public string PropNotNullable { get; set; }

    private static IObservable<TRet> WhenAnyValue<TSender, TRet>(
        TSender? sender,
        Expression<Func<TSender, TRet>> property1)
    {
        return sender.WhenAny(property1, (IObservedChange<TSender, TRet> c1) => c1.Value);
    }
}

Note there is, correctly, no warning in the second case. In both cases, the nullability of the selected property flows through to the return type.

[glennawatson]

Already a PR to fix the issue so thanks for the detailed code we will add it to the test.

[csmager]

Thanks. I've looked at the linked PR and the signatures for WhenAny / WhenAnyValue are unchanged, so I'd expect the above issue to remain.

[ChrisPulman]

@csmager I am making the changes in stages to make it simple to manage, thanks for your snippet it helped to understand the issue, it became obvious when put that simply. The original aim was to remove as much as possible the need to use notation (? + !), but the reality is its not quite that simple as issues become hidden.