[swift-evolution] Swift 3 vs "additive" proposals

[Javier Soto]

I'll work on a formal proposal for sealed by default :)

On Wed, Jun 22, 2016 at 1:43 PM John McCall <rjmccall at apple.com> wrote:

> On Jun 22, 2016, at 1:38 PM, Matthew Johnson <matthew at anandabits.com>
> wrote:
>
> On Jun 22, 2016, at 11:48 AM, John McCall <rjmccall at apple.com> wrote:
>
> On Jun 22, 2016, at 9:15 AM, Javier Soto <javier.api at gmail.com> 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 <
> swift-evolution at swift.org> wrote:
>
>> On Jun 22, 2016, at 10:59 AM, John McCall <rjmccall at apple.com> wrote:
>>
>>
>> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <
>> swift-evolution at swift.org> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> --
> Javier Soto
>
>
>
>
> --
Javier Soto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160622/c357c3be/attachment-0001.html>