Hi Matthew. Sorry about that! I just saw your reply. I opened a PR with the proposal already: https://github.com/apple/swift- evolution/pull/376 I would be happy to work with you on improving the proposal. I think your mention to sealed protocols is super interesting, but I think that could be additive. It might be easier to discuss each of them separately.
On Wed, Jun 22, 2016 at 2:42 PM Matthew Johnson <matt...@anandabits.com> wrote: > On Jun 22, 2016, at 4:29 PM, Javier Soto <javier....@gmail.com> wrote: > > 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? > > The proposal(s) I am planning is intended to achieve exhaustive pattern > matching for classes and protocols. > > > On Wed, Jun 22, 2016 at 1:43 PM John McCall <rjmcc...@apple.com> wrote: > >> On Jun 22, 2016, at 1:38 PM, Matthew Johnson <matt...@anandabits.com> >> wrote: >> >> On Jun 22, 2016, at 11:48 AM, John McCall <rjmcc...@apple.com> wrote: >> >> On Jun 22, 2016, at 9:15 AM, Javier Soto <javier....@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> wrote: >> >>> On Jun 22, 2016, at 10:59 AM, John McCall <rjmcc...@apple.com> wrote: >>> >>> >>> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution < >>> 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 >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> -- >> Javier Soto >> >> >> >> >> -- > Javier Soto > > -- Javier Soto
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution