> 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] >> <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? > > 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
