Swift 3 vs "additive" proposals


(Chris Lattner) #1

Hi Everyone,

As I mentioned before, the Swift 3 release is winding down. There is still time left to make changes, but it is very short. As such, we - as a community - need to stay focused on the goals for this release, principally the goal to get to source stability. It is very important for users of Swift that Swift 3 and the Swift 4 compiler be as compatible as possible. This is important for the continued growth of Swift into new places, like new platforms (which don’t get the benefit of Xcode migration) and Swift Playgrounds.

As such, “additive" proposals will need very strong rationale explaining why they are critical for the Swift 3 release, and we won’t be merging these proposals into the swift-evolution repository unless they have that. We should stay focused on proposals that perfect the features we have, rather than adding new ones.

Similarly, general discussions on this mailing list about blue sky additions to the language are distracting from our important goals, and the core team generally isn’t paying attention to these anyway. I would really appreciate it if we could stay focused on what is important, until the time is right to look beyond Swift 3. This time is in August (which will be here way too soon :-), at which point we can look to the future. I outlined this here earlier:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017701.html

Sorry to be a “downer”, but Swift 3 really is a very important release for the Swift developer community as a whole.

-Chris


(Erica Sadun) #2

A few things on my radar.

Fully breaking that won't be possible post Swift 3:
Rationalizing the first/last/prefix/suffix/drop/etc. methods. Brent R-G said he'd run with this. Discussion: http://article.gmane.org/gmane.comp.lang.swift.evolution/16334/
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.
Potentially code breaking:
Rationalizing for loops-in either by removing `where` (breaking) or completing the filter/break operations (additive but wordy). Discussion here (primarily during WWDC week): http://thread.gmane.org/gmane.comp.lang.swift.evolution/20142 My draft proposal <https://github.com/erica/swift-evolution/blob/5703c94450dcf4a3bc941333d3fadd90a7bd4ad8/proposals/XXXX-whereloops.md> also addresses `where` in switch and catch statements, which could be breaking if changed to `if`.
Redesigning de-init to allow you to declare cleanup operations at points where the dangerous operations are first invoked. Introduced by Graham Perks but ran into WWDC disruption of discussion. Discussion here: http://thread.gmane.org/gmane.comp.lang.swift.evolution/20019
Ending the strong-weak dance once and for all by allowing {self in} and [weak self] / guard let self = self, which would impact a lot of code more than be breaking in and of itself.
-- E

···

On Jun 21, 2016, at 11:55 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hi Everyone,

As I mentioned before, the Swift 3 release is winding down. There is still time left to make changes, but it is very short. As such, we - as a community - need to stay focused on the goals for this release, principally the goal to get to source stability. It is very important for users of Swift that Swift 3 and the Swift 4 compiler be as compatible as possible.


(John McCall) #3

Hi Everyone,

As I mentioned before, the Swift 3 release is winding down. There is still time left to make changes, but it is very short. As such, we - as a community - need to stay focused on the goals for this release, principally the goal to get to source stability. It is very important for users of Swift that Swift 3 and the Swift 4 compiler be as compatible as possible.

A few things on my radar.

Fully breaking that won't be possible post Swift 3:
Rationalizing the first/last/prefix/suffix/drop/etc. methods. Brent R-G said he'd run with this. Discussion: http://article.gmane.org/gmane.comp.lang.swift.evolution/16334/
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.
Potentially code breaking:
Rationalizing for loops-in either by removing `where` (breaking) or completing the filter/break operations (additive but wordy). Discussion here (primarily during WWDC week): http://thread.gmane.org/gmane.comp.lang.swift.evolution/20142 My draft proposal <https://github.com/erica/swift-evolution/blob/5703c94450dcf4a3bc941333d3fadd90a7bd4ad8/proposals/XXXX-whereloops.md> also addresses `where` in switch and catch statements, which could be breaking if changed to `if`.

I agree that these would be breaking.

Redesigning de-init to allow you to declare cleanup operations at points where the dangerous operations are first invoked. Introduced by Graham Perks but ran into WWDC disruption of discussion. Discussion here: http://thread.gmane.org/gmane.comp.lang.swift.evolution/20019
Ending the strong-weak dance once and for all by allowing {self in} and [weak self] / guard let self = self, which would impact a lot of code more than be breaking in and of itself.

These two are additive. We would not remove explicit captures or deinits.

John.

···

On Jun 22, 2016, at 7:59 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 21, 2016, at 11:55 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:


(Matthew Johnson) #4

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.

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


(Nate Cook) #5

That's a great list, Erica—I'd also add:
  - Closure parameter / argument label revisions from Dave Abrahams (upcoming)
  - Functional algorithm renaming from Patrick Pijnappel (upcoming)

