I'll work on a formal proposal for sealed by default :) 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
