On 27 Dec 2017, at 12:41, Douglas Gregor via swift-dev wrote:
Sent from my iPhone
On Dec 27, 2017, at 11:05 AM, Karl Wagner <razie...@gmail.com> wrote:
On 22. Dec 2017, at 07:13, Ted Kremenek via swift-dev
<swift-dev@swift.org> wrote:
On Dec 19, 2017, at 9:39 PM, Ted Kremenek via swift-dev
<swift-dev@swift.org> wrote:
On Dec 19, 2017, at 8:57 PM, Douglas Gregor <dgre...@apple.com>
wrote:
Sent from my iPhone
On Dec 19, 2017, at 8:31 PM, Ted Kremenek <kreme...@apple.com>
wrote:
On Dec 19, 2017, at 3:59 PM, Douglas Gregor <dgre...@apple.com>
wrote:
On Dec 19, 2017, at 2:26 PM, Ted Kremenek via swift-dev
<swift-dev@swift.org> wrote:
On Dec 18, 2017, 4:53 PM -0800, Douglas Gregor via swift-dev
<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
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.
This is a reasonable approach. To make it consistent, we would want to
make the Codable conformances of Array, Set, Dictionary, and Optional
unconditional again—otherwise, user code couldn’t have Codable
conformances for some types without adding the flag.
I’m hesitant to do this because the unconditional conformances to
Codable are wrong, and fixing them is going to cause some (legitimate,
necessary) source breakage. It feels better overall to get that out of
the way sooner... before more wrong Codable conformances get layered
on top.
- Doug
Just to be clear, what is the current impact of leaving those `Codable`
conformances conditional? Having casts like `[1,2,3] as? Codable` fail?
For what it’s worth, I’m not entirely certain how useful type-erased
`Encodable` and `Decodable` values are in practice (aside from the very
workarounds we used because conditional conformances weren’t ready
yet)… Can we try to get some metrics about whether people do this at
all today and for what purposes?
I don’t feel too strongly either way (these conformances have been
unconditional so far, so we’re not regressing anything by not doing
this for `Codable`), but I do think it would be nice to have the actual
conditional conformances in place if we’re not breaking anyone.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
