Formal Architecture/API Proposal

[JakenVeina]

So, after all the different experiments and "playtests" I've done, both on this repo, and elsewhere, I think I've got a good handle on what I think the architecture and public APIs should be. I'd like to summarize and get some feedback before calling this all a final design, to move forward with an MVP that ReactiveUI can start using, as well as some small demo apps on my end.

Strap in, cause it's probably gonna be a long read. I'm not a big fan of giant walls of text myself, but I think it's warranted here.

Branding

DynamicDataVNext was never intended to be the formal name of the project (at least in my mind), and a decision on this can still probably be postponed, but I think it's time to consider options:

DynamicData2 or DynamicDataV2

The most obvious candidate. Also the most boring. Kinda hate it, honestly, but there's definitely something to be said for keeping the DynamicData branding.

ReactiveUI.DynamicData or ReactiveUI.Collections

If this project is gonna be built on top of ReactiveUI.Primitives, maybe it makes sense to just put it under the ReactiveUI umbrella? Of course, if we end up implementing a shim layer to provide support for both Primitives and System.Reactive this makes less sense. And I'm leaning towards having compatibility with both, if possible.

ReactiveCollections

This is the name I gave to one of my prototypes, and it aligns well with what most of the API names are that I'll list out below. As a reactivemarbles project, I think it fits pretty well, but as I mentioned above, we would probably lose out on DynamicData brand recognition.

Change Modeling

For me, the core architecture of how DynamicData models changes and change sets was the biggest reason to pursue a whole VNext project. The existing change modeling isn't bad but there's a ton of room for improvement in both readability and performance, and it's such a core part of DynamicData that changing it would mean VERY wide-scale breaking changes, that can't really be done incrementally.

Domain structure

My proposal consists of 3 domains, corresponding to different types of collections that are being virtualized: Distinct, Ordered, and Keyed. Each domain consists of the following types:

• XXXChange
  • Minimal struct modeling a single item change, including Type, derived Category, and the item itself.
• XXXChangeType
  • Enum listing the possible types of changes, I.E. Add/Remove/etc. Includes a None type, for compatibility and clarity.
• XXXChangeSet
  • Minimal struct modeling a collection of (ordered) single-item changes. Includes Type, the changes themselves, and private fields that may be useful for letting consumers inspect the changes.
    • In particular, each domain has a FirstAdditionIndex field that allows the changeset to build a zero-allocation iterator over just the additions or just the removals, within a Reset operation.
  • Most notably, all the ChangeSet types utilize ImmutableArray<T> to build and store the lists of changes, allowing for a lot of optimization in memory allocations, based on how much work Microsoft has put into optimizing that library. In particular, VNext runs circles around DynamicData for things like single-change changesets, clears, and resets.
• XXXChangeSet.Builder
  • Builder types, in the same style as ImmutableArray<T>.Builder, ImmutableList<T>.Builder, etc. that provide a safe and memory-optimal way to build changesets up from individual changes, and guarantee correctness of the output, with regard to what the changeset's Type reports as.
• XXXClear, XXXReset, etc.
  • Each ChangeSet type provides methods for "interpreting" the changes within, depending on the type of the changeset, by returning a zero-allocation data structure that wraps the changes, and lets the consumer skip various checks they'd have to make, were they to iterate over the changes directly.
    • Best exmaple is Reset changes, which always consist of Remove changes for all existing items in the collection, followed by Add changes for all new items. Each XXXChangeSet type has an .AsReset() method that will throw if the changeset's Type is not Reset, but will otherwise return an XXXReset struct that contains zero-allocation iterators for Removals and Additions, which iterate over the items directly, without requiring a consumer to check the Type of each change, as they go.
  • Basically, it provides a baked-in way for consumers to safely optimize how they process changes, by leveraging assumptions about how changesets are supposed to work, and an assumption that the library will never produce incoherent changesets.
