> 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. 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
