> On Dec 27, 2017, at 11:05 AM, Karl Wagner via swift-dev <swift-dev@swift.org> > wrote: > > > >> On 22. Dec 2017, at 07:13, Ted Kremenek via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >> >> >>> On Dec 19, 2017, at 9:39 PM, Ted Kremenek via swift-dev >>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >>> >>> >>> >>> On Dec 19, 2017, at 8:57 PM, Douglas Gregor <dgre...@apple.com >>> <mailto:dgre...@apple.com>> wrote: >>> >>>> >>>> >>>> Sent from my iPhone >>>> >>>> On Dec 19, 2017, at 8:31 PM, Ted Kremenek <kreme...@apple.com >>>> <mailto:kreme...@apple.com>> wrote: >>>> >>>>> >>>>> >>>>> On Dec 19, 2017, at 3:59 PM, Douglas Gregor <dgre...@apple.com >>>>> <mailto:dgre...@apple.com>> wrote: >>>>> >>>>>> >>>>>> >>>>>>> On Dec 19, 2017, at 2:26 PM, Ted Kremenek via swift-dev >>>>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >>>>>>> >>>>>>> >>>>>>> On Dec 18, 2017, 4:53 PM -0800, Douglas Gregor via swift-dev >>>>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>>, wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> A little while back, I added an error to the Swift 4.1 compiler that >>>>>>>> complains if one tries to use conditional conformances, along with a >>>>>>>> flag “-enable-experimental-conditional-conformances” to enable the >>>>>>>> feature. We did this because we haven’t implemented the complete >>>>>>>> proposal yet; specifically, we don’t yet handle dynamic casting that >>>>>>>> involves conditional conformances, and won’t in Swift 4.1. >>>>>>>> >>>>>>>> I’d like to take away the >>>>>>>> "-enable-experimental-conditional-conformances” flag and always allow >>>>>>>> conditional conformances in Swift 4.1, because the changes in the >>>>>>>> standard library that make use of conditional conformances can force >>>>>>>> users to change their code *to themselves use conditional >>>>>>>> conformances*. Specifically, if they had code like this: >>>>>>>> >>>>>>>> extension MutableSlice : P { } >>>>>>>> extension MutableBidirectionalSlice : P { } >>>>>>>> // … >>>>>>>> >>>>>>>> they’ll get an error about overlapping conformances, and need to do >>>>>>>> something like the following to fix the issue: >>>>>>>> >>>>>>>> extension Slice: P where Base: MutableCollection { } >>>>>>>> >>>>>>>> which is way more elegant, but would require passing >>>>>>>> "-enable-experimental-conditional-conformances”. That seems… >>>>>>>> unfortunate… given that we’re forcing them to use this feature. >>>>>>>> >>>>>>>> My proposal is, specifically: >>>>>>>> >>>>>>>> Allow conditional conformances to be used in Swift 4.1 (no flag >>>>>>>> required) >>>>>>>> Drop the -enable-experimental-conditional-conformances flag entirely >>>>>>>> Add a runtime warning when an attempt to dynamic cast fails due to a >>>>>>>> conditional conformance, so at least users know what’s going on >>>>>>>> >>>>>>> >>>>>>> The last bullet doesn’t feel right to me. It sounds like we would ship >>>>>>> a feature that we know only partially works, but issue a runtime >>>>>>> warning in the case we know isn’t fully implemented? I’m I >>>>>>> interpretting that point correctly? >>>>>> >>>>>> Yes, that’s correct. We will fail to match the conformance (i.e., return >>>>>> “nil” from an “as?” cast), which might be correct and might be wrong. >>>>>> >>>>>> - Doug >>>>> >>>>> Hmm. I’m concerned that a warning runtime would be to settle. Many >>>>> people would possibly not even notice it. It’s essentially an edge case >>>>> in a feature that isn’t fully implemented and thus that part of the >>>>> feature should not be used yet. >>>>> >>>>> What do you think about making this a hard runtime error instead, similar >>>>> to how we are approaching runtime issues for exclusivity checking? That >>>>> would be impossible to miss and would convey the optics that this runtime >>>>> aspect of the feature is not yet supported and thus should not be used. >>>> >>>> I’d rather not make it a runtime error, because code that’s doing dynamic >>>> casting to a protocol is generally already handling the “nil” case (“as?” >>>> syntax), so aborting the program feels far too strong. >>>> >>>> - Doug >>> >>> For me I think the part I’m struggling with is that making it a warning >>> conflates two things together: expected failure in the dynamic cast because >>> the value you are casting doesn’t have that type or — in this case — >>> failure because the cast can never succeed because it is not supported yet. >>> I feel like we would be silently swallowing an unsupported condition. If >>> that didn’t matter, why bother issuing a warning? Clearly were trying to >>> send some kind of message here about this not being supported. >> >> Doug and I chatted a bit offline. >> >> I’m now more on the side of thinking a warning is a reasonable approach. >> I’m still concerned that it will be unnoticed by some developers, and I am >> mixed on conflating failure the cast of “this doesn’t work at all for this >> specific type because it has a conditional conformance” versus “this didn’t >> work because the type didn’t conform to the protocol”. That said, I think >> the cases impacted here are likely very, very small — and a crash in the >> program is probably excessive. >> _______________________________________________ >> swift-dev mailing list >> swift-dev@swift.org <mailto:swift-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-dev > > > What about if we disabled conditional conformances for non-generic protocols > (or keep that part behind the flag)? It seems a bit arbitrary, but IIRC, the > standard library uses conditional conformances for things like Equatable and > the various faces of Collection, which are not runtime-castable anyway.
Even with that restriction, the missing runtime functionality is exposed by `as? AnyHashable` casting, which exposes dynamic lookup of Equatable and Hashable conformances. -Joe
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