• XXXChangeStream
  • This is one of the biggest concepts I'm excited about in VNext: the basic type that we operate on is not IObservable<XXXChangeSet<T>>, it's XXXChangeStream<T>. This is a minimal struct that contains an IObservable<XXXChangeSet<T>>, but it also contains metadata about the stream.
    • In DynamicData today, we have a fair bit of spots where stream metadata is needed, especially when it comes to grouping and sorting operators, but the metadata is passed WITHIN each changeset itself. This balloons the size of EVERY changeset that these operators have to generate, and makes it less-than-obvious that these bits of metadata don't actually change from changeset to changeset.
    • With the XXXChangeStream types, metadata is passed from operator to operator ONCE, during stream construction, before a single changeset has even been produced. Not only does this reduce changeset size, it means that operators can use that metadata to actually CHANGE their internal implementations, to optimize for the scenario in play.
    • The biggest use-case for this is to control Refresh support within operators. In DynamicData, we have quite a few operators that have a dedicated "immutable" variant, that doesn't support refreshes (.FilterImmutable(), .TransformImmutable(), etc.) because there's a LOT of optimization to be had when you can assume that items will never mutate (and thus, that Refresh changes can never occur). Putting this kind of metadata within XXXChangeStream types allows consumers to declare whether they want to support mutability ONCE, up-front, at the source collection, and have that info carry down from operator to operator, instead of having to make a decision about what operator to call, and with what optional parameters, at every step of a query.

There's also a few types shared by all the domains:

• ChangeCategory
  • An enum consisting of None, Addition, Removal, and Other. It helps power the shared logic that all three domains use, when it comes to generating correct Reset type changesets.
• ChangeSetType
  • An enum consisting of Empty, Update, Clear, and Reset. It allows consumers to optimize Clear and Reset operations by skipping the iteration of every individual change, if they don't actually need to.
• Optional<T>
  • So long as Microsoft continues to not have an Optional<T> in the BCL, folks will continue to re-implement their own, and I'm no exception. I just don't see the point in pulling in any third party dependency that has one, if that's the ONLY thing we'd need. Lemme know if there's maybe something in ReactiveUI I could use, or if this might cause some conflicts.

The Distinct Domain

I.E. virutalized reactive HashSet<T> collections. Allows consumers to do useful things that they couldn't in DynamicData, like an O(1) .Contains().

public enum DistinctChangeType
{
    None,
    Add,
    Remove
}

I thought this might be really niche, but in the very first demo app I started building to playtest things, Distinct().Contains() actually came up as one of the first queries I wanted to write.

The Ordered Domain

I.E. virtualized reactive List<T> collections. Every item has a specific index, within the collection, that operators must track. Unlike the List domain in DynamicData, this does NOT support any level of "maybe it's ordered, maybe it's not", or more specifically "maybe this item has a known-index, and maybe it doesn't, you have to handle both cases". That's been a big headache for me, at least, when it comes to working on DD's List operators.

public enum OrderedChangeType
{
    None,
    Insertion,
    Movement,
    Removal,
    Replacement,
    Update
}

The other big thing I want to do for this domain is NOT try and support everything that any consumer may find useful. Really, that's gonna be a theme for this whole project, I think, but here in particular. Most notably, there will be no Ordered.Filter() operator. If you want to filter your collection, you HAVE to do it in Distinct or Keyed domains, and then you apply .Sort() to move to the Ordered domain. The .Filter() operators in List have proven to be very difficult to maintain, and pretty terrible for performance. Definitely open to flexibility on this point, though.

The Keyed Domain

I.E. virtualized reactive Dictionary<TKey, TValue> collections. Our comfort zone. The thing we wish we could just make everyone use, exclusively, and forget about all the other stuff. Every item has an associated key value that SHOULD be unique within the collection. And may or may not be derived from the item, via a selector.

public enum KeyedChangeType
{
None,
Addition,
Removal,
Replacement
}

Similar to what I said with regard to the Ordered domain, there will be NO partial sorting support here. If you want sorting, your .Sort() operator takes you out of this domain, and into the Ordered domain.