I did a quick look through the proposals listed in schedule.md and the yet-to-be-merged proposals to see what might be source breaking. Without passing judgement on whether these should be scheduled, included, or accepted, this is what I came up with:

Merged Proposals

The merged proposals that are / have been in review are by some coincidence all source breaking. The two remaining unscheduled proposals are additive.

Breaking
SE-0086: Drop NS Prefix in Swift Foundation
SE-0103: Make non-escaping closures the default
SE-0077: Improved operator declarations
SE-0091: Improving operator requirements in protocols
SE-0089: Renaming String.init<T>(_: T)
SE-0101: Rename sizeof and related functions to comply with API Guidelines
SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type
SE-0103: Make non-escaping closures the default

Additive
SE-0079: Allow using optional binding to upgrade self from a weak to strong reference
SE-0100: Add sequence-based initializers and merge methods to Dictionary

Pull Requests

Of the proposals waiting to be merged, I counted six source-breaking changes plus another that would almost certainly have breaking follow-on effects in the standard library.

Breaking
#374 [WIP] Protocol oriented integers: Lots of big changes to the numerics system
#218 Throwing Properties and Subscripts proposal: Includes breaking changes to the C/ObjC importer
#365 Shorthand Argument Renaming: Would require changing $0, $1,... to #0, #1,...
#362 Removing Where Clauses from For-In Loops: Requires refactoring for-in loops that include where clauses
#354 Proposal: Allow Single Dollar Sign as Valid Identified: This would codify existing behavior that has been filed as a bug
#329 Proposal: Add last(where:) and lastIndex(where:) Methods to Collections: Renames existing index(of:) and index(where:) collection methods

In-between
#284 More Powerful Constraints for Associated Types: Additive, but has major ramifications for the stdlib that could be source-breaking
    
Additive
#372 [Proposal] Generic and Throwing Subscripts
#371 Enum case stored properties proposal
#369 Conditional Compilation Blocks proposal
#367 Create NNNN-directional-index-methods.md
#366 Create NNNN-unboxing-anyindex.md
#353 #warning
#346 Introducing with to the Standard Library
#328 Proposal: more lenient subscript methods over Collections
#322 Multi-line string literal proposals
#247 Proposal: Factory Initializers
#211 Create 0052-enforcing_calling_super.md
#114 Deriving collections of enum cases
#103 Tail Call Optimization attribute and modifier
#140 Implementing `Comparable` On `NSOperatingSystemVersion`

Other
#370 Renaming the OS X Platform Conditional Compilation Test: Doug Gregor suggested this could just be implemented as a bug fix

-Nate

···

On Jun 22, 2016, at 9:59 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 21, 2016, at 11:55 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi Everyone,

As I mentioned before, the Swift 3 release is winding down. There is still time left to make changes, but it is very short. As such, we - as a community - need to stay focused on the goals for this release, principally the goal to get to source stability. It is very important for users of Swift that Swift 3 and the Swift 4 compiler be as compatible as possible.

A few things on my radar.

Fully breaking that won't be possible post Swift 3:
Rationalizing the first/last/prefix/suffix/drop/etc. methods. Brent R-G said he'd run with this. Discussion: http://article.gmane.org/gmane.comp.lang.swift.evolution/16334/
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.
Potentially code breaking:
Rationalizing for loops-in either by removing `where` (breaking) or completing the filter/break operations (additive but wordy). Discussion here (primarily during WWDC week): http://thread.gmane.org/gmane.comp.lang.swift.evolution/20142 My draft proposal <https://github.com/erica/swift-evolution/blob/5703c94450dcf4a3bc941333d3fadd90a7bd4ad8/proposals/XXXX-whereloops.md> also addresses `where` in switch and catch statements, which could be breaking if changed to `if`.
Redesigning de-init to allow you to declare cleanup operations at points where the dangerous operations are first invoked. Introduced by Graham Perks but ran into WWDC disruption of discussion. Discussion here: http://thread.gmane.org/gmane.comp.lang.swift.evolution/20019
Ending the strong-weak dance once and for all by allowing {self in} and [weak self] / guard let self = self, which would impact a lot of code more than be breaking in and of itself.


(John McCall) #6

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. :slight_smile: It's the design of the requirements that I'm pretty opposed to revisiting.

John.

···

On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #7

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

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

···

On Jun 22, 2016, at 10:59 AM, John McCall <rjmccall@apple.com> wrote:

On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #8

Pull Requests

Additive
#346 Introducing with to the Standard Library

