Sent from my iPad
> On Jun 22, 2016, at 5:01 PM, Javier Soto <[email protected]> wrote: > > 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. No problem! The "by default" aspect is the most important part of your proposal and isn't something I was planning. I mentioned the proposal(s) I have in mind for a couple reasons. Of course I wouldn't mind slipping something extra in if the core team thinks it makes sense. But more importantly, I mentioned this so future aspects of 'sealed' can be considered in the design. Specifically, in the case of protocols there are two avenues for sealing them - refinements by other protocols and conformances by types. I haven't figured out the best way to make that distinction yet (if you have any ideas please chime in). Ideally the path forward would be clear before your proposal is reviewed even if the addition for protocols happens after Swift 3. -Matthew > > On Wed, Jun 22, 2016 at 2:42 PM Matthew Johnson <[email protected]> > wrote: >>> On Jun 22, 2016, at 4:29 PM, Javier Soto <[email protected]> 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 <[email protected]> wrote: >>>>>> On Jun 22, 2016, at 1:38 PM, Matthew Johnson <[email protected]> >>>>>> wrote: >>>>>>> On Jun 22, 2016, at 11:48 AM, John McCall <[email protected]> wrote: >>>>>>> >>>>>>> On Jun 22, 2016, at 9:15 AM, Javier Soto <[email protected]> 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 >>>>>>> <[email protected]> wrote: >>>>>>>>>> On Jun 22, 2016, at 10:59 AM, John McCall <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution >>>>>>>>>>> <[email protected]> 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 >>>>>>>>>> [email protected] >>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> swift-evolution mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> >>>>>>> -- >>>>>>> Javier Soto >>>>>> >>>>> >>>> >>> >>> -- >>> Javier Soto > > -- > Javier Soto
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