Source Collections

Another one of my big goals in this project was to try and align our APIs with Microsoft APIs, whenever possible. There's a HUGE potential readability benefit for leveraging APIs that consumers are already familiar with. I mentioned that earlier with regard to ImmutableArray<T>, and how I've modeled portions of the XXXChangeSet APIs after that. Here, I'm talking about one of the most-familiar APIs to basically ALL .NET developers: System.Collections.Generic.

To see what I mean, here's the collection APIs in the Distinct domain.

public interface IObservableSet<T>
    : IObservableCollection<T>,
        ISet<T>
{
    DistinctChangeStream<T> ChangeStream { get; }

    bool Refresh(T item);
    
    void Reset(IEnumerable<T> items);
}

public interface IObservableReadOnlySet<T>
    : IObservableReadOnlyCollection<T>,
        IReadOnlySet<T>
{
    DistinctChangeStream<T> ChangeStream { get; }
}

And also the shared interfaces

public interface IObservableCollection<T>
    : ICollection<T>
{
    IObservable<Unit> CollectionChanged { get; }
 
    IDisposable SuspendNotifications();
}

public interface IObservableReadOnlyCollection<T>
    : IReadOnlyCollection<T>
{
    IObservable<Unit> CollectionChanged { get; }
}

These interfaces have a couple several implementations (so far):

• ChangeTrackingHashSet<T>
  • This actually doesn't implement the IObservableSet<T> and IObservableReadOnlySet<T> interfaces, but just ISet<T> and
    IReadOnlySet<T>. It captures changes as they occur into a BufferedChanges collection, that's backed by a DistinctChangeSet<T>.Builder, which consumers can then call .CaptureAndClear() on, to build formal changesets.
  • Naming I think is self-explanatory. I think it's a slight improvement on "ChangeAware" as the prefix in DD, as it's just a liiiiiiiittle more explicitly clear about what the collection does. I'm not married to it, though.
• ReactiveHashSet<T>
  • The readonly version. I.E. The ObservableCache/ObservableList eqvuialent. But it does work slightly differently, in that it's not actually externally mutable. You feed it an IObservable<DistinctChangeSet<T>>, and it materializes the changes into a collection that you can query, and re-publishes the stream for further subscribers. Logically equivalent to an RX .Publish(), or a DD .ToObservable()
  • In my mind "Reactive" makes sense as the prefix, as it describes the nature of the collection being built from an observable change stream, I.E. "reacting" to it. I think it outweighs the cons of having this mean the opposite of what the "Observable" prefix meant on a collection in DD.
• ObservableHashSet<T>
  • The read-write "source" version. I.E. the SourceCache/SourceList equivalent. This is really just a wrapper around ChangeTrackingHashSet<T>.
  • Other names considered were SubjectHashSet<T> or obviously SourceHashSet<T> to mirror DD. Happy to consider more, but I settled on "Observable" as making the most sense to me.

Stream Metadata

I talked about metadata earlier, being stuff we can attach to each XXXChangeStream type, and there's two pieces that I've put into place, within DistinctChangeStream:

public readonly record struct DistinctChangeStream<T>
{
    public required IEqualityComparer<T> Comparer { get; init; }

    public DistinctItemOptions Options { get; init; }
    
    public required IObservable<DistinctChangeSet<T>> Source { get; init; }
}

public readonly record struct DistinctItemOptions
{
    public bool ItemsAreMutable { get; init; }
}

I talked about item mutability and Refresh changes before, so here it is. DistinctItemOptions is a constructor parameter for all of the collections in the Distinct domain: ChangeTrackingHashSet<T>, ReactiveHashSet<T>, and ObservableHashSet<T>. So, you specify it at the same time as the type of item that it describes: when you construct the collection.