Yeah, mea culpa -- but mea culpa with a reason. Method cascades are not going to be in 3. This is intentionally a stop-gap additive feature specifically for 3, since it's so widely used in the dev community for both Swift constructs and Cocoa(touch) initialization. It's super easy-to-implement/add. If considered, it makes a lot of sense in the 3 timeframe. It makes less sense (although it's still useful) after 3.

Additive
#369 Conditional Compilation Blocks proposal

Definitely additive but it's stuff again that's extremely practical and has a big demand, all the way back to the first moments of open source, and it's pretty much all implemented as private methods now.

Other
#370 Renaming the OS X Platform Conditional Compilation Test: Doug Gregor suggested this could just be implemented as a bug fix

I've put in the bug report. I tried implementing it myself, but apparently my compiler fu is not as strong as I hoped (although the errors in my patch seem to come from code I have absolutely nothing to do with -- I was thinking of throwing myself on Dmitri's mercy for that).

-- E

···

On Jun 22, 2016, at 10:05 AM, Nate Cook <natecook@gmail.com> wrote:


(John McCall) #9

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

Thank goodness. :slight_smile:

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

Yeah, I think we'd love to see better names; there's just no consensus yet.

John.

···

On Jun 22, 2016, at 9:09 AM, Matthew Johnson <matthew@anandabits.com> wrote:

On Jun 22, 2016, at 10:59 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:


(Erica Sadun) #10

We identified three categories:

* A protocol for types that can be initialized from specific types or protocols, e.g. created/initialized with strings (a specific type) or created/initialized with floating point numbers (conforming to a protocol). Current examples include "IntegerLiteralConvertible".
* A protocol for types that can form a representation which may or may not provide a complete projection (the original may not be recoverable from that representation), e.g. "CustomStringConvertible" and "CustomPlaygroundQuickLookable" both fall into this.
* A protocol for isomorphism: can be converted to and from a type, e.g. "RawRepresentable"

This is really the last chance to rationalize this across the language and to evaluate whether other protocol groups should have a core scheme for naming.

-- E

p.s. AbsoluteValuable, AnyCollectionProtocol, AnyObject, ArrayLiteralConvertible, BidirectionalCollection, Collection, BidirectionalIndexable, BinaryFloatingPoint, FloatLiteralConvertible, BitwiseOperations, Boolean, BooleanLiteralConvertible, CVarArg, Collection, Sequence, Comparable, CustomDebugStringConvertible, CustomLeafReflectable, CustomPlaygroundQuickLookable, CustomReflectable, CustomStringConvertible, DictionaryLiteralConvertible, Equatable, ErrorProtocol, ExtendedGraphemeClusterLiteralConvertible, FloatLiteralConvertible, FloatingPoint, IntegerLiteralConvertible, SignedNumber, AbsoluteValuable, Strideable, Hashable, Indexable, IndexableBase, Integer : _Integer, Strideable, IntegerArithmetic : _IntegerArithmetic, Comparable, IntegerLiteralConvertible, IteratorProtocol, LazyCollectionProtocol, LazySequenceProtocol, LazySequenceProtocol, MirrorPath, MutableCollection, Collection, MutableIndexable, NilLiteralConvertible, OptionSet, RawRepresentable, OutputStream, RandomAccessCollection, BidirectionalCollection, RandomAccessIndexable, RangeReplaceableCollection, Collection, RangeReplaceableIndexable, RawRepresentable, Sequence, SetAlgebra, ArrayLiteralConvertible, SignedInteger : _SignedInteger, Integer, SignedNumber, IntegerLiteralConvertible, Streamable, Strideable, StringInterpolationConvertible, StringLiteralConvertible, UnicodeCodec, UnicodeScalarLiteralConvertible, UnsignedInteger : _DisallowMixedSignArithmetic, Integer, _DisallowMixedSignArithmetic : _Integer, _Incrementable, _Integer, CustomStringConvertible, Hashable, IntegerArithmetic, BitwiseOperations, _Incrementable, _IntegerArithmetic, _SequenceWrapper, _SignedInteger : _Integer, SignedNumber

···

On Jun 22, 2016, at 10:09 AM, Matthew Johnson <matthew@anandabits.com> wrote:

On Jun 22, 2016, at 10:59 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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. :slight_smile: 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. :slight_smile:

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


(Javier Soto) #11

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.

···

On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:

On Jun 22, 2016, at 10:59 AM, John McCall <rjmccall@apple.com> wrote:

On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution < > swift-evolution@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. :slight_smile: 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. :slight_smile:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Javier Soto


(John McCall) #12

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 Jun 22, 2016, at 9:15 AM, Javier Soto <javier.api@gmail.com> wrote:

On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 22, 2016, at 10:59 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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. :slight_smile: 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. :slight_smile:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Javier Soto


(Chéyo Jiménez) #13

Would sealed classes be able to be (unsafely) casted as non sealed classes?

···

On Jun 22, 2016, at 9:48 AM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 22, 2016, at 9:15 AM, Javier Soto <javier.api@gmail.com <mailto:javier.api@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.

