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
I'm confused; I thought that overlapping conformances could result in cases where it's ambiguous which extension to use to satisfy a requirement, but I don't see anything in your proposal for handling that. Does that become a dynamic failure?
-Dave
···
On Dec 18, 2017, at 4:52 PM, 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
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?
···
On Dec 18, 2017, 4:53 PM -0800, Douglas Gregor via swift-dev <swift-dev@swift.org>, wrote:
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
Thoughts?
I'm confused; I thought that overlapping conformances could result in cases where it's ambiguous which extension to use to satisfy a requirement, but I don't see anything in your proposal for handling that. Does that become a dynamic failure?
My proposal doesn’t handle that. I guess I was unclear: the first code snippet, which is well-formed in Swift 4, will get an “overlapping conformance” error in Swift 4.1. It’s a source compatibility break, but one we feel is necessary.
The fixed code only has a single (conditional) conformance, so there’s nothing to overlap.
- Doug
···
Sent from my iPhone
On Dec 18, 2017, at 6:27 PM, Dave Abrahams <dabrahams@apple.com> wrote:
On Dec 18, 2017, at 4:52 PM, Douglas Gregor via swift-dev <swift-dev@swift.org> wrote:
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
Thoughts?
I'm confused; I thought that overlapping conformances could result in cases where it's ambiguous which extension to use to satisfy a requirement, but I don't see anything in your proposal for handling that. Does that become a dynamic failure?
We don’t allow overlapping conformances; a concrete type T cannot conform to the same protocol P in more than one way with different conditional requirements.
Slava
···
On Dec 18, 2017, at 6:27 PM, Dave Abrahams via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
On Dec 18, 2017, at 4:52 PM, Douglas Gregor via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
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
···
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?
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.
···
On Dec 19, 2017, at 3:59 PM, Douglas Gregor <dgregor@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.
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
···
Sent from my iPhone
On Dec 19, 2017, at 8:31 PM, Ted Kremenek <kremenek@apple.com> wrote:
On Dec 19, 2017, at 3:59 PM, Douglas Gregor <dgregor@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:
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.
···
On Dec 19, 2017, at 8:57 PM, Douglas Gregor <dgregor@apple.com> wrote:
Sent from my iPhone
On Dec 19, 2017, at 8:31 PM, Ted Kremenek <kremenek@apple.com> wrote:
On Dec 19, 2017, at 3:59 PM, Douglas Gregor <dgregor@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.
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.
···
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 <dgregor@apple.com <mailto:dgregor@apple.com>> wrote:
Sent from my iPhone
On Dec 19, 2017, at 8:31 PM, Ted Kremenek <kremenek@apple.com <mailto:kremenek@apple.com>> wrote:
On Dec 19, 2017, at 3:59 PM, Douglas Gregor <dgregor@apple.com <mailto:dgregor@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.
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.
- Karl
···
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 <mailto:swift-dev@swift.org>> wrote:
On Dec 19, 2017, at 8:57 PM, Douglas Gregor <dgregor@apple.com <mailto:dgregor@apple.com>> wrote:
Sent from my iPhone
On Dec 19, 2017, at 8:31 PM, Ted Kremenek <kremenek@apple.com <mailto:kremenek@apple.com>> wrote:
On Dec 19, 2017, at 3:59 PM, Douglas Gregor <dgregor@apple.com <mailto:dgregor@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 https://lists.swift.org/mailman/listinfo/swift-dev
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
···
Sent from my iPhone
On Dec 27, 2017, at 11:05 AM, Karl Wagner <razielim@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 <dgregor@apple.com> wrote:
On Dec 19, 2017, at 8:31 PM, Ted Kremenek <kremenek@apple.com> wrote:
On Dec 19, 2017, at 3:59 PM, Douglas Gregor <dgregor@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:
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.
···
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 <razielim@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 <dgregor@apple.com> >>>>> wrote:
Sent from my iPhone
On Dec 19, 2017, at 8:31 PM, Ted Kremenek <kremenek@apple.com> >>>>>> wrote:
On Dec 19, 2017, at 3:59 PM, Douglas Gregor <dgregor@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.
Even with that restriction, the missing runtime functionality is exposed by `as? AnyHashable` casting, which exposes dynamic lookup of Equatable and Hashable conformances.
-Joe
···
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 <dgregor@apple.com <mailto:dgregor@apple.com>> wrote:
Sent from my iPhone
On Dec 19, 2017, at 8:31 PM, Ted Kremenek <kremenek@apple.com <mailto:kremenek@apple.com>> wrote:
On Dec 19, 2017, at 3:59 PM, Douglas Gregor <dgregor@apple.com <mailto:dgregor@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.
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.
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?
Right. Those casts, which would have succeeded in Swift 4, will fail (with a runtime warning) in Swift 4.1.
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)…
The standard library had a bunch of clever trickery to deal with type-erased Encodable and Decodable… I suspect few others did the same thing.
Can we try to get some metrics about whether people do this at all today and for what purposes?
Unfortunately, I don’t know of a good way to do that.
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.
Yes, I agree. I especially want to get the source-breakage aspect out of the way.
- Doug
···
On Jan 2, 2018, at 11:14 AM, Itai Ferber <iferber@apple.com> wrote:
On 27 Dec 2017, at 12:41, Douglas Gregor via swift-dev wrote:
On Dec 27, 2017, at 11:05 AM, Karl Wagner <razielim@gmail.com <mailto:razielim@gmail.com>> 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 <dgregor@apple.com <mailto:dgregor@apple.com>> wrote:
On Dec 19, 2017, at 8:31 PM, Ted Kremenek <kremenek@apple.com <mailto:kremenek@apple.com>> wrote:
On Dec 19, 2017, at 3:59 PM, Douglas Gregor <dgregor@apple.com <mailto:dgregor@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:
Codable in particular doesn't have this problem because it has initializer requirements. Encodable on its own technically does, but nothing really works with Encodable on its own anyway because the whole system is optimized for round-tripping. If Codable is the only thing we we're worried about, it shouldn't stop us.
Jordan
···
On Jan 2, 2018, at 11:29, Douglas Gregor via swift-dev <swift-dev@swift.org> wrote:
Just to be clear, what is the current impact of leaving those Codable conformances conditional? Having casts like [1,2,3] as? Codable fail?
Right. Those casts, which would have succeeded in Swift 4, will fail (with a runtime warning) in Swift 4.1.