The other piece of metadata that I think will prove really useful is the IEqualityComparer<T> here. This lets us match what HashSet<T> supports, by not requiring items to implement IEquatable<T> to get custom equality, whereas DynamicData really doesn't support that. Some DynamicData operators allow you to inject an IEqualityComparer<T> into the operator itself, but it's only per-operator. If you need equality comparison at several points in the query, you have to manually hand the comparer to each one. This will be even MORE useful in the Keyed domain, because we'll be able to supply a KeyComparer as well as a ValueComparer the same way Dictionary<TKey, TValue> does.

Operators

I don't have too much to say about operators, but I will mention that my intention is, again to leverage familiarity with existing Microsoft APIs. I.E. System.Linq. And System.Reactive.Linq, I suppose. Maybe put operators in a DynamicDataVNext.Linq namespace? So, operator names should be .Select(), .Where(), etc. wherever possible.

I can drop a sample of what one of my prototype operator implementation looks like, though.

public static partial class DistinctChangeStream
{
    extension<T>(DistinctChangeStream<T> stream)
    {
        public DistinctChangeStream<T> Where(Func<T, bool> predicate)
        {
            return stream with
            {
                Source = Observable.Create<DistinctChangeSet<T>>(stream.Options.ItemsAreMutable
                    ? SubscribeMutable
                    : SubscribeImmutable)
            };
            
            IDisposable SubscribeImmutable(IObserver<DistinctChangeSet<T>> downstreamObserver)
            {
                var matchingItemCount = 0;
                var changeSetBuilder = new DistinctChangeSet<T>.Builder(isSourceEmpty: true);
                
                return stream.Source
                    .Select(changeSet =>
                    {
                        if (changeSet.Type is ChangeSetType.Empty)
                            return DistinctChangeSet.Empty<T>();
                        
                        changeSetBuilder.Changes.EnsureCapacity(changeSet.Changes.Length);
                        
                        foreach (var change in changeSet.Changes)
                        {
                            ImmutableRefreshException.ThrowIf(change.Type is DistinctChangeType.Refreshment);

                            if (change.Type is DistinctChangeType.None)
                                continue;

                            if (!predicate.Invoke(change.Item))
                                continue;
                            
                            matchingItemCount += (change.Type is DistinctChangeType.Addition)
                                ? 1
                                : -1;
                            
                            changeSetBuilder.AddChange(
                                change:         change,
                                isSourceEmpty:  matchingItemCount is 0);
                        }
                        
                        return changeSetBuilder.BuildAndClear(willBuilderBeReused: true);
                    })
                    .Where(static changeSet => changeSet.Type is not ChangeSetType.Empty)
                    .SubscribeSafe(downstreamObserver);
            }

            IDisposable SubscribeMutable(IObserver<DistinctChangeSet<T>> downstreamObserver)
            {
                var downstreamItems = new ChangeTrackingHashSet<T>(
                    comparer:   stream.Comparer,
                    options:    stream.Options);

                return stream.Source
                    .Select(changeSet =>
                    {
                        switch (changeSet.Type)
                        {
                            case ChangeSetType.Clear:
                                downstreamItems.Clear();
                                break;
                            
                            case ChangeSetType.Reset:
                                {
                                    downstreamItems.Clear();
                                    foreach (var addition in changeSet.AsReset().Additions)
                                        if (predicate.Invoke(addition))
                                            downstreamItems.Add(addition);
                                }
                                break;
                            
                            case ChangeSetType.Update:
                                foreach (var change in changeSet.Changes)
                                {
                                    switch (change.Type)
                                    {
                                        case DistinctChangeType.Addition:
                                            if (predicate.Invoke(change.Item))
                                                downstreamItems.Add(change.Item);
                                            break;
                                        
                                        case DistinctChangeType.Refreshment:
                                            if (predicate.Invoke(change.Item))
                                                downstreamItems.Add(change.Item);
                                            else
                                                downstreamItems.Remove(change.Item);
                                            break;
                                        
                                        case DistinctChangeType.Removal:
                                            downstreamItems.Remove(change.Item);
                                            break;
                                    }
                                }
                                break;
                        }
                        
                        return downstreamItems.BufferedChanges.CaptureAndClear();
                    })
                    .Where(static changeSet => changeSet.Type is not ChangeSetType.Empty)
                    .SubscribeSafe(downstreamObserver);
            }
        }
    }
}

Conclusion

I'd like to make sure everyone is on board with this as a surface, before I invest more heavily into it, so gimme any qualms or concerns or suggestions you might have.

For now, I'm going to start pulling this all together from the handful of different prototypes I've got lying around, and work towards getting a publishable package here (or wherever) that ReactiveUI can start referencing. I figure @glennawatson and whoever else over there can start build a list of the kinds of operators they need, once they start referencing the project.

[glennawatson]

This is the promised operator report — a rundown of what the ReactiveUI org projects actually consume from DynamicData today, project by project.

One thing worth saying up front: where we currently roll our own change-set machinery (in ReactiveUI.Routing), we'd be happy to drop that and adapt to VNext-style operators instead — we'd just want the equivalents documented so we know what to migrate onto.

ReactiveUI.Routing

This is our heaviest user, but mostly of DynamicData types, not operators. It now produces its own change-tracking (IReactiveChangeSet) internally and only adapts to DynamicData's type surface at the boundary so the public API stays DD-compatible.

• Type surface consumed: IChangeSet / IChangeSet<T>, Change<T>, RangeChange<T>, ListChangeReason, DynamicData.Kernel.Optional.
• Operators we hand-rolled rather than taking from DD (candidates to move onto VNext equivalents):
  • CountChanged() — filter a change-set stream to only sets that change the count (Adds/Removes > 0). VNext equivalent ≈ a reason filter like WhereReasonsAre(Add, Remove).
  • ActOnEveryObject(onAdd, onRemove) — run callbacks per add/remove, correctly across initial load and Reset. Equivalent ≈ OnItemAdded + OnItemRemoved / the old ActOnEveryObject.
  • LightChangeSet<T> — a low-allocation IChangeSet<T> to avoid DD's ChangeSet<T> allocation. Equivalent ≈ a lightweight changeset / Change construction path.
  • ToDynamicDataChangeSet() — adapt our internal change set → DD IChangeSet<T>.
• Routing tests/benchmarks also use ToObservableChangeSet, Bind, and Count (Aggregation).

ReactiveUI.Validation

• SourceList<T> / IObservableList<T>
• .Connect()
• .StartWithEmpty()
• .AutoRefreshOnObservable(...)
• .QueryWhenChanged(...)
• .ToCollection()

Sextant (Sextant.Avalonia)

• ObservableCollection.ToObservableChangeSet() (DynamicData.Binding)
• .Count() (DynamicData.Aggregation)

ReactiveUI.SourceGenerators (BindableDerivedList generator)

• Generates the Bind(out ReadOnlyObservableCollection<T>) pattern — emits the ReadOnlyObservableCollection<T> property that user code binds an IObservable<IChangeSet<T>> into.

Smaller consumers (tests & samples)

• Punchclock tests & Extensions tests: .ToObservableChangeSet(scheduler:) → .Bind(out …)
• Akavache WPF sample: .ToObservableChangeSet() → .ToCollection()

Distinct operators in use across the ecosystem

ToObservableChangeSet, Bind(out ReadOnlyObservableCollection<T>), Connect, ToCollection, QueryWhenChanged, AutoRefreshOnObservable, StartWithEmpty, Count (Aggregation) — plus the IChangeSet<T> / Change<T> / ListChangeReason / RangeChange<T> type surface, and the few list helpers (count-change filtering, ActOnEveryObject) we'd rather get from VNext directly.

[glennawatson]

To add to Claude's comment, the Routing stuff we basically jsut found we were getting alloc spikes from the IChangeSet concept like you already identified and is one of the core reasons why you're going down the vNext route, so once we get the new concept it negates the reason for the custom built operators.

[JakenVeina]

