Improved Scheduler generics

[p16r]

I see that all the generic schedulers defined in this package can be genericised on just one underlying Scheduler type instead of that scheduler's own associated types. e.g.:

public struct ImmediateScheduler<
-  SchedulerTimeType, SchedulerOptions
+  S: Scheduler
>: Scheduler
- where
-  SchedulerTimeType: Strideable,
-  SchedulerTimeType.Stride: SchedulerTimeIntervalConvertible
{
+  public typealias SchedulerTimeType = S.SchedulerTimeType
+  public typealias SchedulerOptions = S.SchedulerOptions

  ⋮

}

Why was the two generic parameter definition chosen over the single generic parameter definition?

[stephencelis]

Good question! I think we did this based off how we also designed AnyScheduler, to be maximally generic, though admittedly we're not sure of a use case for using all that power. We do have a type alias for ImmediateScheduleOf<S> that has a single generic, though, so if you have a use case where ImmediateScheduler<S> would read better, tacking on an Of should do the trick.

[p16r]

Thanks! Trying to understand why the typealias is there in the first place is what led me to ask this. All the articles about these schedulers that I’ve come across use the typealias only, none of them use the two generic scheduler directly. Have you come across any use case where having separate generic parameters came in handy or do you think there’s a case to redefine the schedulers and deprecate the typealias?

[stephencelis]

@p16r They are absolutely required for AnyScheduler. Otherwise you wouldn't be able to swap out type-erased schedulers at runtime:

var scheduler: AnyScheduler<DispatchQueue.SchedulerTimeType, DispatchQueue.SchedulerOptions>?
scheduler = .main       // ✅
scheduler = .immediate  // ✅
scheduler = .test       // ✅

If we didn't "erase" the underlying S, then the AnyScheduler<DispatchQueue> would not be swappable with an AnyScheduler<ImmediateScheduler<DispatchQueue>>, etc.

[p16r]

The trick to fixing that issue is to add type eraser methods on AnyScheduler etc that erase to the underlying Scheduler type instead of relying on the extension on Scheduler itself. I have implemented the changes in this PR if you'd like to take a look.

[stephencelis]

@p16r Thanks for sharing your findings! I'm still not sure I can think of a reason to make such a change in the library at this time, though, especially since it's breaking. The current 2-generic approach also feels a bit more direct to me, since it's specifying the type of time and options it's dealing with, and not a scheduler type that may or may not be used under the hood. Can you think of a reason to motivate the change or were you just interested in exploring the difference?

[p16r]

On the contrary I haven't come across any use case using separate generics not tied to a scheduler. All the write-ups I've read use the *SchedulerOf typealias, which is why I asked if you have come across any such use cases. A big reason why I'm enthusiastic about proposing this change is since this library is still v0.x it might be more amenable to such breaking changes.

My motivations have pretty much been:

• If no one is taking advantage of the "2-generic-ness" of the types, wouldn't it make the types leaner to make them generic only on a scheduler type?
• This has been an exercise to level up my Swift Generics knowledge, even if this idea isn't accepted.