GetErrors() should return IEnumerable<string>

[sm-g]

I am develop form with validation with requirement: revalidate property when it's value changed (i.e. with UpdateSourceTrigger=PropertyChanged in xaml) only when it already had validation error. I have such code:

public string Foo
        {
            get => _foo;
            set
            {
                var hadErrors = HasErrorsFor();

                SetAndNotify(ref _foo, value);

                if (hadErrors)
                {
                    ValidateProperty();
                }
            }
        }

...

        protected bool HasErrorsFor([CallerMemberName] string propertyName = null)
        {
            return GetErrors(propertyName)?.Cast<string>().Any() == true;
        }

Would be nice two write GetErrors(propertyName).Any() instead of GetErrors(propertyName)?.Cast<string>().Any() == true.

[canton7]

GetErrors is a member of INotifyDataErrorInfo. The interface says it has to return IEnumerable.

I supposed I could implement INotifyDataErrorInfo explicitly, but that's a breaking change at this point.

In your example, you could use return GetErrors(propertyName).GetEnumerator().MoveNext().

[sm-g]

Ok, however GetErrors(propertyName) could return null.

[sm-g]

so you still have to make null check:

                var enumerable = GetErrors(string.Empty);
                if (enumerable != null)
                {
                    return enumerable.Cast<string>();
                }
                return new string[0];

this could be implemented in Stylet

[canton7]

That would be a breaking change -- what if people are currently checking for null?

[sm-g]

You mean, somebody could have built some logic based on fact that this method returns null in some (undocumented) conditions, and in same time they do not handle case when returned value is empty? 🤔 Looks unrealistic.

In my opinion, current behavior is little, but annoying bug.

[canton7]

Yes, I do mean that. Anyone doing what you're currently doing will have noticed that it can return null, and may have built some logic based on that.

A bug is when the behaviour of the code doesn't match the requirements. This is performing as expected, therefore there is no bug.