Yeah, LightChangeSet<T> caught my eye. I'll take a look and see how it compares to OrderedChangeSet<T> in VNext. You're definitely gonna still see allocations, but VNext's use of ImmutableArray APIs should cut down the amount of allocation by a fair bit.

[glennawatson]

Follow-up to the operator report — here's where our projects currently hand-roll collection/lifetime management that vNext operators would own. I've included the usage pattern behind each one so you can see the behavioural contract an operator would need to satisfy, not just the call site.

The dominant pattern: keyed cache + per-item subscribe + dispose-on-removal

By far the most common shape across the ecosystem is a Dictionary<key, IDisposable> (or in-flight-request dict) where we subscribe to each item as it enters, and dispose that subscription by hand when it leaves. This is keyed SourceCache + MergeMany/SubscribeMany + DisposeMany. If vNext nails a lean keyed cache with DisposeMany/MergeMany, it replaces most of the code below.

ReactiveUI core — AutoPersistHelperMixins.cs (3 sites)

• Usage pattern: "auto-persist every object in a collection." When an item is added we subscribe to its change notifications and wire up a throttled save; when it's removed (or on Reset/initial load) we dispose that per-item subscription.
• Contract needed: per-item subscription whose lifetime is tied to membership, keyed by item identity, with correct teardown on Remove/Clear/Reset.
• → SourceCache<TItem>().Connect().MergeMany(x => x.AutoPersist(...)).DisposeMany().

Akavache — RequestCache.cs (in-flight coalescing)

• Usage pattern: dedupe concurrent identical async requests. Multiple callers asking for the same key share one underlying IObservable (Replay(1).RefCount()), and the entry is evicted when the request completes. Invalidation also scans keys by prefix/suffix.
• Contract needed: keyed lookup where the value is a shared/ref-counted observable, completion-driven auto-eviction, and bulk remove-by-key-predicate.
• → keyed SourceCache + distinct.

Akavache — shutdown paths (CacheDatabase, SettingsStorage)

• Usage pattern: on shutdown, dispose every registered cache/stream. Currently a manual foreach … Dispose().
• Contract needed: the cache owns its values' lifetime, so disposing the cache disposes all members → DisposeMany.

Fusillade — RateLimitedHttpMessageHandler.cs

• Usage pattern: HTTP request coalescing under a concurrency limit. A lock-protected Dictionary<string, InflightRequest> keyed by request signature, ref-counted so the entry drops when the last subscriber leaves.
• Contract needed: thread-safe keyed cache + ref-count/auto-eviction semantics.
• → keyed SourceCache + distinct.

Sextant — navigation stacks

• Usage pattern: a navigation stack (push / pop / pop-to-root / clear) that the UI binds to, where "current page = top of stack," and popped view-models must be disposed. Today this is mirrored imperatively as Stack<IViewModel> per platform (Platforms/uap/NavigationView.xaml.cs, Navigation/ViewStackServiceBase.cs); the Avalonia head already uses ToObservableChangeSet().Count(), so an ordered change-set would unify the platforms.
• Contract needed: ordered/positional change sets, Bind to a platform collection, top-of-stack selection, and DisposeMany/SubscribeMany to destroy VMs on pop.

ReactiveUI.Validation (already a DD consumer — remaining gaps)

• Usage pattern: live aggregate validation over a dynamic set of validation components. IsValid = all components valid; combined error text = concatenation of the invalid ones; and each component exposes its own ValidationStatusChange observable that must be watched only while it's a member. Today we subscribe per-component by hand (Select(...).Merge().Switch()) and re-iterate all components to rebuild the aggregate on every change.
• Contract needed: MergeMany to flatten per-item status observables with membership-scoped subscribe/unsubscribe, plus aggregation / QueryWhenChanged to recompute IsValid and text. (This is the canonical AutoRefresh-then-aggregate case.)

Lower priority / gated

ReactiveUI.Uno — the example app SQLiteStudio view-models build a ReadOnlyObservableCollection from async query results by hand → the standard ToObservableChangeSet + Bind.

