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

[Javier Soto]

Hi Matthew. Sorry about that! I just saw your reply. I opened a PR with the
proposal already: https://github.com/apple/swift-
evolution/pull/376
I would be happy to work with you on improving the proposal. I think your
mention to sealed protocols is super interesting, but I think that could be
additive. It might be easier to discuss each of them separately.

On Wed, Jun 22, 2016 at 2:42 PM Matthew Johnson <matthew at anandabits.com>
wrote:

> On Jun 22, 2016, at 4:29 PM, Javier Soto <javier.api at gmail.com> wrote:
>
> I'll work on a formal proposal for sealed by default :)
>
>
> I have already been planning a proposal for sealed (in general) but didn’t
> think it fit with the goals of Swift 3 anymore (I had forgotten about the
> plan to make sealed the default).
>
> John, the modifier you allude to would be to allow inheritance outside the
> module, correct?  Would it also be appropriate to introduce `sealed`-like
> behavior for protocols (no protocol inheritance and / or conformance
> outside the module) along side sealed by default or should that still wait
> as it is purely additive?
>
> The proposal(s) I am planning is intended to achieve exhaustive pattern
> matching for classes and protocols.
>
>
> 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
>
> --
Javier Soto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160622/1637ff1b/attachment.html>