> 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] >> <mailto:[email protected]>> wrote: >> >>> On Jun 22, 2016, at 9:15 AM, Javier Soto <[email protected] >>> <mailto:[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] <mailto:[email protected]>> wrote: >>>> On Jun 22, 2016, at 10:59 AM, John McCall <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>>> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution >>>>> <[email protected] <mailto:[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 >>> >>> <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] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> -- >>> Javier Soto >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