Net ask

The single highest-leverage capability for us is a lean keyed cache paired with DisposeMany + MergeMany — that one combination covers the auto-persist, request-coalescing, navigation-stack, and validation cases above. Keeping the core allocation-light and low/no-dependency is what determines whether the dependency-conscious libraries (Splat, Routing) can actually move onto it.

[glennawatson]

Some discussions:

• Name: Use either DD continuation although V2 etc seems a bit meh. Or ReactiveCollections. The ReactiveUI limits perceptions of your potential users to it being just a UI thing
• ImmutableArray: Be interesting to get updated benchmarks
• XXXChangeStream likely being a struct gives also some advnatages to ValueTask based return types and alloc free fast path returns
• Optional: We added one in marbles you can hijack -- yes its annoying its not in BCL
• As mentioned in our reviews above we don't use the Refresh() style operators much but I think this would be a compelling feature for vNext
• One we found useful in our optimisations in MArbles, if there's a logical grouping like Distinct().Contains() is to avoid the alloc cycle and combine into a common operator. This dramatically improved our perf/alloc perf.
• I would say though not having Linq names has put some users I've recommended to the library off, so keeping the naming at least with Shims back and forth. I have a policy in marbles no dumb methods, we create common sink classes/structs between both the Linq compatible name and internal name then there's no slow down for the user whichever way they want to go

Those are some notes I've had reading through the doc. The ideas seem good.

[JakenVeina]

Name: Use either DD continuation although V2 etc seems a bit meh. Or ReactiveCollections. The ReactiveUI limits perceptions of your potential users to it being just a UI thing

Pretty much my exact thoughts. None of the options are particularly compelling.

ImmutableArray: Be interesting to get updated benchmarks

The benchmarks here include the usage of ImmutableArray<tT> as the main backing store. Even when doing that guaranteed allocation on every single-change changeset, they show we're averaging about half-as-much memory allocation, overall.

I looked at LightChangeSet<T> and now I'm reeeeeally tempted to give that approach a try as well, even though I thought the changeset modeling was pretty set-in-stone. Specifically, the setup where single-change changesets are zero-allocation. I was rather against that idea initially, since it's a real pain to deal with in list-land DD today, where every changeset has to have type checks to see if it's a single or a range, and do different things depending on that, but with .AsAddition()/.AsRemoval() aliasing pattern established, I now think I could make it pretty seamless for the consumer.

What I'd do is keep the ImmutableArray<T> as private/internal, and expose the list of changes as ReadOnlySpan<T>. That way, the single/many check can be done internally, and the consumer isn't even aware of it. This WOULD increase the struct size of XXXChangeSets themselves, so it might not actually be better, overall. It would also make it worse to do async work per-change, as ReadOnlySpan<T> is a ref struct.

I'll plan to prototype and benchmark this after I've got some working operators to benchmark against.

As mentioned in our reviews above we don't use the Refresh() style operators much but I think this would be a compelling feature for vNext

I'm a hardcore "don't ever use refresh" evangelist, but boy are there a LOT of existing DD consumers that thrive on it. I really can't justify dropping the concept entirely, but I'm looking forward to offering big optimizations to those like me who opt-out of it.

One we found useful in our optimisations in MArbles, if there's a logical grouping like Distinct().Contains() is to avoid the alloc cycle and combine into a common operator. This dramatically improved our perf/alloc perf.

I'm already thinking the same thing, as much as I dislike what the API ends up looking like. Combining operators for common scenarios is a big optimization opportunity. We've already started down that path in DD, with newer stuff like .SortAndBind().

I would say though not having Linq names has put some users I've recommended to the library off, so keeping the naming at least with Shims back and forth. I have a policy in marbles no dumb methods, we create common sink classes/structs between both the Linq compatible name and internal name then there's no slow down for the user whichever way they want to go.

I'm uhhh..... not following. Particularly with what you mean by "dumb methods".