I'll work on a formal proposal for sealed by default :)
I have already been planning a proposal for sealed (in general) but didn’t think it fit with the goals of Swift 3 anymore (I had forgotten about the plan to make sealed the default).
John, the modifier you allude to would be to allow inheritance outside the module, correct? Would it also be appropriate to introduce `sealed`-like behavior for protocols (no protocol inheritance and / or conformance outside the module) along side sealed by default or should that still wait as it is purely additive?
That's additive. 'sealed' would be additive if it weren't primarily a proposal to change the default rule, but we clearly aren't going to default protocols that way.
That’s what I thought, just making sure. :)
The proposal(s) I am planning is intended to achieve exhaustive pattern matching for classes and protocols.
Subclass matching can never be exhaustive in Swift as it stands because the object can be an instance of the superclass. You need to formalize abstract classes before you can define that case away.
Actually my plan is to propose an “exact match” cast operator that allows for exhaustive pattern matching. If we do get abstract classes that would allow an additional way for the compiler to prove exhaustiveness.
That aside, I agree that this proposal should provide sufficient information for class/protocol exhaustiveness. However, actually adding the language rule for that should be a separate proposal and is very unlikely to land in Swift 3.
That’s what I figured. I’ll continue to sit on my ideas until we get past Swift 3.
I would like to continue discussing what sealed protocols might look like so we can make sure this proposal aligns well with what we might want to do there. The tricky part is how we distinguish a sealing conformances from sealing refinements (if we need to be able to do that). For example, are there cases where we would want to prevent protocols from inheriting a protocol while still allowing new conformances? And conversely, are there cases where we would want to allow new protocols to refine the protocol and existing conformances to be “upgraded” to the new refined protocol? If we want to support those use cases how might we make the necessary distinction syntactically?
It seems like the right thing to do for classes is pretty obvious (aside from the exact name for the “unsealed” modifier). But I will feel more confident that we are doing the right thing if we also have a reasonably good idea of what we might do for protocols as well.
-Matthew
···
On Jun 22, 2016, at 6:12 PM, John McCall <rjmccall@apple.com> wrote:
On Jun 22, 2016, at 2:42 PM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:
On Jun 22, 2016, at 4:29 PM, Javier Soto <javier.api@gmail.com <mailto:javier.api@gmail.com>> wrote:
John.
On Wed, Jun 22, 2016 at 1:43 PM John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:
On Jun 22, 2016, at 1:38 PM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:
On Jun 22, 2016, at 11:48 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:
On Jun 22, 2016, at 9:15 AM, Javier Soto <javier.api@gmail.com <mailto:javier.api@gmail.com>> wrote:
How would we evaluate the proposal to introduce the "sealed" specifier for classes (open within module, final outside of module) and default to that, in terms of source-code compatibility?
From my point of view it might be easier to do before Swift 3, but if delayed until Swift 4 it wouldn't be the most time-consuming breakage for developers.I believe we consider this plan of record, actually, other than the spelling of the modifier. It's something we probably ought to commit to in Swift 3, though.
By “commit to in Swift 3” do you mean that it is likely the core team would introduce a proposal for this in Swift 3?
We might be able to put the decision off as part of the larger resilience feature, but I think it would be better to settle this in 3 if we can. Who, exactly, authors the proposal is not settled; a community proposal would be welcome.
John.
John.
On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jun 22, 2016, at 10:59 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:
On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Rationalizing base conversion protocol names. I personally don't have the heart to try to re-address the "LiteralConvertible" protocol naming thing again but this would be the last chance to do anything about getting this issue addressed.
Given the vast amount of bike shedding that has already happened around this topic, I don’t think there is a solution that everyone will be happy with. It is also unclear (to me at least) what solution might be acceptable to the core team.
To be clear, I don't care about the name. If you want to rename IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag the conversation into the muck again. :) It's the design of the requirements that I'm pretty opposed to revisiting.
This is orthogonal to the discussion that happened in your thread, definitely no discussion of any changes to the requirements. :)
We are discussing this proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md and specifically the use of the `Convertible` suffix for both the `*LiteralConvertible` protocols and the `Custom(Debug)StringConvertible` protocols where the conversion runs in opposite directions.
The core team decision was:
"The feedback on the proposal was generally positive about the idea of renaming these protocols, but the specific names in the proposal are not well received, and there is no apparent confluence in the community on better names. The core team prefers discussion to continue -- if/when there is a strong proposal for a better naming approach, we can reconsider renaming these."
John.
At the same time, it continues to bother me that `Convertible` is used by standard library protocols with two completely different meanings. This is a problem that deserves to be solved and as it involves a breaking change Swift 3 is the right timeframe in which to do so.
If the core team is able to indicate an approach they favor I would be willing to revise and resubmit the proposal. But I don’t want to spend any further time speculating about what solution might be considered acceptable.
Matthew
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Javier Soto--
Javier Soto