John.

On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 22, 2016, at 10:59 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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. :slight_smile: 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. :slight_smile:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Javier Soto

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(John McCall) #14

Would sealed classes be able to be (unsafely) casted as non sealed classes?

Sealed-ness doesn't change the type. Casting doesn't come into it.

If you're asking if there would be a way to unsafely add subclasses, no, there would not.

John.

···

On Jun 22, 2016, at 11:47 AM, Jose Cheyo Jimenez <cheyo@masters3d.com> wrote:

On Jun 22, 2016, at 9:48 AM, John McCall via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 22, 2016, at 9:15 AM, Javier Soto <javier.api@gmail.com <mailto:javier.api@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.

John.

On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 22, 2016, at 10:59 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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. :slight_smile: 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. :slight_smile:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Javier Soto

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(John McCall) #15

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.

···

On Jun 22, 2016, at 1:38 PM, Matthew Johnson <matthew@anandabits.com> wrote:

On Jun 22, 2016, at 11:48 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jun 22, 2016, at 9:15 AM, Javier Soto <javier.api@gmail.com <mailto:javier.api@gmail.com>> wrote:

John.

On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 22, 2016, at 10:59 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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. :slight_smile: 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. :slight_smile:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Javier Soto


(Matthew Johnson) #16

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?

···

On Jun 22, 2016, at 11:48 AM, John McCall <rjmccall@apple.com> wrote:

On Jun 22, 2016, at 9:15 AM, Javier Soto <javier.api@gmail.com <mailto:javier.api@gmail.com>> wrote:

John.

On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 22, 2016, at 10:59 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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. :slight_smile: 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. :slight_smile:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Javier Soto


(Adrian Zubarev) #17

You might consider the topic I started about access modifier on extensions. LINK

Fixing this would be a breaking change, because:

if you never explicitly set public modifier the visibility would break
fixing implicit public modifier on extensions would mean fixing the problems with protocols + extensions, because right now its not possible to use access modifier when there are protocols attached to the extension.
There is no proposal yet, but there is almost no feedback on that topic as well.

···

--
Adrian Zubarev
Sent with Airmail

Am 22. Juni 2016 um 18:48:45, John McCall via swift-evolution (swift-evolution@swift.org) schrieb:

On Jun 22, 2016, at 9:15 AM, Javier Soto <javier.api@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.

John.

On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 22, 2016, at 10:59 AM, John McCall <rjmccall@apple.com> wrote:

On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <swift-evolution@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. :slight_smile: 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. :slight_smile:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Javier Soto

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Javier Soto) #18

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

···

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

On Jun 22, 2016, at 1:38 PM, Matthew Johnson <matthew@anandabits.com> > wrote:

On Jun 22, 2016, at 11:48 AM, John McCall <rjmccall@apple.com> wrote:

On Jun 22, 2016, at 9:15 AM, Javier Soto <javier.api@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@swift.org> wrote:

On Jun 22, 2016, at 10:59 AM, John McCall <rjmccall@apple.com> wrote:

On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution < >> swift-evolution@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. :slight_smile: 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. :slight_smile:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Javier Soto

--

Javier Soto


(John McCall) #19

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

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?

That's additive. 'sealed' would be additive if it weren't primarily a proposal to change the default rule, but we clearly aren't going to default protocols that way.

The proposal(s) I am planning is intended to achieve exhaustive pattern matching for classes and protocols.

Subclass matching can never be exhaustive in Swift as it stands because the object can be an instance of the superclass. You need to formalize abstract classes before you can define that case away.

That aside, I agree that this proposal should provide sufficient information for class/protocol exhaustiveness. However, actually adding the language rule for that should be a separate proposal and is very unlikely to land in Swift 3.

John.

···

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

On Jun 22, 2016, at 4:29 PM, Javier Soto <javier.api@gmail.com <mailto:javier.api@gmail.com>> wrote:

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

On Jun 22, 2016, at 1:38 PM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

On Jun 22, 2016, at 11:48 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jun 22, 2016, at 9:15 AM, Javier Soto <javier.api@gmail.com <mailto:javier.api@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 22, 2016, at 10:59 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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. :slight_smile: 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. :slight_smile:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Javier Soto

--
Javier Soto


(Matthew Johnson) #20

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

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 Jun 22, 2016, at 4:29 PM, Javier Soto <javier.api@gmail.com> wrote:

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

On Jun 22, 2016, at 1:38 PM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

On Jun 22, 2016, at 11:48 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jun 22, 2016, at 9:15 AM, Javier Soto <javier.api@gmail.com <mailto:javier.api@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 22, 2016, at 10:59 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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. :slight_smile: 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. :slight_smile:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Javier Soto

--
Javier Soto