[swift-evolution] [Proposal draft] Conditional conformances
Joe Groff
jgroff at apple.com
Mon Oct 3 14:53:27 CDT 2016
> On Oct 2, 2016, at 8:56 AM, Callionica (Swift) via swift-evolution <swift-evolution at swift.org> wrote:
>
> Interesting comment about worries that you'd be dispatched to the least good SS version . A different language with different constraints, but when LINQ to Objects implementers needed to provide optimized c# implementations for some operations they chose a runtime type check to dispatch to the optimized version. For example, while API is exposed as IEnumerable<T> there are method implementations that check for ICollection<T> at runtime in order to hit more efficient implementations. So static dispatch is good, but win for collections often big enough to overcome a hit from dynamic dispatch.
Yep, and Swift's specialization optimization already knows how to fold `is` and `as` checks after specializing a generic, so checking for a specific type or sub-protocol and jumping into a more optimized implementation for that subtype "dynamically" is still likely to be optimized away.
-Joe
> On Sunday, October 2, 2016, plx via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
>> On Sep 30, 2016, at 1:23 PM, Douglas Gregor <dgregor at apple.com <javascript:_e(%7B%7D,'cvml','dgregor at apple.com');>> wrote:
>>>
>>> This is purely anecdotal but I had a lot of utility code laying around that I’d marked with notes like `// TODO: revisit once conditional conformances are available`.
>>>
>>> When I was leaving those notes I was expecting to need overlapping conformances often, but I reviewed them *before* replying and I actually haven’t found an example where having overlapping conformances is both (1) a significant win and also (2) a win in a way that’d be of broad, general interest.
>>>
>>> - 80% have no real need for overlapping conditional conformances
>>> - 15% might have “elegance gains” but nothing practically-significant
>>> - 5% would *probably* see real gains but are likely not of broad interest
>>>
>>> …which wasn’t what I was expecting, but leaves me a lot more comfortable without overlapping conformances for now than I was in the abstract.
>>
>> Very interesting, thanks for doing this review!
>
> I've taken the time to provide a bit more color on the 80/15/5 breakdown because I don't see much discussion for this proposal in terms of concrete situations...just theoretical concerns and theoretical possibilities. I don't have any completed code either, but I have notes and to-do lists for things I was planning to do, and I think seeing even some semi-concrete scenarios might be helpful here.
>
> The "80%" are generally analogous to the `SomeWrapper` in the writeup; as a concrete example, I was waiting on the availability of conditional conformances to resume work on an emulation of structural unions, e.g. something like:
>
> enum Sum2<A,B> {
> case a(A)
> case b(B)
> }
>
> ...(and analogously for 3, 4, as-necessary).
>
> There's a very obvious way to write `extension Sum2 : Equatable where A:Equatable, B:Equatable {}`...and at the time I set this aside, I was expecting to also want to come back and have additional conformances for things like `...where A:Equatable, B:AnyObject` (using `===` for comparing `B`) and so on for other combinations.
>
> Upon revisiting such things in light of the proposal, I now think differently: for this case it seems like a better long-term approach anyways to stick to a single conformance and work with it like this:
>
> extension Sum2:Equatable where A:Equatable, B:Equatable {
> // details elided
> }
>
> /// Adaptor using `ObjectIdentifier` to implement `==`.
> struct ObjectWrapper<Wrapped:AnyObject> : Equatable, Hashable {
> let wrapped: Wrapped
> }
>
> ...as upon reflection I really would prefer dealing with the hassle of working with `Sum2<A,ObjectWrapper<B>>` in situations where -- in theory -- `Sum2<A,B>` could do -- to the hassle of writing out 4+ conformances for `Sum2` (and so on...even with nice code-gen tools that's going to be a lot of bloat!).
>
> What changed my mind was tracing through the implications of conditional conformances for the use-site ergonomics of adaptors like `ObjectWrapper` above; what I mean is, suppose I have a protocol like this:
>
> protocol WidgetFactory {
> associatedtype Widget
> associatedtype Material
>
> func produceWidget(using material: Material) -> Widget
> }
>
> ...then it's rather easy to simply write this type of boilerplate:
>
> extension ObjectWrapper: WidgetFactory where Wrapped: WidgetFactory {
> typealias Widget = Wrapper.Widget
> typealias Material = Wrapper.Material
>
> func produceWidget(using material: Material) -> Widget {
> return base.produceWidget(using: material)
> }
> }
>
> ...which thus means I have the tools I need to make my use of wrappers like the `ObjectWrapper` largely transparent at the use sites I care about; e.g. I can write a single conditional conformance like this:
>
> extension Sum2: WidgetFactory
> where
> A:WidgetFactory, B:WidgetFactory,
> A.Material == B.Material,
> A.Widget == B.Widget {
>
> typealias Widget = A.Widget
> typealias Material = A.Material
>
> func produceWidget(using material: Material) throws -> Widget {
> switch self {
> case let .a(aa): return aa.produceWidget(using: material)
> case let .b(bb): return bb.produceWidget(using: material)
> }
> }
>
> }
>
> ...and it will apply even in situations where circumstances left me using `ObjectWrapper` (or similar) on any of the type parameters to `Sum2` (e.g. if I also needed an `Equatable` conformance for whatever reason).
>
> At least for now--when I'm still just revisiting plans and thinking about it in light of the proposal--I really would prefer having a simpler language and writing this type of boilerplate, than having a more-complex language and writing the *other* type of boilerplate (e.g. the 4+ `Equatable` conformances here, and so on for other situations).
>
> Note that I'm not claiming the above is the only use for overlapping conditional conformances -- not at all! -- just that situations like the above comprise about 80% of the things I was intending to do with conditional conformances...and that after revisiting them expecting to be troubled by the proposed banning of overlapping conformances, I'm now thinking I'd wind up not using the overlapping-conformance approach in such cases even if it were available.
>
> So that's the first 80%.
>
> Moving on, the next 15% are places where there's some forced theoretical or aesthetic inelegance due to the lack of overlapping conformances, but none of these seem to have any significant practical import.
>
> A representative case here is that I currently have the following pair:
>
> /// `ChainSequence2(a,b)` enumerates the elements of `a` then `b`.
> struct ChainSequence2<A:Sequence,B:Sequence> : Sequence
> where A.Iterator.Element == B.Iterator.Element {
> // elided
> }
>
> /// `ChainCollection2(a,b)` enumerates the elements of `a` then `b`.
> struct ChainCollection2<A:Collection,B:Collection> : Collection
> where A.Iterator.Element == B.Iterator.Element {
> // ^ `where` is not quite right, see below
> }
>
> ...and obviously conditional conformances will allow these to be consolidated into a single `Chain2` type that then has appropriate conditional conformances (and for which the cost/benefit for me will tip in favor of adding conditional conformances to `BidirectionalCollection` and `RandomAccessCollection`, also).
>
> On paper--e.g., theoretically--the lack of overlapping conformances leaves in a few aesthetic issues...for example, at present `ChainCollection2` actually has to be one of these:
>
> // "narrower" option: not all `A`, `B` can necessarily be used together:
> struct ChainCollection2<A:Collection,B:Collection> : Collection
> where
> A.Iterator.Element == B.Iterator.Element,
> A.IndexDistance == B.IndexDistance {
> typealias IndexDistance = A.IndexDistance
> }
>
> // "wasteful" option: theoretically in some cases we are "overpaying" and
> // using a stronger `IndexDistance`, but now we can use any `A` and `B`
> struct ChainCollection2<A:Collection,B:Collection> : Collection
> where A.Iterator.Element == B.Iterator.Element {
> typealias IndexDistance = IntMax
> }
>
> With overlapping conditional conformances you could have both: one conformance that uses base collections' `IndexDistance` when possible, and another that uses `IntMax` when necessary...but without conditional conformances it's necessary to choose between the "narrower" approach or the "wasteful" approach (preserving the status quo).
>
> If you're following along I'm sure you're aware that in this specific case, this "choice" is purely academic (or purely aesthetic)...if you go with the `IntMax` route there's almost always going to be between "no actual difference" and "no measurable difference", so even if it *maybe* feels a bit icky the right thing to do is get over it and stop making a mountain out of an anthill.
>
> Note that I'm well aware that you can choose to see this as a concrete instance of a more-general problem -- that the lack of overlapping conformances would potentially leave a lot of performance on the table due to forcing similar decisions (and in contexts where there *would* be a real difference!) -- but speaking personally I couldn't find very much in my "chores pending availability of conditional conformance" that both (a) fell into this category and (b) had more than "aesthetic" implications.
>
> This brings me to that last 5% -- the handful of things for which overlapping conformances have nontrivial benefits -- and my conclusion here is that these tended to be things I doubt are of general interest.
>
> An example here is that I like to use a function that takes two sequences and enumerates their "cartesian product", with the following adjustments:
>
> - no specific enumeration *ordering* is guaranteed
> - does something useful even with infinite, one-shot sequences...
> - ...meaning specifically that it will eventual-visit any specific pair (even when one or both inputs are infinite, one-shot)
>
> ...(useful for doing unit tests, mostly), which to be done "optimally" while also dotting all the is and crossing all the ts would currently require at least 8 concrete types:
>
> - 4 sequences, like e.g.:
> - UnorderedProductSS2<A:Sequence, B:Sequence>
> - UnorderedProductSC2<A:Sequence, B:Collection>
> - UnorderedProductCS2<A:Collection, B:Sequence>
> - UnorderedProductCC2<A:Collection, B:Collection>
> - 4 iterators (one for each of the above)
>
> ...since you need to use a different iteration strategy for each (yes you don’t *need* 8 types, but I’m trying to “dott all is, cross all ts” here).
>
> In theory overlapping conditional conformances could be used to cut that down to only 5 types:
>
> - 1 type like `UnorderedProduct<A:Sequence,B:Sequence>`
> - the same 4 iterators from before, each used with the appropriate conformance
>
> ...which *is* less code *and* seemingly provides nontrivial gains (the `SS` variant must maintain buffers of the items it's already seen from each underlying sequence, but the others have no such requirement).
>
> But, to be honest, even if those gains are realized, this is the kind of situation I'm perfectly comfortable saying is a "niche" and neither broadly relevant to the majority of Swift developers nor broadly relevant to the majority of Swift code; if overlapping conformances were available I'd use them here, but I'm not going to ask for them just to be able to use them here.
>
> Also, I'm skeptical these gains would be realized in practice: between the proposed "least specialized conformance wins" rule and Swift's existing dispatch rules in generic contexts, it seems like even if overlapping conformances *were* allowed and I *did* use them, I'd still wind up getting dispatched to the pessimal `SS` variant in many cases for which I'd have been hoping for one of the more-optimal versions.
>
> So between the niche-ness of such uses -- and their being 5% or less of what I was hoping to do -- and my skepticism about how dispatch would pan out in practice, I can't get behind fighting for overlapping conformances at this time unless they'd be permanently banned by banning them now.
>
> As already stated, I do think that their absence *will* reveal some *true* pain points, but I think it makes sense to adopt a "wait-and-see" approach here as some more-targeted solution could wind up being enough to address the majority of those future pain points.
>
> These are my more-detailed thoughts after looking at what I was planning to do with conditional conformances once the became available. I realize it doesn't touch on every conceivable scenario and every conceivable use, but I want to reiterate that I did my review expecting to find a bunch of things that I could use as justifications for why Swift absolutely should have overlapping conditional conformances right now...but on actually looking at my plans, I couldn't find anything for which I actually felt that way.
>
>>
>> - Doug
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161003/b6d0dedb/attachment.html>
More information about the swift-evolution
mailing list