This intentionally fails to demonstrate what may be undesirable behaviour.
My first theory for avoiding this would be to haveselect when Equatable return a different subscription type, which, if the user callsskipRepeats on, discards its prior, default skipRepeats implementation.
However, before I go ahead and try and find a solution, I wanted to open the discussion in case others think this behaviour is fine / desirable.

I swear we had a user report confusion about this somewhere, recently. Cannot find the issue, though.

It does not make sense toskipRepeats eagerly; I'd definitely postpone this to the last possible moment, just like you said:

My first theory for avoiding this would be to have select when Equatable return a different subscription type, which, if the user calls skipRepeats on, discards its prior, default skipRepeats implementation.

I think something among the lines of aLazySkipRepeatsSubscription<T> (OrLazyFilteredSubscription) could do the trick. It can use a chain of subscriptions under the hood, delegatingselect calls to itself to the underlying subscriptionsuntil the selected substate is not skippable anymore.

Then more expressibe types can aid; the generalSubscription becomes aSubstateSubscription andSkipRepeatsSubscription (orFilteredSubscription) etc. so the type system takes care of conveying if something was skipped anywhere, yet.

Writing it down like this makes me realize we are operating on types called "subscription", which conveys the connection to the store is already established but subsequently modified. What about renaming the stuff we callskipRepeats andselect on something more skin to "stream of state updates"? Then aSubscription type is just the end result and we can insert as many helper types as we need without causing confusion for subscription setup.StateUpdate,FilteredUpdate<T: StateUpdate>,SubstateSelection<T: StateUpdate>. ThenStore.subscribe((StateUpdate) -> StateUpdate) conveys that you subscribe to the store via state updates that you can modify. How's that sound?

I'd like to help cook something like this up if it resonates with you.

I propose we pick this issue up one way or another, and@mjarvis what do you think about a title like "[WIP] Avoid multiple calls to skipRepeats for substates" or something?

@mjarvis Since we never managed to get#307 to work, do you have an opinion on the renaming ofsubscribe return type names? I can just go ahead and implement it as you proposed to make it quick.

@DivineDominion I gave this a try a while back but was unable to resolve the problem. You're welcome to take a crack at it.

so i ran into this issue and incurred performance hits in my app. i calledskipRepeats to insert a specific equality checking closure that was optimized for the specific StoreSubscriber (as one does), but that closure was never invoked. also, just to be clear (if slightly pedantic), we're talking about the closure argument toskipRepeats and not the "skipRepeats implementation" that the user of ReSwift implements, right?