Supporting structs would be a challenge because they are passed by value.

Consider the case of passing a Dictionary into the ItemsSource. Technically, a Dictionary<TKey, TValue> is really an IEnumerable of KeyValuePair structs.

If we do this now, SelectedItem functionality and inline editing functionality will both not work, because they rely on reference equality.

It is possible to change the SelectedItem propertyChanged delegate, RowToEdit propertyChanged delegate, and CreateCell() function to use .Equals() instead of a reference equality. I tried that and it works in a simple case.

However, if we did that, it would theoretically be possible that more than one item in the collection would be flagged as the SelectedItem or the editable item. And that is not what we want.

And I don't know of a way to force it to get passed by reference.

Now, MAUI actually has bugs ( dotnet/maui#15249 dotnet/maui#19208 ) when trying to pass a Dictionary into a CollectionView, unless both the key and value are primitive types.

But supposing that bug were fixed, the question of whether we want to support structs remains. There may be some way to create a hidden index, and wrapping and unwrapping the items all the time, but it would be a huge refactoring and maintenance burden, and I can't seem to make that work anyways.

Given the limitations of structs, if we decided against supporting them, ideally we would just change ItemsSource to be IEnumerable<T> where T : class

But XAML doesn't support the backing class to be generic. So the next best option is to just detect if a value type is used and throw a helpful exception message explaining the issue.