Re: [swift-evolution] Swift 3.1 vs Swift 4

[Charlie Monroe via swift-evolution]

I was kind of serious about this. I'll set up a pool on 
http://www.payit2.com/for-anything-and-everything/pool-money-for-a-gift.aspx

We should just decide on the target price and choose something from 
http://www.lovescotch.com - should I submit a PR with a proposal? ;)

> On Jul 26, 2016, at 12:19 AM, Erica Sadun  wrote:
> 
> http://www.yelp.com/search?find_desc=liquor+delivery_loc=cupertino,+CA
> 
> *kof*
> 
> -- E
> 
>> On Jul 25, 2016, at 3:33 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jul 25, 2016, at 12:41 PM, Charlie Monroe  
>>> wrote:
>>> 
>>> I kinda wish that there was a pool where we could all chip in for a keg of 
>>> beer and a large bottle of whiskey for the team after the official release 
>>> of Swift 3, so that they can celebrate it properly!
>> 
>> Given the ambient stress level, I think it would call for a keg of whiskey 
>> :-) :-)
>> 
>> -Chris
>> ___
>> 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

Re: [swift-evolution] [Review] SE-0131: Add AnyHashable to the standard library

[Pyry Jahkola via swift-evolution]

Dmitri Gribenko wrote:

>> There's one very obscure gotcha with AnyHashable that subclass instances of
>> a Hashable base class should be cast to the base type before wrapping into
>> AnyHashable, otherwise such wrapped values may break the equivalence law of
>> symmetry (`a == b` iff `b == a`).
> 
> The implementation that I have does not suffer from this issue.  (The
> initializer of AnyHashable walks the superclass chain and upcasts the
> value to the correct type.)

Brilliant! Glad that you found a resolution!

— Pyry
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0131: Add AnyHashable to the standard library

[Karl via swift-evolution]

I’d only +1 this proposal if we can perform an implicit conversion. From 
SE-0116:

> The user model for this type would ideally align with our long-term goal of 
> supporting Hashable existentials directly, so the type deserves some 
> short-term compiler support to help us get there.


I read that as meaning that the interface should look as close as possible to 
what using a raw “Hashable” would look like, and that some short-term complier 
magic to achieve that would be acceptable. As far as that goes:

- unwrapping is functionally equivalent (upcasting from Any today, in the 
future from Hashable, but when upcasting all that matters is the destination 
type so NFC)
- wrapping is too verbose:

> /// let descriptions: [AnyHashable : Any] = [
> /// AnyHashable(""): "emoji",
> /// AnyHashable(42): "an Int",
> /// AnyHashable(Int8(43)): "an Int8",
> /// AnyHashable(Set(["a", "b"])): "a set of strings"
> /// ]

That would be a big regression in readability, IMO. Previously, you could 
declare those keys without the “AnyHashable” wrapper, and the bridging magic 
would turn Int -> NSNumber because that’s the way to make an Int conform to 
NSObject. It should be possible to teach the compiler how to turn a Hashable in 
to an AnyHashable implicitly.

But yeah, if we can do an implicit conversion, it’s a  from me

Karl

> On 24 Jul 2016, at 00:26, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0131: Add AnyHashable to the standard library" begins now 
> and runs through July 25.  This proposal is a bit unusual, since it is a late 
> additive proposal.  The reason we need to do something here is as a critical 
> part of "SE-0116: Import Objective-C id as Swift Any type”, enabling 
> importing untyped NSDictionary's and NSSet’s properly.  The core team 
> considers this already conceptually approved for Swift 3 as part of SE-0116, 
> but would greatly appreciate feedback on the details of the proposed design.
> 
> The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> 
> ___
> 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

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Xiaodi Wu via swift-evolution]

On Mon, Jul 25, 2016 at 8:35 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Sun Jul 24 2016, Chris Lattner  wrote:
>
> > Hello Swift community,
> >
> > The review of "SE-0132: Rationalizing Sequence end-operation names"
> > begins now and runs through July 26.  Apologies for the short review
> > cycle, but we’re right up against the end of source breaking changes
> > for Swift 3.  The proposal is available here:
> >
> >
> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
> >
> > Reviews are an important part of the Swift evolution process. All
> > reviews should be sent to the swift-evolution mailing list at
> >
> >   https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > or, if you would like to keep your feedback private, directly to the
> review manager.
> >
> > What goes into a review?
> >
> > The goal of the review process is to improve the proposal under review
> > through constructive criticism and contribute to the direction of
> > Swift. When writing your review, here are some questions you might
> > want to answer in your review:
> >
> >   * What is your evaluation of the proposal?
>
> I'm mostly very much in favor of this proposal, but I have some
> thoughts.
>
> First, though, I have to apologize for those wide tables, since I'm
> listed as a co-author (because of a small design contribution).  The
> only way I've been able to read them is by looking at the markdown
> source, so that's how I'm going to quote it here.
>
> [Note to future authors: if you need to include a table, this is how you
> can make it narrow enough:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md#proposed-solution
> .
> The source is awful to read but it renders OK.]
>
>
> > ## Proposed solution
> >
> > We sever the index-taking APIs from the others, forming two separate
> > families, which we will call the "Sequence-end operations" and the
> > "index-based operations". We then consider and redesign them along
> > separate lines.
> >
> > ### Sequence-end operations
> >
> > Each of these APIs should be renamed to use a directional word based on
> > its row in the table:
> >
> > | Operand  | Directional word   |
> > |  | -- |
> > | **Fixed Size**   |
> > | First 1  | first  |
> > | Last 1   | last   |
> > | First (n: Int)   | prefix |
> > | ...with closure  | prefix |
> > | Last (n: Int)| suffix |
> > | ...with closure  | suffix |
> > | **Searching From End**   |
> > | First  matching  element | first  |
> > | ...with closure  | first  |
> > | Last matching element| last   |
> > | ...with closure  | last   |
> >
> > To accomplish this, `starts(with:)` should be renamed to
> > `hasPrefix(_:)`, and other APIs should have directional words replaced
> > or added as appropriate.
> >
> > Additionally, the word `drop` in the "Exclude" APIs should be replaced
> > with `removing`. These operations omit the same elements which the
> > `remove` operations delete, so even though the types are not always
> > the same (`removing` returns `SubSequence`, not `Self`), we think they
> > are similar enough to deserve to be treated as nonmutating forms.
>
> Unfortunately there's a semantic difference that I hadn't noticed
> before: the mutating “remove” operations have a precondition that there
> be at least as many elements as are being removed.  “Drop,” like “pop,”
> is forgiving of such overruns.  I think this is solvable; my suggestion
> is below
>
> > These changes yield (altered names **bold**):
> >
> > |  | Get   |
> Index | Exclude
>| Remove (1)| Pop (1)  | Equate (2)
>|
> > |  | - |
> - |
> - | - |
>  | -- |
> > | **Fixed Size**   |
> > | First 1  | C.first   | -
>| **S.removingFirst()**
>| C.removeFirst()   | C.popFirst() | -
> |
> > | Last 1   | C.last| -
>| **S.removingLast()**
> | C.removeLast()| C.popLast()  | -
> |
> > | First (n: Int)   | S.prefix(3)   | -
>| 

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Saagar Jha via swift-evolution]

There’s remove, which is mutating in that it actually removes the elements from 
the target. removing, on the other hand is nonmutating and basically gives a 
copy and then removes from the copy.
Saagar Jha



> On Jul 25, 2016, at 21:21, Boris Wang via swift-evolution 
>  wrote:
> 
> "When the operation is naturally described by a verb, use the verb’s 
> imperative for the mutating method and apply the “ed” or “ing” suffix to name 
> its nonmutating counterpart."
> 
> I known it. But, the "verb" here should be a action will change the object. 
> Not every verb will change the object.
> 
> Like the word: peek ,copy.
> 
> In socket program, there's a action "peek", just check if there has new data 
> in socket data buffer, not move out the data(like the API receive()). It's 
> not "receiving".
> 
> 
> Daniel Duan >于2016年7月26日 周二11:39写道：
> Please read the naming section in Swift API design guidelines 
> https://swift.org/documentation/api-design-guidelines/#naming 
> 
> 
> 
> Daniel Duan
> Sent from my iPhone
> 
> On Jul 25, 2016, at 8:29 PM, Boris Wang via swift-evolution 
> > wrote:
> 
>> I am curious about the reason using "removing",
>> What we are doing is not remove, just selecting some elements from the 
>> original collection.
> 
>> ___
> 
>> 
>> 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

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

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Boris Wang via swift-evolution]

"When the operation is naturally described by a verb, use the verb’s
imperative for the mutating method and apply the “ed” or “ing” suffix to
name its nonmutating counterpart."

I known it. But, the "verb" here should be a action will change the object.
Not every verb will change the object.

Like the word: peek ,copy.

In socket program, there's a action "peek", just check if there has new
data in socket data buffer, not move out the data(like the API receive()).
It's not "receiving".


Daniel Duan 于2016年7月26日 周二11:39写道：

> Please read the naming section in Swift API design guidelines
> https://swift.org/documentation/api-design-guidelines/#naming
>
>
> Daniel Duan
> Sent from my iPhone
>
> On Jul 25, 2016, at 8:29 PM, Boris Wang via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I am curious about the reason using "removing",
> What we are doing is not remove, just selecting some elements from the
> original collection.
>
> ___
>
>
> 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

Re: [swift-evolution] [Review] SE-0131: Add AnyHashable to the standard library

[Dmitri Gribenko via swift-evolution]

On Mon, Jul 25, 2016 at 1:12 PM, Nate Cook via swift-evolution
 wrote:
>>   
>> https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md
>
> +1!
>
> This proposal looks great to me. I only have one nitpick: it looks like 
> there's a '_Hashable' protocol used in the Dictionary extension to get around 
> the limit on generic subscripts. Swift has managed to remove most (all?) 
> underscored protocols from public APIs, so I would just suggest that the 
> implementation consider an alternate name that isn't underscored. Something 
> like 'HashableBase' would still imply that the protocol is more of an 
> implementation detail than a useful protocol on its own.

Hi Nate,

I don't see a benefit for this.  Nobody should be using _Hashable.
Adding it as a non-underscored protocol increases API surface for no
benefit.  _Hashable is slated for removal as soon as we get the
necessary compiler features.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0131: Add AnyHashable to the standard library

[Dmitri Gribenko via swift-evolution]

On Mon, Jul 25, 2016 at 1:34 PM, Pyry Jahkola via swift-evolution
 wrote:
>
> On 24 Jul 2016, at 01:26, Chris Lattner via swift-evolution
>  wrote:
>
> Hello Swift community,
>
> The review of "SE-0131: Add AnyHashable to the standard library" begins now
> and runs through July 25.  This proposal is a bit unusual, since it is a
> late additive proposal.  The reason we need to do something here is as a
> critical part of "SE-0116: Import Objective-C id as Swift Any type”,
> enabling importing untyped NSDictionary's and NSSet’s properly.  The core
> team considers this already conceptually approved for Swift 3 as part of
> SE-0116, but would greatly appreciate feedback on the details of the
> proposed design.
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md
>
> * What is your evaluation of the proposal?
>
>
> +1, this is a nice addition, and useful at times.
>
> There's one very obscure gotcha with AnyHashable that subclass instances of
> a Hashable base class should be cast to the base type before wrapping into
> AnyHashable, otherwise such wrapped values may break the equivalence law of
> symmetry (`a == b` iff `b == a`).

The implementation that I have does not suffer from this issue.  (The
initializer of AnyHashable walks the superclass chain and upcasts the
value to the correct type.)

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0125: Remove NonObjectiveCBase and isUniquelyReferenced

[Chris Lattner via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0125-remove-nonobjectivecbase.md

The review of "SE-0125: Remove NonObjectiveCBase and isUniquelyReferenced" ran 
from Active review July 19...22. The proposal has been *accepted*.

This proposal had significant community feedback to help refine and improve its 
design, and Arnold has incorporated that into his v2 of the proposal.  The core 
team agrees the new revision is a good design.

Thank you to Arnold Schwaighofer for driving this discussion forward!

-Chris Lattner
Review Manager

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

[swift-evolution] [Accepted] SE-0130: Replace repeating Character and UnicodeScalar forms of String.init

[Chris Lattner via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0130-string-initializers-cleanup.md

The review of "SE-0130: Replace repeating Character and UnicodeScalar forms of 
String.init" ran from Active review July 22…24. The proposal has been 
*accepted*.

There was very little public discussion about this proposal, but the core team 
believes this eliminates a real ambiguity, while leaving doors open for future 
improved designs.

Thank you to Roman Levenstein for driving this discussion forward.

-Chris Lattner
Review Manager


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

[swift-evolution] [Accepted] SE-0128: Change failable UnicodeScalar initializers to failable

[Chris Lattner via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0128-unicodescalar-failable-initializer.md

The review of "SE-0128: Change failable UnicodeScalar initializers to failable" 
ran from Active review July 21…24. The proposal has been *accepted*.

Feedback was universally positive, and the proposal is straight forward.

Thank you to Xin Tong for driving this discussion forward.

-Chris Lattner
Review Manager


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

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Daniel Duan via swift-evolution]

Please read the naming section in Swift API design guidelines 
https://swift.org/documentation/api-design-guidelines/#naming

Daniel Duan
Sent from my iPhone

> On Jul 25, 2016, at 8:29 PM, Boris Wang via swift-evolution 
>  wrote:
> 
> I am curious about the reason using "removing",
> What we are doing is not remove, just selecting some elements from the 
> original collection.
> ___
> 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

[swift-evolution] [Rejected] SE-0122: Use colons for subscript declarations

[Chris Lattner via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md

The review of "SE-0122: Use colons for subscript declarations" ran from July 
19…24. The proposal has been *rejected*.

The feedback on this proposal from the community was overall divided with a 
slight bias towards reject.  Reasonable arguments were made on both sides: 
subscripts are definitely property-like in some ways, but they are also 
function-like in other ways.  Further, if we were aiming to align declaration 
syntax with use, arguably the parameter list should be enclosed in square 
brackets (but to be clear, we’re not going to do that).  Overall, the core team 
agrees with the pervasive sentiment that this is not important enough to make a 
change for.

Thank you to James Froggatt for raising this proposal,

-Chris Lattner
Review Manager

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

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Boris Wang via swift-evolution]

I am curious about the reason using "removing",
What we are doing is not remove, just selecting some elements from the
original collection.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Dave Abrahams via swift-evolution]

on Sun Jul 24 2016, Chris Lattner  wrote:

> Hello Swift community,
>
> The review of "SE-0132: Rationalizing Sequence end-operation names"
> begins now and runs through July 26.  Apologies for the short review
> cycle, but we’re right up against the end of source breaking changes
> for Swift 3.  The proposal is available here:
>
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
>
> Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
>
>   https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the review 
> manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of
> Swift. When writing your review, here are some questions you might
> want to answer in your review:
>
>   * What is your evaluation of the proposal?

I'm mostly very much in favor of this proposal, but I have some
thoughts.

First, though, I have to apologize for those wide tables, since I'm
listed as a co-author (because of a small design contribution).  The
only way I've been able to read them is by looking at the markdown
source, so that's how I'm going to quote it here.

[Note to future authors: if you need to include a table, this is how you
can make it narrow enough:
https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md#proposed-solution.
The source is awful to read but it renders OK.]


> ## Proposed solution
> 
> We sever the index-taking APIs from the others, forming two separate 
> families, which we will call the "Sequence-end operations" and the 
> "index-based operations". We then consider and redesign them along 
> separate lines.
> 
> ### Sequence-end operations
> 
> Each of these APIs should be renamed to use a directional word based on 
> its row in the table:
> 
> | Operand  | Directional word   |
> |  | -- |
> | **Fixed Size**   |
> | First 1  | first  |
> | Last 1   | last   |
> | First (n: Int)   | prefix |
> | ...with closure  | prefix |
> | Last (n: Int)| suffix |
> | ...with closure  | suffix |
> | **Searching From End**   |
> | First  matching  element | first  |
> | ...with closure  | first  |
> | Last matching element| last   |
> | ...with closure  | last   |
> 
> To accomplish this, `starts(with:)` should be renamed to
> `hasPrefix(_:)`, and other APIs should have directional words replaced
> or added as appropriate.
> 
> Additionally, the word `drop` in the "Exclude" APIs should be replaced
> with `removing`. These operations omit the same elements which the
> `remove` operations delete, so even though the types are not always
> the same (`removing` returns `SubSequence`, not `Self`), we think they
> are similar enough to deserve to be treated as nonmutating forms.

Unfortunately there's a semantic difference that I hadn't noticed
before: the mutating “remove” operations have a precondition that there
be at least as many elements as are being removed.  “Drop,” like “pop,”
is forgiving of such overruns.  I think this is solvable; my suggestion
is below

> These changes yield (altered names **bold**):
> 
> |  | Get   | Index
>  | Exclude   | 
> Remove (1)| Pop (1)  | Equate (2) 
> |
> |  | - | 
> - | 
> - | - | 
>  | -- |
> | **Fixed Size**   |
> | First 1  | C.first   | -
>  | **S.removingFirst()** | 
> C.removeFirst()   | C.popFirst() | -  
> |
> | Last 1   | C.last| -
>  | **S.removingLast()**  | 
> C.removeLast()| C.popLast()  | -  
> |
> | First (n: Int)   | S.prefix(3)   | -
>  | **S.removingPrefix(3)**   | 
> **C.removePrefix(3)** | -| **S.hasPrefix([x,y,z])** 

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Andre via swift-evolution]

> 2016/07/22 0:33、Chris Lattner via swift-evolution  
> のメール：
> 
> Hello Swift community,
> 
> The third review of "SE-0117: Allow distinguishing between public access and 
> public overridability" begins now and runs through July 25. The proposal is 
> available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?

+1 for the first design
(it would be nice to have stored properties on extensions if we couldn't 
subclass anymore as that is one of the cases that I would subclass something, 
or uses associated object in objc)

--

I am totally in agreement with Garths’ most lucid and cogent "reframing" of 
this proposal:

All we are doing now is subdividing public into two separate sublevels, public 
and open. Just as public subsumes all the privileges of internal, open subsumes 
public.

Then we can just reframe the gist of it like this:


Before SE-0117
After  SE-0117

Subclassable →
public
open

Visible →
public
public
Outside Module
Default →
internal
internal
Inside Module

private
private


This is a lot less controversial and if this is what this proposal really 
means, I think there would be a lot less resistance to it...


>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
Yes

>   * Does this proposal fit well with the feel and direction of Swift?
Yes

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
Kotlin w/open classes except that it limits subclassing wether inside or 
outside of a 'module' (basically taking harder stance against subclassing).

I like swifts "middle-way" approach.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
Been following this proposal since original discussions, participated in 
previous reviews, read all the emails in his discussion and toyed a bit more 
with kotlin to understand it's open/sealed implementation compared to this 
proposal, also followed a couple conversations/blogs online about this proposal.

> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> 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

Re: [swift-evolution] Swift 3.1 vs Swift 4

[Goffredo Marocchi via swift-evolution]

Sly sly manager you are, but I thought popular culture taught us you used 
automated schnapps IV's for peak productivity ;).



http://xkcd.com/323/

Sent from my iPhone

> On 25 Jul 2016, at 22:33, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jul 25, 2016, at 12:41 PM, Charlie Monroe  
>> wrote:
>> 
>> I kinda wish that there was a pool where we could all chip in for a keg of 
>> beer and a large bottle of whiskey for the team after the official release 
>> of Swift 3, so that they can celebrate it properly!
> 
> Given the ambient stress level, I think it would call for a keg of whiskey 
> :-) :-)
> 
> -Chris
> ___
> 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

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Dave Abrahams via swift-evolution]

on Mon Jul 25 2016, Jacob Bandes-Storch  wrote:

> On Mon, Jul 25, 2016 at 1:11 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> I'm giving the overall idea a +0 and the specific proposal as currently
>> written a -1, because I think this is a much more complicated bikeshed
>> than it appears to be on the surface and the proposal doesn't begin to
>> address the issues.  Specifically, I'm concerned about these points:
>>
>> * `flatten` works on Optional and sequences of Optional.
>>   How does it make sense to rename these operations “join?”
>>
>
> Does it really? These don't work for me:
>
> let x = [1,2,nil,4]
> x.flatten()
>
> let y = Optional(Optional(42))
> y.flatten()

Agh.  Well, hello, bug!  It's supposed to, IMO, for the same reason that
flatMap does.  The relationship is that 

  x.flatten() === x.flatMap {$0}

So how would you document the semantics of 

   Optional(Optional(42)).joined()

>> * The name and semantics of `flatten` is linked to that of `flatMap`.
>>   It's almost impossible to explain what `flatMap` does without
>>   reference to `flatten`.  Will it make sense to explain `flatMap` in
>>   terms of `joined`?
>>
>
> I think the current documentation comments do a pretty good job:
>
> On the [T].flatMap(T -> U?) -> [U] version:
>   /// Returns an array containing the non-`nil` results of calling the given
>   /// transformation with each element of this sequence.
>
> On the [T].flatMap(T -> [U]) -> [U] version:
>   /// Returns an array containing the concatenated results of calling the
>   /// given transformation with each element of this sequence.
>
> (This one also mentions array.map(transform).flatten(), which would become
> array.map(transform).joined().)

Okay.

>> * `flatten` is a functional term of art in the same family as `flatMap`.
>>   We have good reasons to consider changing some of the other names in
>>   this family, such as `filter` and `reduce`, but that idea has met with
>>   significant resistance on the list.  How far should we go?  Does it
>>   make sense to make this one change alone?
>
> I wouldn't argue for renaming flatMap. I'm not suggesting to change the
> name of flatten() because I don't like it (I do); I'm suggesting to change
> it because — unlike Ruby, whose Array has #flatten and #join, but the
> latter is *only* for producing strings — we seem to have the *same*
> functionality behind 2 differently-named APIs.
>
> (Actually I feel like flatMap is a more fundamental functional method in
> the family of filter and reduce than flatten/joined is. flatten is just
> flatMap({$0}), 

x.map(f) can be written as x.flatMap(Optional(f)) or even x.flatMap(f)
for that matter.  Does that make flatMap more fundamental than map? ;-)

Something roughly like this holds:

  flatMap = map • flatten
  map = flatMap • Optional
  flatten = flatMap • identity

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

Re: [swift-evolution] Swift 3.1 vs Swift 4

[Erica Sadun via swift-evolution]

http://www.yelp.com/search?find_desc=liquor+delivery_loc=cupertino,+CA

*kof*

-- E

> On Jul 25, 2016, at 3:33 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jul 25, 2016, at 12:41 PM, Charlie Monroe  
>> wrote:
>> 
>> I kinda wish that there was a pool where we could all chip in for a keg of 
>> beer and a large bottle of whiskey for the team after the official release 
>> of Swift 3, so that they can celebrate it properly!
> 
> Given the ambient stress level, I think it would call for a keg of whiskey 
> :-) :-)
> 
> -Chris
> ___
> 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

Re: [swift-evolution] Swift 3.1 vs Swift 4

[Brandon Knope via swift-evolution]

This might need to go through the evolution process:

Keg of beer or whiskey?!!

B

> On Jul 25, 2016, at 5:33 PM, Chris Lattner  wrote:
> 
> 
>> On Jul 25, 2016, at 12:41 PM, Charlie Monroe  
>> wrote:
>> 
>> I kinda wish that there was a pool where we could all chip in for a keg of 
>> beer and a large bottle of whiskey for the team after the official release 
>> of Swift 3, so that they can celebrate it properly!
> 
> Given the ambient stress level, I think it would call for a keg of whiskey 
> :-) :-)
> 
> -Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Jacob Bandes-Storch via swift-evolution]

On Mon, Jul 25, 2016 at 2:09 PM, David Rönnqvist 
wrote:
>
> Haskell calls the general *m (m a) -> m a* function for "join", but also
> has a specialized *[[a]] -> [a]* function called "concat". (The function
> corresponding to "flatMap" is called "bind" in Haskell (although used as an
> operator), so since neither is called flatten or flatMap it doesn't have
> the confusion where one of them would be named so).
>

There's also mapMaybe

and concatMap

and
mapM
 and
probably others. "concat" is just "concatMap id". Similarly, concatMap can
be seen as equivalent to bind with its arguments reversed, "flip (>>=)". I
personally find the plethora of similar functions confusing, but I'm not
totally fluent in Haskell's standard libraries.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 vs Swift 4

[Chris Lattner via swift-evolution]

> On Jul 25, 2016, at 12:41 PM, Charlie Monroe  
> wrote:
> 
> I kinda wish that there was a pool where we could all chip in for a keg of 
> beer and a large bottle of whiskey for the team after the official release of 
> Swift 3, so that they can celebrate it properly!

Given the ambient stress level, I think it would call for a keg of whiskey :-) 
:-)

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

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Garth Snyder via swift-evolution]

A warm -0.5 from me, meaning that I agree that this issue is important to 
address, and that I concur with many of the particulars. (I agree that removing 
is way better than drop, for example.)

However, I suspect that this approach may open more Pandora’s boxes than it 
closes. Most of my discomfort centers on the idea of incomplete ranges. This 
seems like a major thing to introduce to the language, and although I like the 
concept, it raises questions that deserve to be addressed independently. 
Incomplete ranges shouldn’t be allowed to just sneak in the back door as part 
of an API cleanup in one particular area.

Really, it seems like ranges could do with some attention in their own right. 
In their current form, they feel like largely pragmatic constructions that 
aren't yet fully baked. A lot of elaborations have already been piled onto 
them, and they’re responsible for a lot of API-level complexity. But as yet, 
they’re not capable of representing, e.g., intervals that are open or half-open 
on the left. 

Incomplete ranges seem to push the idea of ranges even further in the direction 
of abstract predicates or mathematically general models of intervals. For 
example, SE-0132 suggests

..< 3

as a syntax for an upper-bounded range. But wouldn’t 

   < 3

be a more natural syntax for this? From a logical perspective, you’re not 
really creating a range so much as expressing the condition that something is 
less than 3, which happens to be encoded by a range. If we had incomplete 
ranges, wouldn’t you want to be able to use them naturally in, e.g., case 
statements?

switch (value) {
case < 3: 
// Small value
case 3…5:
// Medium value
case > 5:
// Large value
}

Doesn’t it seem odd that < 3 is representable as a range but > 5 is not? 

(I’ve shown all these with reasonable spacing, but IIRC, the odd 
no-space-around-range-operators rule is still in effect. That would be worth 
addressing, too, if ranges are really going to be first-class citizens.)

> Matthew Johnson: I think this proposal pushes a bit too hard on consistency 
> of “first / last” vs “prefix / suffix”.  Specifically, I think first(n) and 
> last(n) are significantly more clear than prefix(n) and suffix(n) (and 
> removingFirst(n) / removingLast(n) instead of removingPrefix(n) / 
> removingSuffix(n).  I think the former are immediately clear.  The latter, 
> while consistent in terms of matching semantics with a naming convention 
> suffer in terms of clarity at the call site.  I do not think it is 
> immediately clear that the parameter specifies the *length* of the prefix or 
> suffix.


Agreed. According to the API standards, a method removePrefix() seem like it 
should accept a prefix as an argument.

> Matthew Johnson: Another comment is that you have generally moved index based 
> methods to subscripts rather than named methods.  Why didn’t you take this 
> all the way and change `replaceSubrange` to be a subscript setter?

That’s a good point also.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

A complete reading of the proposal, but without existing knowledge of the 
subtleties of Range implementation.

Garth

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

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

[Adrian Zubarev via swift-evolution]

PR closed, we’ll come back for Swift 3.1. ;)



-- 
Adrian Zubarev
Sent with Airmail

Am 25. Juli 2016 um 23:08:26, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

Fixed PR: https://github.com/apple/swift-evolution/pull/468



-- 
Adrian Zubarev
Sent with Airmail

Am 25. Juli 2016 um 21:35:22, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

We’ve submitted a PR. https://github.com/apple/swift-evolution/pull/466

The proposal was refactored completely.

Introduction

This proposal removes .Type and .Protocol in favor of two generic-style 
syntaxes and aligns global type(of:) function (SE–0096) to match the changes.

Swift-evolution threads:

[Revision] [Pitch] Rename T.Type
[Review] SE–0126: Refactor Metatypes, repurpose T[dot]self and Mirror
[Proposal] Refactor Metatypes, repurpose T[dot]self and Mirror
[Discussion] Seal T.Type into Type
Motivation

Every type T has an instance, accessible through T.self, which represents the 
type itself. Like all instances in Swift, this “type instance” itself has a 
type, which is referred to as its “metatype”. The metatype of T is written 
T.Type. The instance members of the metatype are the same as the static or 
class members of the type.

Metatypes have subtype relationships which reflect the types they represent. 
For instance, given these types:

protocol Proto {}
class Base {}
class Derived: Base, Proto {}
Derived.Type is a subtype of both Base.Type and Proto.Type (and Any.Type). That 
means that Derived.self can be used anywhere a Derived.Type, Base.Type, 
Proto.Type, or Any.Type is called for.

Unfortunately, this simple picture is complicated by protocols. Proto.self is 
actually of type Proto.Protocol, not type Proto.Type. This is necessary because 
the protocol does not, and cannot, conform to itself; it requires conforming 
types to provide static members, but it doesn’t actually provide those members 
itself. Proto.Type still exists, but it is the supertype of all types 
conforming to the protocol.

Making this worse, a generic type always uses T.Type to refer to the type of 
T.self. So when Proto is bound to a generic parameter P, P.Type is the same as 
Proto.Protocol.

This shifting of types is complicated and confusing; we seek to clean up this 
area.

We also believe that, in the long term, the dot syntax will prevent us from 
implementing certain future enhancements that might be valuable:

Moving the implementation of metatypes at least partly into the standard 
library.
Adding members available on all type instances for features like read-write 
reflection or memory layout information.
Conforming metatypes to protocols like Hashable or CustomStringConvertible.
Offering straightforward syntaxes for dynamic features like looking up types by 
name.
Proposed solution

We abolish .Type and .Protocol in favor of two generic-style syntaxes:

Type is the concrete type of T.self. A Type can only ever accept that one 
specific type, not any of its subtypes. If T is a protocol P, than the only 
supertype for Type is Subtype. To be crystal clear here, Type is not 
a subtype of Subtype.

Subtype is the supertype of all Types whose instances are subtypes of T. If 
T is a class, Subtype would accept a Type for any of its subclasses. If T is 
a protocol, Subtype would accept a Type for any conforming concrete type.

In this new notation, some of our existing standard library functions would 
have signatures like:

func unsafeBitCast(_: T, to type: Type) -> U
func sizeof(_: Type) -> Int
func ==(t0: Subtype?, t1: Subtype?) -> Bool
func type(of: T) -> Subtype // SE-0096
That last example, type(of:), is rather interesting, because it is actually a 
magic syntax rather than a function. We propose to align this syntax with Type 
and Subtype by renaming it to Subtype(of:). We believe this is clearer about 
both the type and meaning of the operation.

let instance: NSObject = NSString()
let class: Subtype = Subtype(of: instance)

print(class) // => NSString
Example: visual metatype relationship
Example: generic functions
Future Directions

We could allow extensions on Type and perhaps on Subtype to add members or 
conform them to protocols. This could allow us to remove some standard library 
hacks, like the non-Equatable-related == operators for types.

It may be possible to implement parts of Type as a fairly ordinary final class, 
moving code from the runtime into the standard library.

We could offer a Subtype(ofType: Type, named: String) pseudo-initializer 
which would allow type-safe access to classes by name.

We could offer other reflection and dynamic features on Type and Subtype.

We could move the MemoryLayout members into Type (presumably prefixed), 
removing the rather artificial MemoryLayout enum.

Along with other generics enhancements, there may be a use for a Subprotocol 
syntax for any protocol requiring conformance to protocol T.

Impact on existing code

This is a source-breaking change that can be automated by a migrator.

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[David Hart via swift-evolution]

>   * What is your evaluation of the proposal?

+1 for most of the proposal
-1 for the slicing subscripts

This proposal is well researched, and well written and makes total sense. I 
totally agree that a renaming is required and I agree with most of the proposal 
for the exception of the slicing subscripts. If the goal of the proposal was to 
make those APIs easily discoverable, then those subscripts go completely 
against that:

You need to know that the subscripts exist and if you are looking for a method, 
you will never find them.
They use a new type which is never used anywhere else.

On a more general note, creating new types in the Standard Library only to 
serve as arguments for those fairly rarely used subscripts sounds very 
heavy-weight.

I vote for keeping functions for those operations.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes.

>   * Does this proposal fit well with the feel and direction of Swift?

Yes, except for the subscripts, which look fairly alien to me.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

No.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Followed the original pitch, gave some feedback, re-read the proposal for the 
official review and spent a day pondering it.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Change some collection iterators to use custom types instead of IndexIterator

[Michael Gottesman via swift-evolution]

Submitted the following PR:

https://github.com/apple/swift-evolution/pull/469

Michael

> On Jul 22, 2016, at 2:35 PM, Michael Gottesman via swift-evolution 
>  wrote:
> 
> Hello everyone!
> 
> Iterators are very important for performance since we use them for for loops. 
> By default collections if they do not provide a custom iterator use 
> IndexingIterator as an iterator. IndexingIterator, while only supporting 
> forward movement, is based on indices which possess the ability to go 
> backwards and forwards. For some indices, backwards iteration adds 
> unnecessary cost/complexity.
> In order to preserve future flexibility, we want to change certain of the 
> types to use custom types that are essentially just IndexingIterator. Then 
> later on when we want to implement these optimizations, we can do it on the 
> custom type underneath the hood without changing the API/ABI.
> 
> The reason I use the phrase "some iterators" is that I already know that we 
> definitely want to do this for StringCharacterView but there are potentially 
> other containers in the standard library that this could apply to. I still 
> need to audit these containers for potential applications. That being said 
> given the place where we are in the schedule, I think it is important to 
> start the discussion about the general concept and after I audit the various 
> containers, I will post an update.
> 
> Thoughts, flames, etc?
> Michael
> 
> https://bugs.swift.org/browse/SR-1961
> ___
> 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

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[David Rönnqvist via swift-evolution]

>* What is your evaluation of the proposal?

-1. I think that there might be something to this idea, but am against the 
proposal in its current form for the same reasons that have already been 
stated: flatten has a broader use than just joining sequences/collections, and 
flatten as a name is strongly related to flatMap.

Not merging "flatten" and "joined" but still adding the default arguments would 
make the similarities between the two even more confusing. 

The name of the merged function (if any) needs more consideration, taking into 
account it's broader context and future use.

>* Is the problem being addressed significant enough to warrant a change to 
> Swift?

Not sure.

>* Does this proposal fit well with the feel and direction of Swift?

No. In its current form it's almost an oversimplification.

>* If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Haskell calls the general m (m a) -> m a function for "join", but also has a 
specialized [[a]] -> [a] function called "concat". (The function corresponding 
to "flatMap" is called "bind" in Haskell (although used as an operator), so 
since neither is called flatten or flatMap it doesn't have the confusion where 
one of them would be named so).

>* How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?

Read the proposal.  

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

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

[Adrian Zubarev via swift-evolution]

Fixed PR: https://github.com/apple/swift-evolution/pull/468



-- 
Adrian Zubarev
Sent with Airmail

Am 25. Juli 2016 um 21:35:22, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

We’ve submitted a PR. https://github.com/apple/swift-evolution/pull/466

The proposal was refactored completely.

Introduction

This proposal removes .Type and .Protocol in favor of two generic-style 
syntaxes and aligns global type(of:) function (SE–0096) to match the changes.

Swift-evolution threads:

[Revision] [Pitch] Rename T.Type
[Review] SE–0126: Refactor Metatypes, repurpose T[dot]self and Mirror
[Proposal] Refactor Metatypes, repurpose T[dot]self and Mirror
[Discussion] Seal T.Type into Type
Motivation

Every type T has an instance, accessible through T.self, which represents the 
type itself. Like all instances in Swift, this “type instance” itself has a 
type, which is referred to as its “metatype”. The metatype of T is written 
T.Type. The instance members of the metatype are the same as the static or 
class members of the type.

Metatypes have subtype relationships which reflect the types they represent. 
For instance, given these types:

protocol Proto {}
class Base {}
class Derived: Base, Proto {}
Derived.Type is a subtype of both Base.Type and Proto.Type (and Any.Type). That 
means that Derived.self can be used anywhere a Derived.Type, Base.Type, 
Proto.Type, or Any.Type is called for.

Unfortunately, this simple picture is complicated by protocols. Proto.self is 
actually of type Proto.Protocol, not type Proto.Type. This is necessary because 
the protocol does not, and cannot, conform to itself; it requires conforming 
types to provide static members, but it doesn’t actually provide those members 
itself. Proto.Type still exists, but it is the supertype of all types 
conforming to the protocol.

Making this worse, a generic type always uses T.Type to refer to the type of 
T.self. So when Proto is bound to a generic parameter P, P.Type is the same as 
Proto.Protocol.

This shifting of types is complicated and confusing; we seek to clean up this 
area.

We also believe that, in the long term, the dot syntax will prevent us from 
implementing certain future enhancements that might be valuable:

Moving the implementation of metatypes at least partly into the standard 
library.
Adding members available on all type instances for features like read-write 
reflection or memory layout information.
Conforming metatypes to protocols like Hashable or CustomStringConvertible.
Offering straightforward syntaxes for dynamic features like looking up types by 
name.
Proposed solution

We abolish .Type and .Protocol in favor of two generic-style syntaxes:

Type is the concrete type of T.self. A Type can only ever accept that one 
specific type, not any of its subtypes. If T is a protocol P, than the only 
supertype for Type is Subtype. To be crystal clear here, Type is not 
a subtype of Subtype.

Subtype is the supertype of all Types whose instances are subtypes of T. If 
T is a class, Subtype would accept a Type for any of its subclasses. If T is 
a protocol, Subtype would accept a Type for any conforming concrete type.

In this new notation, some of our existing standard library functions would 
have signatures like:

func unsafeBitCast(_: T, to type: Type) -> U
func sizeof(_: Type) -> Int
func ==(t0: Subtype?, t1: Subtype?) -> Bool
func type(of: T) -> Subtype // SE-0096
That last example, type(of:), is rather interesting, because it is actually a 
magic syntax rather than a function. We propose to align this syntax with Type 
and Subtype by renaming it to Subtype(of:). We believe this is clearer about 
both the type and meaning of the operation.

let instance: NSObject = NSString()
let class: Subtype = Subtype(of: instance)

print(class) // => NSString
Example: visual metatype relationship
Example: generic functions
Future Directions

We could allow extensions on Type and perhaps on Subtype to add members or 
conform them to protocols. This could allow us to remove some standard library 
hacks, like the non-Equatable-related == operators for types.

It may be possible to implement parts of Type as a fairly ordinary final class, 
moving code from the runtime into the standard library.

We could offer a Subtype(ofType: Type, named: String) pseudo-initializer 
which would allow type-safe access to classes by name.

We could offer other reflection and dynamic features on Type and Subtype.

We could move the MemoryLayout members into Type (presumably prefixed), 
removing the rather artificial MemoryLayout enum.

Along with other generics enhancements, there may be a use for a Subprotocol 
syntax for any protocol requiring conformance to protocol T.

Impact on existing code

This is a source-breaking change that can be automated by a migrator.

We suggest the following migration process; this can differ from the final 
migration process implemented by the core team if this proposal will be 
accepted:

Any.Type is 

Re: [swift-evolution] [Proposal] Formalized Ordering, take 2

[David Sweeris via swift-evolution]

> On Jul 25, 2016, at 2:28 PM, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> 
>> On 25 Jul 2016, at 21:23, Nevin Brackett-Rozinsky 
>> > 
>> wrote:
>> 
>> My one question is, will I be able to write 
>> `someCollection.sort(.ascending)` and get the expected result? (This could 
>> be an additive future direction.)
> 
> 
> To sort to ascending order, you'd still just call `.sort()` with no arguments.
> 
> To limit the scope of this proposal somewhat, I moved the introduction of new 
> sorting functions into the Future directions section. All of those changes 
> are additive in a way or another:
> 
> 1. The default .sort() function would use `<=>` instead of `<`.
> 
> (a) On the one hand, we'd get improved performance in cases like 
> Array.sort() where doing another `<` comparison would be more costly.
> (b) On the other hand, we'd get well-defined behaviour when sorting Double 
> arrays containing NaNs, because all non-NaN values would be sorted into one 
> contiguous subrange of the result.

Two quick questions… 
1) What about adding an `isInvalid` case? That way types (such as Double/Float) 
which have “unordered” values can check for an invalid comparison.
2) What about making `Ordering` a tuple instead of an enum? “typealias Ordering 
= (isLessThan: Bool, isEqual: Bool, isGreaterThan: Bool, isInvalid: Bool)”? 
It’d take up more space on the stack, but I think this:
func < (lhs: Int, rhs: Int) -> Bool {
return (lhs <=> rhs).isLessThan
}
or even this:
func < (lhs: Int, rhs: Int) -> Bool {
let ord =  (lhs <=> rhs).isLessThan
return ord.isLessThan && !ord.isInvalid
}

would execute faster than this:
func < (lhs: Int, rhs: Int) -> Bool {
switch (lhs <=> rhs) {
case lessThan: return true
default: return false
}

because there wouldn’t be any branching beyond what’s necessary to do the 
actual comparison.

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

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Pyry Jahkola via swift-evolution]

> On 25 Jul 2016, at 09:10, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0132: Rationalizing Sequence end-operation names" begins 
> now and runs through July 26.  Apologies for the short review cycle, but 
> we’re right up against the end of source breaking changes for Swift 3.  The 
> proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
> 
>   * What is your evaluation of the proposal?

+1 to the method renames.
-1 to the slice syntax proposed.

I find the introduction of unary operators confusing. I don't think it's good 
design that you need to remove a space when moving from the old syntax to the 
new one:

array[array.startIndex ..< someIndex] // before
array[..   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes.

>   * Does this proposal fit well with the feel and direction of Swift?

Yes.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

N/A

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?


Quick reading.

Thanks to Brent for the effort!

— Pyry

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

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Jacob Bandes-Storch via swift-evolution]

On Mon, Jul 25, 2016 at 1:11 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> I'm giving the overall idea a +0 and the specific proposal as currently
> written a -1, because I think this is a much more complicated bikeshed
> than it appears to be on the surface and the proposal doesn't begin to
> address the issues.  Specifically, I'm concerned about these points:
>
> * `flatten` works on Optional and sequences of Optional.
>   How does it make sense to rename these operations “join?”
>

Does it really? These don't work for me:

let x = [1,2,nil,4]
x.flatten()

let y = Optional(Optional(42))
y.flatten()



> * The name and semantics of `flatten` is linked to that of `flatMap`.
>   It's almost impossible to explain what `flatMap` does without
>   reference to `flatten`.  Will it make sense to explain `flatMap` in
>   terms of `joined`?
>

I think the current documentation comments do a pretty good job:

On the [T].flatMap(T -> U?) -> [U] version:
  /// Returns an array containing the non-`nil` results of calling the given
  /// transformation with each element of this sequence.

On the [T].flatMap(T -> [U]) -> [U] version:
  /// Returns an array containing the concatenated results of calling the
  /// given transformation with each element of this sequence.

(This one also mentions array.map(transform).flatten(), which would become
array.map(transform).joined().)



>
> * `flatten` is a functional term of art in the same family as `flatMap`.
>   We have good reasons to consider changing some of the other names in
>   this family, such as `filter` and `reduce`, but that idea has met with
>   significant resistance on the list.  How far should we go?  Does it
>   make sense to make this one change alone?
>

I wouldn't argue for renaming flatMap. I'm not suggesting to change the
name of flatten() because I don't like it (I do); I'm suggesting to change
it because — unlike Ruby, whose Array has #flatten and #join, but the
latter is *only* for producing strings — we seem to have the *same*
functionality behind 2 differently-named APIs.

(Actually I feel like flatMap is a more fundamental functional method in
the family of filter and reduce than flatten/joined is. flatten is just
flatMap({$0}), although as pointed out above, flatten isn't actually
available in all the places that flatMap({$0}) would work.)

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

Re: [swift-evolution] [Review] SE-0131: Add AnyHashable to the standard library

[Pyry Jahkola via swift-evolution]

> On 24 Jul 2016, at 01:26, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0131: Add AnyHashable to the standard library" begins now 
> and runs through July 25.  This proposal is a bit unusual, since it is a late 
> additive proposal.  The reason we need to do something here is as a critical 
> part of "SE-0116: Import Objective-C id as Swift Any type”, enabling 
> importing untyped NSDictionary's and NSSet’s properly.  The core team 
> considers this already conceptually approved for Swift 3 as part of SE-0116, 
> but would greatly appreciate feedback on the details of the proposed design.
> 
> The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md
> 
>   * What is your evaluation of the proposal?

+1, this is a nice addition, and useful at times.

There's one very obscure gotcha 

 with AnyHashable that subclass instances of a Hashable base class should be 
cast to the base type before wrapping into AnyHashable, otherwise such wrapped 
values may break the equivalence law of symmetry (`a == b` iff `b == a`).

But now that most of Foundation's class clusters are bridged into value types, 
that problem is unlikely to occur to anyone anymore.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

So and so.

>   * Does this proposal fit well with the feel and direction of Swift?

Yes. Maybe it will also help us gain more experience when designing real 
existential types.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

A bit of a hack compared to real existentials. But a good one.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick reading.

— Pyry

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

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Matthew Johnson via swift-evolution]

> On Jul 25, 2016, at 3:22 PM, Nate Cook via swift-evolution 
>  wrote:
> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
> 
> First, a big thanks to Brent for all the work in categorizing, describing, 
> and justifying all these changes! I'm largely in favor of the new method 
> names—several of the renamings lead to better grouping of related methods, 
> and I think the compromises that have been made make lots of sense.
> 
> However, I'm not in favor of replacing the existing slicing methods with new 
> subscript syntax that uses partial ranges. These represent a significant new 
> vernacular for Swift that none of us has used before in the language. I'm 
> additionally worried about the discoverability and clarity of this kind of 
> slicing. In the other languages I've used that support similar kinds of 
> subscripting, it always seems too clever by half—fussy to write and 
> frequently confusing to read.
> 
> At this late date, I propose keeping the slicing methods (i.e., 
> prefix(upTo:), prefix(through:), and suffix(from:)) and considering adopting 
> the new slicing-via-subscript syntax in a future proposal.

This seems like a reasonable alternative.  The slicing / subscript syntax can 
reasonably be viewed as sugar for the named methods.

> 
> Best,
> Nate
> 
> ___
> 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

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Dave Abrahams via swift-evolution]

on Sun Jul 24 2016, Xiaodi Wu  wrote:

> On Mon, Jul 25, 2016 at 1:10 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hello Swift community,
>>
>> The review of "SE-0132: Rationalizing Sequence end-operation names" begins
>> now and runs through July 26.  Apologies for the short review cycle, but
>> we’re right up against the end of source breaking changes for Swift 3.  The
>> proposal is available here:
>>
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
>>
>> Reviews are an important part of the Swift evolution process. All reviews
>> should be sent to the swift-evolution mailing list at
>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> or, if you would like to keep your feedback private, directly to the
>> review manager.
>>
>> What goes into a review?
>>
>> The goal of the review process is to improve the proposal under review
>> through constructive criticism and contribute to the direction of Swift.
>> When writing your review, here are some questions you might want to answer
>> in your review:
>>
>> * What is your evaluation of the proposal?
>>
>
> The end product is really quite beautiful. This proposal very much succeeds
> at rationalizing all names without introducing terminology that's
> unprecedented. I very much appreciate that properties or functions named
> `first` now always return one or zero elements and that ranges are always
> indicated with range operators. The only quibble is that `hasPrefix(_:by:)`
> might be more appropriately `hasPrefix(_:comparingBy:)`, as the standalone
> preposition doesn't quite make sense IMO.

It makes as much sense as in `elementsEqual(_:by:)` et. al, IMO.


>> * Is the problem being addressed significant enough to warrant a
>> change to Swift?
>>
>
> Yes.
>
>> * Does this proposal fit well with the feel and direction of Swift?
>>
>
> Yes, very much so.
>
>> * If you have used other languages or libraries with a similar
>> feature, how do you feel that this proposal compares to those?
>>
>
> This proposal rationalizes Swift-specific names, so not sure how to compare
> to other languages.
>
>> * How much effort did you put into your review? A glance, a quick
>> reading, or an in-depth study?
>>
>
> A quick reading of this version; I followed the original discussion and
> thought about it more in-depth then.
>
>> More information about the Swift evolution process is available at
>>
>> https://github.com/apple/swift-evolution/blob/master/process.md
>>
>> Thank you,
>>
>> -Chris Lattner
>> Review Manager
>> ___
>> 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
>

-- 
Dave

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

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Nate Cook via swift-evolution]

>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md

First, a big thanks to Brent for all the work in categorizing, describing, and 
justifying all these changes! I'm largely in favor of the new method 
names—several of the renamings lead to better grouping of related methods, and 
I think the compromises that have been made make lots of sense.

However, I'm not in favor of replacing the existing slicing methods with new 
subscript syntax that uses partial ranges. These represent a significant new 
vernacular for Swift that none of us has used before in the language. I'm 
additionally worried about the discoverability and clarity of this kind of 
slicing. In the other languages I've used that support similar kinds of 
subscripting, it always seems too clever by half—fussy to write and frequently 
confusing to read.

At this late date, I propose keeping the slicing methods (i.e., prefix(upTo:), 
prefix(through:), and suffix(from:)) and considering adopting the new 
slicing-via-subscript syntax in a future proposal.

Best,
Nate

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

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Dave Abrahams via swift-evolution]

on Sun Jul 24 2016, Chris Lattner  wrote:

> Hello Swift community,
>
> The review of "SE-0133: Rename `flatten()` to `joined()`" begins now
> and runs through July 26.  Apologies for the short review cycle, but
> we’re right up against the end of source breaking changes for Swift 3.
> The proposal is available here:
>
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md
>
> Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
>
>   https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the review 
> manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of
> Swift. When writing your review, here are some questions you might
> want to answer in your review:
>
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
>   https://github.com/apple/swift-evolution/blob/master/process.md

I'm giving the overall idea a +0 and the specific proposal as currently
written a -1, because I think this is a much more complicated bikeshed
than it appears to be on the surface and the proposal doesn't begin to
address the issues.  Specifically, I'm concerned about these points:

* `flatten` works on Optional and sequences of Optional.
  How does it make sense to rename these operations “join?”

* The name and semantics of `flatten` is linked to that of `flatMap`.
  It's almost impossible to explain what `flatMap` does without
  reference to `flatten`.  Will it make sense to explain `flatMap` in
  terms of `joined`?

* `flatten` is a functional term of art in the same family as `flatMap`.
  We have good reasons to consider changing some of the other names in
  this family, such as `filter` and `reduce`, but that idea has met with
  significant resistance on the list.  How far should we go?  Does it
  make sense to make this one change alone?

I could be convinced to change my evaluation of the proposal if there
are good answers to these questions, but until then, I'm not won over.

-- 
Dave

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

Re: [swift-evolution] [Review] SE-0131: Add AnyHashable to the standard library

[Nate Cook via swift-evolution]

>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md

+1!

This proposal looks great to me. I only have one nitpick: it looks like there's 
a '_Hashable' protocol used in the Dictionary extension to get around the limit 
on generic subscripts. Swift has managed to remove most (all?) underscored 
protocols from public APIs, so I would just suggest that the implementation 
consider an alternate name that isn't underscored. Something like 
'HashableBase' would still imply that the protocol is more of an implementation 
detail than a useful protocol on its own.

Nate

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

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

[Adrian Zubarev via swift-evolution]

We’ve submitted a PR. https://github.com/apple/swift-evolution/pull/466

The proposal was refactored completely.

Introduction

This proposal removes .Type and .Protocol in favor of two generic-style 
syntaxes and aligns global type(of:) function (SE–0096) to match the changes.

Swift-evolution threads:

[Revision] [Pitch] Rename T.Type
[Review] SE–0126: Refactor Metatypes, repurpose T[dot]self and Mirror
[Proposal] Refactor Metatypes, repurpose T[dot]self and Mirror
[Discussion] Seal T.Type into Type
Motivation

Every type T has an instance, accessible through T.self, which represents the 
type itself. Like all instances in Swift, this “type instance” itself has a 
type, which is referred to as its “metatype”. The metatype of T is written 
T.Type. The instance members of the metatype are the same as the static or 
class members of the type.

Metatypes have subtype relationships which reflect the types they represent. 
For instance, given these types:

protocol Proto {}
class Base {}
class Derived: Base, Proto {}
Derived.Type is a subtype of both Base.Type and Proto.Type (and Any.Type). That 
means that Derived.self can be used anywhere a Derived.Type, Base.Type, 
Proto.Type, or Any.Type is called for.

Unfortunately, this simple picture is complicated by protocols. Proto.self is 
actually of type Proto.Protocol, not type Proto.Type. This is necessary because 
the protocol does not, and cannot, conform to itself; it requires conforming 
types to provide static members, but it doesn’t actually provide those members 
itself. Proto.Type still exists, but it is the supertype of all types 
conforming to the protocol.

Making this worse, a generic type always uses T.Type to refer to the type of 
T.self. So when Proto is bound to a generic parameter P, P.Type is the same as 
Proto.Protocol.

This shifting of types is complicated and confusing; we seek to clean up this 
area.

We also believe that, in the long term, the dot syntax will prevent us from 
implementing certain future enhancements that might be valuable:

Moving the implementation of metatypes at least partly into the standard 
library.
Adding members available on all type instances for features like read-write 
reflection or memory layout information.
Conforming metatypes to protocols like Hashable or CustomStringConvertible.
Offering straightforward syntaxes for dynamic features like looking up types by 
name.
Proposed solution

We abolish .Type and .Protocol in favor of two generic-style syntaxes:

Type is the concrete type of T.self. A Type can only ever accept that one 
specific type, not any of its subtypes. If T is a protocol P, than the only 
supertype for Type is Subtype. To be crystal clear here, Type is not 
a subtype of Subtype.

Subtype is the supertype of all Types whose instances are subtypes of T. If 
T is a class, Subtype would accept a Type for any of its subclasses. If T is 
a protocol, Subtype would accept a Type for any conforming concrete type.

In this new notation, some of our existing standard library functions would 
have signatures like:

func unsafeBitCast(_: T, to type: Type) -> U
func sizeof(_: Type) -> Int
func ==(t0: Subtype?, t1: Subtype?) -> Bool
func type(of: T) -> Subtype // SE-0096
That last example, type(of:), is rather interesting, because it is actually a 
magic syntax rather than a function. We propose to align this syntax with Type 
and Subtype by renaming it to Subtype(of:). We believe this is clearer about 
both the type and meaning of the operation.

let instance: NSObject = NSString()
let class: Subtype = Subtype(of: instance)

print(class) // => NSString
Example: visual metatype relationship
Example: generic functions
Future Directions

We could allow extensions on Type and perhaps on Subtype to add members or 
conform them to protocols. This could allow us to remove some standard library 
hacks, like the non-Equatable-related == operators for types.

It may be possible to implement parts of Type as a fairly ordinary final class, 
moving code from the runtime into the standard library.

We could offer a Subtype(ofType: Type, named: String) pseudo-initializer 
which would allow type-safe access to classes by name.

We could offer other reflection and dynamic features on Type and Subtype.

We could move the MemoryLayout members into Type (presumably prefixed), 
removing the rather artificial MemoryLayout enum.

Along with other generics enhancements, there may be a use for a Subprotocol 
syntax for any protocol requiring conformance to protocol T.

Impact on existing code

This is a source-breaking change that can be automated by a migrator.

We suggest the following migration process; this can differ from the final 
migration process implemented by the core team if this proposal will be 
accepted:

Any.Type is migrated to Subtype.
If T.Type is in function parameter, where T is a generic type parameter, then 
it’s migrated to Type.
Every T.Protocol will be replaced with Type.
Every T.Type in a dynamic 

Re: [swift-evolution] Swift 3.1 vs Swift 4

[Brandon Knope via swift-evolution]

Thanks Chris!  I wish you and the team the best week :)

Brandon 

> On Jul 25, 2016, at 2:34 PM, Chris Lattner  wrote:
> 
> 
>> On Jul 25, 2016, at 10:02 AM, Brandon Knope via swift-evolution 
>>  wrote:
>> 
>> +1 for clarification
>> 
>> Swift 4 begins August 1st…does this mean Swift 3.* are only for bug fixes 
>> and anything that has been approved and has not made it into 3.0?
> 
> August 1 is when planning for all releases beyond Swift 3 starts.  I strongly 
> suspect there will be at least one 3.x release.  Please wait to talk about it 
> next week, there is too much going on right now.
> 
> -Chris
> 
>> 
>> Brandon
>> 
>>> On Jul 25, 2016, at 12:55 PM, Erica Sadun via swift-evolution 
>>>  wrote:
>>> 
>>> Will there be a door of opportunity to propose for Swift 3.1 rather than 
>>> Swift 4 after 8/1? I've been sitting on `sequence(first, next, while)`  
>>> (https://github.com/erica/swift/tree/unfold, 
>>> https://bugs.swift.org/browse/SR-2065) because it's additive. I think it 
>>> will do a lot to ameliorate the ill-will raised by SE-0007. 
>>> 
>>> Thanks for any guidance.
>>> 
>>> -- E
>>> 
>>> ___
>>> 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
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Formalized Ordering, take 2

[Pyry Jahkola via swift-evolution]

> On 25 Jul 2016, at 21:23, Nevin Brackett-Rozinsky 
>  wrote:
> 
> My one question is, will I be able to write `someCollection.sort(.ascending)` 
> and get the expected result? (This could be an additive future direction.)


To sort to ascending order, you'd still just call `.sort()` with no arguments.

To limit the scope of this proposal somewhat, I moved the introduction of new 
sorting functions into the Future directions section. All of those changes are 
additive in a way or another:

1. The default .sort() function would use `<=>` instead of `<`.

(a) On the one hand, we'd get improved performance in cases like 
Array.sort() where doing another `<` comparison would be more costly.
(b) On the other hand, we'd get well-defined behaviour when sorting Double 
arrays containing NaNs, because all non-NaN values would be sorted into one 
contiguous subrange of the result.

That's an additive change because (a) types implementing total order will still 
sort according to the same spec as `.sort(by: <)`.

2. If I had it my way, the default .sort() would also become stable, and the 
programmer could opt in to using a faster unstable sort variant. There are 
cases where an unstable sort performs better, but a stable sort is a better 
default, not least because it's usually what people want when sorting a table 
by a given column.

3. Several functions (e.g. `.sort(by:)`) would be paired with a 
`frobnicate(ordering:)` variant where the block returns `Ordering` instead of 
`Bool`. For sorting to descending order, you'd call something like 
`someCollection.sort(ordering: Ordering.reversing(<=>))`. Or whatever naming 
we'll end up with.

— Pyry

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

Re: [swift-evolution] [Proposal] Formalized Ordering, take 2

[Pyry Jahkola via swift-evolution]

> On 25 Jul 2016, at 18:51, Björn Forster  wrote:
> 
> Could you please explain for someone as simple minded as me why there is (or 
> has to be) a difference in the implementation of <, <= and >, >=?
> Sorry, but I don't get into my head why there is/has to be a preference for 
> one side. Could you or someone else point out (in the proposal) why there is 
> a need/what is the reason for this?
> I assume that this might not be obvious to some other people on the first 
> look, too.

The reason is two-fold:

Firstly, and most importantly, because we want the law of antisymmetry (that `a 
< b` iff `b > a`, and likewise for ≤ and ≥) to hold even in the presence of 
strange types. Turning only one operator of every such pair into customisation 
points makes it essentially impossible to break that law.

Secondly, because we want to minimise the surface area of Comparable to keep 
the API as simple as possible. The drawback of my design is that while it 
manages to alleviate many subtleties of IEEE-754, it also contains many member 
functions (essentially all but `<=>`) which should not be customised for most 
types in practice.

— Pyry

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

Re: [swift-evolution] [Proposal] Formalized Ordering, take 2

[Xiaodi Wu via swift-evolution]

On Mon, Jul 25, 2016 at 1:52 PM, Stephen Canon via swift-evolution <
swift-evolution@swift.org> wrote:

> First, this is orthogonal to "adhering to the standard".
>  isTotallyOrdered( ) provides the total order predicate required by IEEE
> 754.  The standard has no opinion about whether or not `<=>` is bound to
> that predicate.
>
> Personally, I would be OK with using the `isTotallyOrdered` semantics for
> `<=>`.  However, it leads to some behavior that would be surprising for
> novices: x is NaN, and a set S is { 1, 2, NaN }, but S does not contain x.
> I am skeptical that the distinction between NaN payloads is salient *for
> generic code written on Comparable types*.  It *is* salient for some
> (rare!) floating-point specific code, but `isTotallyOrdered` is available
> for floating-point types.
>
> There’s also the issue that if we want to be able to point at IEEE 754 and
> say “<=> implements a total order on Level N”, distinguishing distinct NaNs
> has consequences for other values.  In particular, it means that a decimal
> type should distinguish between 1e0 and 10e-1, because it would necessarily
> be an ordering on level 3 or 4.  For { 1, 20 } to not contain 2e1 seems
> highly dubious to me.
>

Given your reasoning, I have to agree that ordering on level 2 is the only
sensible option for generic code written on Comparable types.

With this resolution, I think Dave has largely convinced me that the design
as originally proposed (shadowable but not overridable `==` forwards to
`===`, etc.) should be workable for wisely chosen implementations of `===`
and `<=>`.

– Steve
>
> On Jul 25, 2016, at 2:23 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
>
> Pyry, this proposal looks great to me. My one question is, will I be able
> to write `someCollection.sort(.ascending)` and get the expected
> result? (This could be an additive future direction.)
>
> Stephen, what is your rationale for wanting `<=>` to identify NaN values
> with different payloads as `.equal`?
>
> I believe the IEEE 754 total order specification uses the bit-pattern just
> as Pyry’s proposal does, and there is value is adhering to the standard.
> Besides, if someone intentionally wishes to consider all NaN values as
> equivalent they can use `.isNaN` (or even map them to .nan first for
> uniformity).
>
> Nevin
>
>
> On Mon, Jul 25, 2016 at 1:26 PM, Stephen Canon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hi Pyry —
>>
>> Dave and I spent some time discussing the details of how this applies to
>> floating point earlier today.  We’re now in agreement that <=> should treat
>> -0 and +0 as distinct, and treat all NaNs as .equal.  There are three
>> motivating considerations:
>>
>> 1. Although -0 and +0 are “IEEE 754 equal”, there is no computation that
>> can produce both of them.  In the parlance of IEEE 754, for any rounding
>> mode, the sets of real values that round to them are disjoint.  Because of
>> this, if -0 and +0 appear as members of a set, or as keys in a dictionary,
>> they necessarily are the result of distinct computations or data.
>>
>> 2. Substitutability.  Adopting these semantics means that if `x <=> y` is
>> `.equal`, `f(x) <=> f(y)` is also `.equal` for any computation `f(x)` that
>> depends on the represented value (as opposed to the encoding) of its
>> argument.
>>
>> 3. 754 defines four “specification levels”, or models:
>>
>> - Level 1: The two-point compactification of the reals, or “extended real
>> numbers”.
>> - Level 2: The set of representable floating-point data: {-inf … -0}
>> union { 0 … inf } union { NaN }.
>> - Level 3: The set of representations of floating-point data:
>> sign-exponent-significand triples, +/-inf, qNaN, sNaN.
>> - Level 4: Floating-point encodings (bit patterns).
>>
>> The `<=>` semantics we propose constitute a total order on level 2, which
>> is the computable model closest to the (reasonably familiar) extended real
>> numbers.  Treating -0 and +0 as .equal would put us in a bit of a no-man’s
>> land between levels 1 and 2.
>>
>> Thanks,
>> – Steve
>>
>> On Jul 25, 2016, at 7:41 AM, Pyry Jahkola  wrote:
>>
>> Since we're running short on time, and the previous discussion thread
>> diverged, here's my attempt to fix the Comparable protocol.
>>
>> *Pull request:* https://github.com/apple/swift-evolution/pull/464
>>
>> TL;DR:
>>
>> 1. Equatable remains unchanged, while Comparable bloats a bit to support
>> several use cases.
>> 2. `a <=> b` is well-defined even if either value is NaN. Zero is equal
>> to minus zero.
>> 3. Types are not strictly required to become totally ordered, even if
>> it's strongly recommended.
>>
>> — — —
>>
>> I simply can't see how a pure total order version of Comparable would fit
>> the standard way floating point values are expected to behave. However, I
>> think we can reach a satisfactory conclusion, one that involves no crashing
>> in the standard library, which is what I previously 

Re: [swift-evolution] [Draft] Swift implementation Regex added

[Joshua Alvarado via swift-evolution]

Okay thanks for taking a look I will have a better implementation ready for 
August 1st. 

Alvarado, Joshua

> On Jul 25, 2016, at 11:14 AM, Will Field-Thompson  wrote:
> 
> The date for Swift 4 proposals is August 1 
> (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024424.html),
>  so you might want to try posting this again then.
> 
>> On Mon, Jul 25, 2016 at 12:55 PM Brandon Knope via swift-evolution 
>>  wrote:
>> There has been talk on this list of adding a fully featured RegEx feature. 
>> It has been pushed back to a later release as the window for Swift 3 is 
>> closing
>> 
>> Brandon
>> 
>>> On Jul 25, 2016, at 12:24 PM, Joshua Alvarado via swift-evolution 
>>>  wrote:
>>> 
>>> My first proposal so take it easy on me :) This is a draft so feedback is 
>>> very welcome and any help. Thank you swiftys.
>>> 
>>> *Introduction*
>>> 
>>> Swift doesn’t have a native implementation of Regex which is included in 
>>> many other languages. This proposal is a suggestion to introduce a native 
>>> Regex type into Swift. 
>>> 
>>> *Motivation*
>>> Working with NSRegularExpression is not very swift like and it is lacking 
>>> in ease of use. More motivation comes from also comes from one of the goals 
>>> of swift with Swiftification of imported Objective-C APIs.
>>> 
>>> *Proposed solution*
>>> 
>>> Add a struct of Regex that can be used with the String type.
>>> 
>>> Regex can be initialized with a String pattern of the Regex and have simple 
>>> properties such as accessing the pattern and toString of the pattern.
>>> 
>>> String to be extended for Regex support. Functions to add be:
>>> 
>>> mutating func replace(regex: Regex, withString: String)
>>> search(regex: Regex) -> Character.Index
>>> match(regex: Regex) -> Match? // Match is another new type
>>> 
>>> Match is a new type that can give more information on a regex match. Match 
>>> will have properties such as numberOfMatches, components (the substring of 
>>> matches in an array), and rangeOfMatch.
>>> 
>>> *Impact on existing code*
>>> NSRegularExpression will stay and can still be used in combination, but a 
>>> more swift like implementation will be out of the box in Swift.
>>> 
>>> *Alternatives considered*
>>> Regex could be a protocol added to String for matching.
>>> 
>>> 
>>> ___
>>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 vs Swift 4

[Chris Lattner via swift-evolution]

> On Jul 25, 2016, at 10:02 AM, Brandon Knope via swift-evolution 
>  wrote:
> 
> +1 for clarification
> 
> Swift 4 begins August 1st…does this mean Swift 3.* are only for bug fixes and 
> anything that has been approved and has not made it into 3.0?

August 1 is when planning for all releases beyond Swift 3 starts.  I strongly 
suspect there will be at least one 3.x release.  Please wait to talk about it 
next week, there is too much going on right now.

-Chris

> 
> Brandon
> 
>> On Jul 25, 2016, at 12:55 PM, Erica Sadun via swift-evolution 
>> > wrote:
>> 
>> Will there be a door of opportunity to propose for Swift 3.1 rather than 
>> Swift 4 after 8/1? I've been sitting on `sequence(first, next, while)`  
>> (https://github.com/erica/swift/tree/unfold 
>> , 
>> https://bugs.swift.org/browse/SR-2065 
>> ) because it's additive. I think it 
>> will do a lot to ameliorate the ill-will raised by SE-0007 
>> .
>>  
>> 
>> Thanks for any guidance.
>> 
>> -- E
>> 
>> ___
>> 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

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

Re: [swift-evolution] [Proposal] Formalized Ordering, take 2

[Nevin Brackett-Rozinsky via swift-evolution]

Pyry, this proposal looks great to me. My one question is, will I be able
to write `someCollection.sort(.ascending)` and get the expected
result? (This could be an additive future direction.)


Stephen, what is your rationale for wanting `<=>` to identify NaN values
with different payloads as `.equal`?

I believe the IEEE 754 total order specification uses the bit-pattern just
as Pyry’s proposal does, and there is value is adhering to the standard.
Besides, if someone intentionally wishes to consider all NaN values as
equivalent they can use `.isNaN` (or even map them to .nan first for
uniformity).

Nevin


On Mon, Jul 25, 2016 at 1:26 PM, Stephen Canon via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi Pyry —
>
> Dave and I spent some time discussing the details of how this applies to
> floating point earlier today.  We’re now in agreement that <=> should treat
> -0 and +0 as distinct, and treat all NaNs as .equal.  There are three
> motivating considerations:
>
> 1. Although -0 and +0 are “IEEE 754 equal”, there is no computation that
> can produce both of them.  In the parlance of IEEE 754, for any rounding
> mode, the sets of real values that round to them are disjoint.  Because of
> this, if -0 and +0 appear as members of a set, or as keys in a dictionary,
> they necessarily are the result of distinct computations or data.
>
> 2. Substitutability.  Adopting these semantics means that if `x <=> y` is
> `.equal`, `f(x) <=> f(y)` is also `.equal` for any computation `f(x)` that
> depends on the represented value (as opposed to the encoding) of its
> argument.
>
> 3. 754 defines four “specification levels”, or models:
>
> - Level 1: The two-point compactification of the reals, or “extended real
> numbers”.
> - Level 2: The set of representable floating-point data: {-inf … -0} union
> { 0 … inf } union { NaN }.
> - Level 3: The set of representations of floating-point data:
> sign-exponent-significand triples, +/-inf, qNaN, sNaN.
> - Level 4: Floating-point encodings (bit patterns).
>
> The `<=>` semantics we propose constitute a total order on level 2, which
> is the computable model closest to the (reasonably familiar) extended real
> numbers.  Treating -0 and +0 as .equal would put us in a bit of a no-man’s
> land between levels 1 and 2.
>
> Thanks,
> – Steve
>
> On Jul 25, 2016, at 7:41 AM, Pyry Jahkola  wrote:
>
> Since we're running short on time, and the previous discussion thread
> diverged, here's my attempt to fix the Comparable protocol.
>
> *Pull request:* https://github.com/apple/swift-evolution/pull/464
>
> TL;DR:
>
> 1. Equatable remains unchanged, while Comparable bloats a bit to support
> several use cases.
> 2. `a <=> b` is well-defined even if either value is NaN. Zero is equal to
> minus zero.
> 3. Types are not strictly required to become totally ordered, even if it's
> strongly recommended.
>
> — — —
>
> I simply can't see how a pure total order version of Comparable would fit
> the standard way floating point values are expected to behave. However, I
> think we can reach a satisfactory conclusion, one that involves no crashing
> in the standard library, which is what I previously suggested.
>
> What I'm trying to fix is so that all operations listed in
> https://dl.dropboxusercontent.com/u/217402/Comparable.pdf abide to laws
> for types without incomparable values, and that types with weaker order can
> still work in *some* well-defined way outside their totally ordered range.
>
> PS. Forgive me Robert, Jaden, and Harlan for not syncing with you, for
> time is tight. I can pull back or revise the proposal if you don't want to
> be involved.
>
> — Pyry
>
>
>
>
> Formalized Ordering
>
>- Proposal: SE-
>
> 
>- Authors: Robert Widmann , Jaden Geller
>, Harlan Haskins
>, Pyry Jahkola
>
>- Status: Awaiting review
>- Review manager: TBD
>
>
> 
> Introduction
>
> This proposal cleans up the semantics of ordering relations in the
> standard library. Our goal is to formalize the total ordering semantics of
> the Comparable protocol and still provide accessible ordering definitions
> for types without total ordering semantics.
>
> 
> Motivation
>
> The standard comparison operators have an intuitive meaning to
> programmers. Swift encourages encoding that in an implementation of
> Comparable that respects the rules of a total order
> . The standard library takes
> advantage of 

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Daniel Duan via swift-evolution]

> On Jul 24, 2016, at 11:10 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>   * What is your evaluation of the proposal?

-1. I find the motivation section troubling. It’s simply an assertion that this 
“should” happen. From reading the rest of the proposed text as well as others 
reviews in support, I get the impression that combining flatten and joined 
results in an API that’s more “pleasing” to some because they do similar things.

IMO, the fact that they are similar is why we should *not* give them the same 
name. In summary, we would be trading 2 simpler APIs to a complex one. I don’t 
believe that’s a goal for Swift.

Both methods returns a corresponding Sequence, FlattenSequence and 
JoinedSequence. Creating a FlattenSequence is always lazy and has O(1) 
complexity, iterating over it is also a simple and efficient process. 
JoinedSequence on the other hand, has O(length_of_separator) complexity at 
init, and involves additional state juggling at iteration. Yes, if the 
separator is skipped, we could make the new `joined` behave exactly like 
`flatten`, and put its merits in the documentation, and warn them about the 
complexity difference, and explain whether/how it’s different to provide “” and 
nil when calling this on a string…

Hopefully, you can see why I’d rather give user `flatten` when that’s all they 
are looking for.  


>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
No.

>   * Does this proposal fit well with the feel and direction of Swift?
Maybe. Less sometimes is good. But in this case it incurs a cost.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
flatten is a well understood and commonly used operation in many PLs.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
read the proposal and posts on this list.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Swift implementation Regex added

[Will Field-Thompson via swift-evolution]

The date for Swift 4 proposals is August 1 (
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024424.html),
so you might want to try posting this again then.

On Mon, Jul 25, 2016 at 12:55 PM Brandon Knope via swift-evolution <
swift-evolution@swift.org> wrote:

> There has been talk on this list of adding a fully featured RegEx feature.
> It has been pushed back to a later release as the window for Swift 3 is
> closing
>
> Brandon
>
> On Jul 25, 2016, at 12:24 PM, Joshua Alvarado via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> My first proposal so take it easy on me :) This is a draft so feedback is 
> very welcome and any help. Thank you swiftys.
>
> *Introduction*
>
> Swift doesn’t have a native implementation of Regex which is included in many 
> other languages. This proposal is a suggestion to introduce a native Regex 
> type into Swift.
>
> *Motivation*
> Working with NSRegularExpression is not very swift like and it is lacking in 
> ease of use. More motivation comes from also comes from one of the goals of 
> swift with Swiftification of imported Objective-C APIs.
>
> *Proposed solution*
>
> Add a struct of Regex that can be used with the String type.
>
> Regex can be initialized with a String pattern of the Regex and have simple 
> properties such as accessing the pattern and toString of the pattern.
>
> String to be extended for Regex support. Functions to add be:
>
> mutating func replace(regex: Regex, withString: String)
> search(regex: Regex) -> Character.Index
> match(regex: Regex) -> Match? // Match is another new type
>
> Match is a new type that can give more information on a regex match. Match 
> will have properties such as numberOfMatches, components (the substring of 
> matches in an array), and rangeOfMatch.
>
> *Impact on existing code*
> NSRegularExpression will stay and can still be used in combination, but a 
> more swift like implementation will be out of the box in Swift.
>
> *Alternatives considered*
> Regex could be a protocol added to String for matching.
>
> ___
> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 vs Swift 4

[Brandon Knope via swift-evolution]

+1 for clarification

Swift 4 begins August 1st…does this mean Swift 3.* are only for bug fixes and 
anything that has been approved and has not made it into 3.0?

Brandon

> On Jul 25, 2016, at 12:55 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Will there be a door of opportunity to propose for Swift 3.1 rather than 
> Swift 4 after 8/1? I've been sitting on `sequence(first, next, while)`  
> (https://github.com/erica/swift/tree/unfold 
> , 
> https://bugs.swift.org/browse/SR-2065 
> ) because it's additive. I think it 
> will do a lot to ameliorate the ill-will raised by SE-0007 
> .
>  
> 
> Thanks for any guidance.
> 
> -- E
> 
> ___
> 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

[swift-evolution] Swift 3.1 vs Swift 4

[Erica Sadun via swift-evolution]

Will there be a door of opportunity to propose for Swift 3.1 rather than Swift 
4 after 8/1? I've been sitting on `sequence(first, next, while)`  
(https://github.com/erica/swift/tree/unfold, 
https://bugs.swift.org/browse/SR-2065) because it's additive. I think it will 
do a lot to ameliorate the ill-will raised by SE-0007 
.
 

Thanks for any guidance.

-- E

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

Re: [swift-evolution] [Draft] Swift implementation Regex added

[Brandon Knope via swift-evolution]

There has been talk on this list of adding a fully featured RegEx feature. It 
has been pushed back to a later release as the window for Swift 3 is closing

Brandon

> On Jul 25, 2016, at 12:24 PM, Joshua Alvarado via swift-evolution 
>  wrote:
> 
> My first proposal so take it easy on me :) This is a draft so feedback is 
> very welcome and any help. Thank you swiftys.
> 
> *Introduction*
> 
> Swift doesn’t have a native implementation of Regex which is included in many 
> other languages. This proposal is a suggestion to introduce a native Regex 
> type into Swift. 
> 
> *Motivation*
> Working with NSRegularExpression is not very swift like and it is lacking in 
> ease of use. More motivation comes from also comes from one of the goals of 
> swift with Swiftification of imported Objective-C APIs.
> 
> *Proposed solution*
> 
> Add a struct of Regex that can be used with the String type.
> 
> Regex can be initialized with a String pattern of the Regex and have simple 
> properties such as accessing the pattern and toString of the pattern.
> 
> String to be extended for Regex support. Functions to add be:
> 
> mutating func replace(regex: Regex, withString: String)
> search(regex: Regex) -> Character.Index
> match(regex: Regex) -> Match? // Match is another new type
> 
> Match is a new type that can give more information on a regex match. Match 
> will have properties such as numberOfMatches, components (the substring of 
> matches in an array), and rangeOfMatch.
> 
> *Impact on existing code*
> NSRegularExpression will stay and can still be used in combination, but a 
> more swift like implementation will be out of the box in Swift.
> 
> *Alternatives considered*
> Regex could be a protocol added to String for matching.
> 
> 
> ___
> 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

Re: [swift-evolution] [swift-evolution-announce] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Scott James Remnant via swift-evolution]

+1

Simple obvious improvement.

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

[swift-evolution] [Draft] Swift implementation Regex added

[Joshua Alvarado via swift-evolution]

My first proposal so take it easy on me :) This is a draft so feedback is very 
welcome and any help. Thank you swiftys.

*Introduction*

Swift doesn’t have a native implementation of Regex which is included in many 
other languages. This proposal is a suggestion to introduce a native Regex type 
into Swift. 

*Motivation*
Working with NSRegularExpression is not very swift like and it is lacking in 
ease of use. More motivation comes from also comes from one of the goals of 
swift with Swiftification of imported Objective-C APIs.

*Proposed solution*

Add a struct of Regex that can be used with the String type.

Regex can be initialized with a String pattern of the Regex and have simple 
properties such as accessing the pattern and toString of the pattern.

String to be extended for Regex support. Functions to add be:

mutating func replace(regex: Regex, withString: String)
search(regex: Regex) -> Character.Index
match(regex: Regex) -> Match? // Match is another new type

Match is a new type that can give more information on a regex match. Match will 
have properties such as numberOfMatches, components (the substring of matches 
in an array), and rangeOfMatch.

*Impact on existing code*
NSRegularExpression will stay and can still be used in combination, but a more 
swift like implementation will be out of the box in Swift.

*Alternatives considered*
Regex could be a protocol added to String for matching.


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

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Gwynne Raskind via swift-evolution]

Agreed as well. This is one of the most contentious topics I’ve seen come 
across Swift so far. While there may be no stopping the avalanche now as far as 
implementing the proposal in general (which I remain against, though many of 
the arguments I’ve heard in favor of it are starting to shake my conviction!), 
it definitely begs more consideration than running up hard against a release 
deadline. Goes double considering the disagreement even among the proposal’s 
supporters about the best semantics.

This being said, for the record, in the current version of the proposal I’d 
prefer option 1 over option 2 (if I’m not allowed to naysay the whole thing). 
Option 2 strikes me as a halfway measure; if we really are going to do this, 
then let’s *do* it.

(And as a general statement, I agree that in that context, "open" should be its 
own access level. I don’t mind having 5 access levels as long as they’re 
clearly defined.)

-- Gwynne Raskind



> On Jul 25, 2016, at 09:43, Davor Jankolija via swift-evolution 
>  wrote:
> 
> I have to agree with what Scott said. At this point it really does seem a bit 
> rusked just to meet the Swift 3 deadline. There will certainly be breaking 
> changes in Swift 4, 5 etc… so although I understand the reasoning to get as 
> many of these into Swift 3, IMO now it’s just trying to rush the proposal at 
> the cost of perhaps more discussion.
> 
> P.S. 
> I’m entirely in favor of the idea and reasoning behind the proposal and feel 
> that a way to prevent all classes being subclassable even if they’re declared 
> public is a worthwhile notion.
> 
> — Davor
> ___
> 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

Re: [swift-evolution] [Proposal] Formalized Ordering, take 2

[Björn Forster via swift-evolution]

Hi Pyry,
thanks for all the work you have put into this!
Could you please explain for someone as simple minded as me why there is
(or has to be) a difference in the implementation of <, <= and >, >=?
Sorry, but I don't get into my head why there is/has to be a preference for
one side. Could you or someone else point out (in the proposal) why there
is a need/what is the reason for this?
I assume that this might not be obvious to some other people on the first
look, too.

Björn

On Mon, Jul 25, 2016 at 1:41 PM, Pyry Jahkola via swift-evolution <
swift-evolution@swift.org> wrote:

> Since we're running short on time, and the previous discussion thread
> diverged, here's my attempt to fix the Comparable protocol.
>
> *Pull request:* https://github.com/apple/swift-evolution/pull/464
>
> TL;DR:
>
> 1. Equatable remains unchanged, while Comparable bloats a bit to support
> several use cases.
> 2. `a <=> b` is well-defined even if either value is NaN. Zero is equal to
> minus zero.
> 3. Types are not strictly required to become totally ordered, even if it's
> strongly recommended.
>
> — — —
>
> I simply can't see how a pure total order version of Comparable would fit
> the standard way floating point values are expected to behave. However, I
> think we can reach a satisfactory conclusion, one that involves no crashing
> in the standard library, which is what I previously suggested.
>
> What I'm trying to fix is so that all operations listed in
> https://dl.dropboxusercontent.com/u/217402/Comparable.pdf abide to laws
> for types without incomparable values, and that types with weaker order can
> still work in *some* well-defined way outside their totally ordered range.
>
> PS. Forgive me Robert, Jaden, and Harlan for not syncing with you, for
> time is tight. I can pull back or revise the proposal if you don't want to
> be involved.
>
> — Pyry
>
>
>
>
> Formalized Ordering
>
>- Proposal: SE-
>
> 
>- Authors: Robert Widmann , Jaden Geller
>, Harlan Haskins
>, Pyry Jahkola
>
>- Status: Awaiting review
>- Review manager: TBD
>
>
> 
> Introduction
>
> This proposal cleans up the semantics of ordering relations in the
> standard library. Our goal is to formalize the total ordering semantics of
> the Comparable protocol and still provide accessible ordering definitions
> for types without total ordering semantics.
>
> 
> Motivation
>
> The standard comparison operators have an intuitive meaning to
> programmers. Swift encourages encoding that in an implementation of
> Comparable that respects the rules of a total order
> . The standard library takes
> advantage of these rules to provide consistent implementations for sorting
> and searching generic collections of Comparable types.
>
> Not all types behave so well in this framework, unfortunately. There are
> cases where the semantics of a total order cannot apply and still maintain
> the traditional definition of “comparison” over these types. Take, for
> example, sorting an array of Float s. Today, Float ‘s instance of
> Comparable follows IEEE-754 and returns false for all comparisons of NaN .
> In order to sort this array, NaN s are considered outside the domain of < ,
> and the order of a “sorted” array containing them is undefined.
>
> In addition, generic algorithms in the Swift Standard Library that make
> use of the current Comparable protocol may have to make twice as many
> comparisons to request the ordering of values with respect to each other
> than they should. Having a central operation to return information about
> the ordering of values once should provide a speedup for these operations.
>
> In the interest of cleaning up the semantics of Comparable types of all
> shapes and sizes and their uses in the Swift Standard Library, this
> proposal is going to re-arrange the requirements of the Comparable and
> Equatable protocols.
>
> Proposed
> solution
> 
> Equatable
>
> The interface of Equatable remains unchanged under this proposal.
> Equatable types should still respect the equivalence laws of *reflexivity*
>  (a == a), *symmetry* (a == b iff b == a), and *transitivity* (if a == b
>  and b == c, 

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 24, 2016, at 11:10 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0132: Rationalizing Sequence end-operation names" begins 
> now and runs through July 26.  Apologies for the short review cycle, but 
> we’re right up against the end of source breaking changes for Swift 3.  The 
> proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>* What is your evaluation of the proposal?

+1 

In the future section :

I strongly dislike every(where:) but I would not be opposed to select(where:) 
but I think filter, map, reduce etc are way better names. 


>* Is the problem being addressed significant enough to warrant a change to 
> Swift?

Yes. There was too much inconsistency.  


>* Does this proposal fit well with the feel and direction of Swift?
Yes
>* If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>* How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?

Quick study. 
> 
> More information about the Swift evolution process is available at
> 
>https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> ___
> 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

[swift-evolution] Getting rid of "..." in variadic functions

[Tino Heth via swift-evolution]

Just wanted to ask about the current status — but then saw that there has been 
a PR already…
It's a pity that there hasn't been the time for a detailed answer, as I still 
think this is one of the best non-trivial proposals so far.

So, I guess you're discouraged by the backfire, but afaics, there haven't been 
many people opposing the idea, but rather a lack of interest.
Maybe it's just not the right time, and I hope there are no serious plans to 
make Swift 3 the last release with breaking changes, so that there will be 
another possibility to discuss the topic when there is less stress.

What's your opinion on simply allowing variadic-syntax at call site wherever an 
array is expected? For me, the only real counter-argument has been that 
"@variadic" is more heavy-weight than three dots, and although I don't agree 
that this is an issue, "nothing" is obviously as lightweight as possible.

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

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Yuta Koshizawa via swift-evolution]

> What is your evaluation of the proposal?

-1

- Certainly `flatten` and `joined` work similarly. I think, however,
the concepts behind them are different. When I use `flatten`, I want
to make nested monads flat. When I use `joined`, I want to concatenate
sequences, mainly `String`s, with a separator. So it is clearer for me
that `flatten` is separated from `joined`.
- `flatMap` means `map` + `flatten`. I feel `flatMap` with `joined`
does not make sense.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?

No. It is not a problem for me as described above.

> Does this proposal fit well with the feel and direction of Swift?

I think proposed `joined` itself fits with the feel of Swift but it is
not the direction of Swift. It can cause problems to unite things
which just look similar ignoring the concepts behind them.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?

Kotlin has `flatten` and `flatMap`. Although Haskell has `join` as
`flatten`, it's `flatMap` is named `>>=` (bind).

I don't know any languages which have a combination of `joined` and
`flatMap`. I feel it is strange.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

A quick reading the thread.

-- Yuta Koshizawa

2016-07-25 15:10 GMT+09:00 Chris Lattner via swift-evolution
:
> Hello Swift community,
>
> The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and runs 
> through July 26.  Apologies for the short review cycle, but we’re right up 
> against the end of source breaking changes for Swift 3.  The proposal is 
> available here:
>
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md
>
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the review 
> manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a 
> change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
> ___
> 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

[swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Davor Jankolija via swift-evolution]

I have to agree with what Scott said. At this point it really does seem a bit 
rusked just to meet the Swift 3 deadline. There will certainly be breaking 
changes in Swift 4, 5 etc… so although I understand the reasoning to get as 
many of these into Swift 3, IMO now it’s just trying to rush the proposal at 
the cost of perhaps more discussion.

P.S. 
I’m entirely in favor of the idea and reasoning behind the proposal and feel 
that a way to prevent all classes being subclassable even if they’re declared 
public is a worthwhile notion.

— Davor
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 24, 2016, at 11:18 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0134: Rename two UTF8-related properties on String" begins 
> now and runs through July 26.  Apologies for the short review cycle, but 
> we’re right up against the end of source breaking changes for Swift 3.  The 
> proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>* What is your evaluation of the proposal?
+1
>* Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes
>* Does this proposal fit well with the feel and direction of Swift?
Yes
>* If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>* How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?
Read thread. 
> 
> More information about the Swift evolution process is available at
> 
>https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> 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

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 24, 2016, at 11:10 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and runs 
> through July 26.  Apologies for the short review cycle, but we’re right up 
> against the end of source breaking changes for Swift 3.  The proposal is 
> available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>* What is your evaluation of the proposal?
-1
>* Is the problem being addressed significant enough to warrant a change to 
> Swift?

I don't thinks so. 

>* Does this proposal fit well with the feel and direction of Swift?

I think we would loose readability. I appreciate having flatten() specially 
when I have to combine it with joined().

This to me would be unfortunate when reading:
[["hey"], ["what"]].joined().joined()


>* If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>* How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?

Participated in thread. 
> 
> More information about the Swift evolution process is available at
> 
>https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> ___
> 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

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

[Ben Rimmington via swift-evolution]

My suggestion for SE-0134 is to use the `utf8CString` name, overloading for 
CSignedChar and CUnsignedChar:




extension String {
- init(cString: UnsafePointer)
- init(cString: UnsafePointer)
- init?(validatingUTF8 cString: UnsafePointer)

+ init(utf8CString: UnsafePointer)
+ init(utf8CString: UnsafePointer)
+ init?(validatingUTF8CString: UnsafePointer)
+ init?(validatingUTF8CString: UnsafePointer)
}

The properties would change to methods, overloaded by return type:




extension String {
- var nulTerminatedUTF8CString: ContiguousArray
- var nulTerminatedUTF8: ContiguousArray

+ func utf8CString() -> ContiguousArray
+ func utf8CString() -> ContiguousArray
}

## NOTES ##

UTF8.CodeUnit is defined as UInt8, and CChar is currently defined as Int8:




/// The C 'char' type.
///
/// This will be the same as either `CSignedChar` (in the common
/// case) or `CUnsignedChar`, depending on the platform.
public typealias CChar = Int8

/// The C 'signed char' type.
public typealias CSignedChar = Int8

/// The C 'unsigned char' type.
public typealias CUnsignedChar = UInt8

There's an abandoned proposal to update CChar:






String.init(cString: UnsafePointer) and nulTerminatedUTF8CString were 
added by SE-0107:







Foundation.NSString uses the `utf8String` name instead:






-- Ben

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

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[David Hart via swift-evolution]

>   * What is your evaluation of the proposal?

+1 This makes total sense. I was going to voice my disagreement until I saw 
that I did not understand what the APIs did because of their names :D The 
renaming makes things much clearer.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes.

>   * Does this proposal fit well with the feel and direction of Swift?

Yes.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Even if some languages have flatten, it does seem like a special case of joined.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick read.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Matthew Johnson via swift-evolution]

> On Jul 25, 2016, at 6:38 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Jul 21, 2016, at 8:33 AM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>>  * What is your evaluation of the proposal?
> 
> Of the designs offered, I prefer #1, because:
> 
> 1. I'm not convinced that there's actually any sense in subclassing a class 
> with no open members; it seems to me that any class intended to be used like 
> this ought to be redesigned to use composition instead of subclassing.
> 
> 2. I also think that you're still effectively depending on implementation 
> details about the instance's lifecycle. Suppose I write a database library 
> which has a Record class. It supports uniquing—that is, a single database 
> record is never represented by two different Record instances. If the last 
> external reference to a Record disappears, does the library hold onto that 
> Record and return it again in response to another query, or does it 
> deallocate it and create a new one? That barely matters *unless* you've 
> subclassed Record.
> 
> 3. Even if there are no overrides, the class and the library around it 
> probably still need to be designed for subclassing. Take the Record example 
> from the previous point: the library will never use your subclass unless 
> there's some hook for telling it which subclass to use. Subclassing isn't 
> going to actually work right if the library doesn't expect any subclasses.
> 
> 4. Even leaving that aside, you may still foisting surprising memory 
> characteristics on the library. For instance, you might hang a large object 
> graph off an instance that's intended to be lightweight, or create a retain 
> cycle the library author took great pains to avoid.
> 
> 5. Finally, this doesn't help with the stated goal of allowing you to make a 
> class `final` in a later version of the library.
> 
> However, I'm actually strongly in favor of Garth Snyder's call for `open` to 
> explicitly become an access level. In design #1, it almost is already; making 
> it official would simplify many aspects of this design.
> 
> (If we do take that road, I would further suggest requiring protocols to be 
> marked `open` instead of `public`. I can easily imagine having closed 
> `public` protocols which are visible but can't be conformed to; this would 
> help with certain typing problems, such as `CKRecordValue`. On the other 
> hand, if `public` were conformable from outside, I can't think of a use for 
> marking a protocol `open`.

I am very much interested in introducing closed protocols.  This seems like an 
interesting and reasonable way to approach it.  I like that it makes the choice 
explicit across module boundaries with no real “default” to speak of - there is 
no additional “burden” (boilerplate) placed on either decision.

> 
> Protocol extension members should continue to be marked `public`. I could 
> imagine `open` being added later, meaning that the member should be added as 
> a protocol requirement so a specialized implementation can be provided; this 
> would avoid the current boilerplate for defaulted protocol members.)
> 
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Yes.
> 
>>  * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes.
> 
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> N/A.
> 
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> I put a little bit less effort into this review than I did into the previous 
> two reviews, the many discussion threads on this topic, or several months of 
> thinking this over and changing my mind about the idea as the plan evolved.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Matthew Johnson via swift-evolution]

> 
>   * What is your evaluation of the proposal?

I was not totally happy with early drafts of this proposal.  The final draft is 
a significant improvement.  I am mostly +1, with a couple of minor critiques.  

I think this proposal pushes a bit too hard on consistency of “first / last” vs 
“prefix / suffix”.  Specifically, I think first(n) and last(n) are 
significantly more clear than prefix(n) and suffix(n) (and removingFirst(n) / 
removingLast(n) instead of removingPrefix(n) / removingSuffix(n).  I think the 
former are immediately clear.  The latter, while consistent in terms of 
matching semantics with a naming convention suffer in terms of clarity at the 
call site.  I do not think it is immediately clear that the parameter specifies 
the *length* of the prefix or suffix.  removingPrefix(ofLength: n) would solve 
the clarity issue at the expense of verbosity.  I would prefer we just keep 
first / last in these cases.

Another comment is that you have generally moved index based methods to 
subscripts rather than named methods.  Why didn’t you take this all the way and 
change `replaceSubrange` to be a subscript setter?


>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes, the new names have more consistency.

>   * Does this proposal fit well with the feel and direction of Swift?

Yes.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I don’t believed I have used any languages that emphasize consistent naming and 
API guidelines as strongly as Swift.  This is a good direction.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

A relatively quick read.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> ___
> 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

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Pyry Jahkola via swift-evolution]

> On 25 Jul 2016, at 09:10, Chris Lattner via swift-evolution 
>  wrote:
> 
> The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and runs 
> through July 26.  Apologies for the short review cycle, but we’re right up 
> against the end of source breaking changes for Swift 3.  The proposal is 
> available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md
> 
>   * What is your evaluation of the proposal?

+1, this makes sense. The functions are very closely related, and while we have 
"flatten" in `flatMap`, is isn't unprecedented to call the joining operation 
`join` instead of `flatten`.

Flatten also somewhat suffers from the expectation that it would flatten 
arbitrary depths of nestings down to just one. (That would be absurd in Swift's 
type system, but is precedented in e.g. Clojure 
.) 
The word "join" instead sounds like a more 1-dimensional operation, and thus 
decreases the minor surprise factor.

It's also nice that `.joined(separator:)` can be simplified down to `.joined()` 
when the default separator is wanted. And I'd say the empty collection is an 
obvious choice for default in here.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes, it makes the function easier to find.

>   * Does this proposal fit well with the feel and direction of Swift?

Yes.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Yes. E.g. Haskell calls it `join` 
.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick reading.

— Pyry

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

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

[David Rönnqvist via swift-evolution]

+1. A small but good improvement.

It makes even more sense since the documentation for these calls it 
“null-terminated” (was called “nul-terminated” in the 2.2 documentation).

- David

> On 25 Jul 2016, at 08:18, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0134: Rename two UTF8-related properties on String" begins 
> now and runs through July 26.  Apologies for the short review cycle, but 
> we’re right up against the end of source breaking changes for Swift 3.  The 
> proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> 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

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Rod Brown via swift-evolution]

   * What is your evaluation of the proposal?
+1. It's consistent with the new language guidelines, and though 'flatten' 
seemed a term-of-art there are multiple arguments here that would clear up 
things, like the string combination.

   * Is the problem being addressed significant enough to warrant a change to 
Swift?
Yes.

   * Does this proposal fit well with the feel and direction of Swift?
Yes. It is consistent with the direction of things, and streamlines APIs.

   * If you have used other languages or libraries with a similar feature, how 
do you feel that this proposal compares to those?
N/A

   * How much effort did you put into your review? A glance, a quick reading, 
or an in-depth study?
A quick reading.

> On 25 Jul. 2016, at 4:10 pm, Chris Lattner via swift-evolution 
>  wrote:
> 
>* What is your evaluation of the proposal?
>* Is the problem being addressed significant enough to warrant a change to 
> Swift?
>* Does this proposal fit well with the feel and direction of Swift?
>* If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>* How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[David Rönnqvist via swift-evolution]

>   * What is your evaluation of the proposal?

+1 
In its third revision I like this proposal more. I think “open” is a good 
keyword for both members and classes. 
I’m in favor of the first design for open classes. That said, I also 
acknowledge that subclassing without overriding anything doesn’t suffer from 
the problems that overriding members do. Additionally, even for a sealed class, 
new methods could be added thought extensions. This means the the benefits of 
the first design over the second one are fairly small. However, in my 
experience (which might be wrong), designing a class for subclassing without 
any overridable methods is quite uncommon, and in the first design can easily 
be resolved by making it open. I see it as a benefit of the first design that 
it allows for this distinction (a class can be make public without being 
subclassable).

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes. 

>   * Does this proposal fit well with the feel and direction of Swift?

Yes. 

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I’ve encountered virtual functions in C++ but only to a small extent.

I like this solution better because it makes the distinction between internally 
and externally overridable (and gets out of the way for internal overrides).

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Read the proposal and much of the discussion (but not all, there’s been so much 
)

- David

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

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Boris Wang via swift-evolution]

And try to use overloading more:

exclude(index: Int)
exclude(part: Range)
exclude({closure})

Boris Wang 于2016年7月25日 周一16:09写道：

> My suggest:
>
> * Change removing to exclude. For exam, S.excludeFirst
> * Keep shorthand for first and last element
> * Change pop to removeXXXCheck. For exam, C.popFirst =>C.removeFirstCheck
>
> Charlie Monroe via swift-evolution 于2016年7月25日
> 周一15:45写道：
>
>>
>> > On Jul 25, 2016, at 8:10 AM, Chris Lattner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > Hello Swift community,
>> >
>> > The review of "SE-0132: Rationalizing Sequence end-operation names"
>> begins now and runs through July 26.  Apologies for the short review cycle,
>> but we’re right up against the end of source breaking changes for Swift 3.
>> The proposal is available here:
>> >
>> >
>> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
>> >
>> > Reviews are an important part of the Swift evolution process. All
>> reviews should be sent to the swift-evolution mailing list at
>> >
>> >   https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
>> > or, if you would like to keep your feedback private, directly to the
>> review manager.
>> >
>> > What goes into a review?
>> >
>> > The goal of the review process is to improve the proposal under review
>> through constructive criticism and contribute to the direction of Swift.
>> When writing your review, here are some questions you might want to answer
>> in your review:
>> >
>> >   * What is your evaluation of the proposal?
>>
>> The updated API is more consistent and seems the right step to take.
>>
>> >   * Is the problem being addressed significant enough to warrant a
>> change to Swift?
>>
>> Yes.
>>
>> >   * Does this proposal fit well with the feel and direction of
>> Swift?
>>
>> Yes.
>>
>> >   * If you have used other languages or libraries with a similar
>> feature, how do you feel that this proposal compares to those?
>> >   * How much effort did you put into your review? A glance, a quick
>> reading, or an in-depth study?
>>
>> Read the proposal and skimmed through the discussion.
>>
>> >
>> > More information about the Swift evolution process is available at
>> >
>> >   https://github.com/apple/swift-evolution/blob/master/process.md
>> >
>> > Thank you,
>> >
>> > -Chris Lattner
>> > Review Manager
>> > ___
>> > 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
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Jacob Bandes-Storch via swift-evolution]

I wasn't explicit about that in the proposal, but I was intending that
these should be renamed too. There's a minor snag: JoinedSequence already
exists. I haven't taken a close look at both implementations yet, but it's
possible we could just combine them.

On Mon, Jul 25, 2016 at 12:46 AM, Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

> Shouldn't the proposal also mention renaming FlattenCollection,
> FlattenBidirectionalCollection and FlattenSequence to
> Joined*(Collection|Sequence)? Or are these going to keep their name?
>
> > On Jul 25, 2016, at 8:10 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Hello Swift community,
> >
> > The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and
> runs through July 26.  Apologies for the short review cycle, but we’re
> right up against the end of source breaking changes for Swift 3.  The
> proposal is available here:
> >
> >
> https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md
> >
> > Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
> >
> >   https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > or, if you would like to keep your feedback private, directly to the
> review manager.
> >
> > What goes into a review?
> >
> > The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
> >
> >   * What is your evaluation of the proposal?
> >   * Is the problem being addressed significant enough to warrant a
> change to Swift?
> >   * Does this proposal fit well with the feel and direction of Swift?
> >   * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> >   * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
> >
> > More information about the Swift evolution process is available at
> >
> >   https://github.com/apple/swift-evolution/blob/master/process.md
> >
> > Thank you,
> >
> > -Chris Lattner
> > Review Manager
> > ___
> > 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Boris Wang via swift-evolution]

My suggest:

* Change removing to exclude. For exam, S.excludeFirst
* Keep shorthand for first and last element
* Change pop to removeXXXCheck. For exam, C.popFirst =>C.removeFirstCheck

Charlie Monroe via swift-evolution 于2016年7月25日
周一15:45写道：

>
> > On Jul 25, 2016, at 8:10 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Hello Swift community,
> >
> > The review of "SE-0132: Rationalizing Sequence end-operation names"
> begins now and runs through July 26.  Apologies for the short review cycle,
> but we’re right up against the end of source breaking changes for Swift 3.
> The proposal is available here:
> >
> >
> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
> >
> > Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
> >
> >   https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > or, if you would like to keep your feedback private, directly to the
> review manager.
> >
> > What goes into a review?
> >
> > The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
> >
> >   * What is your evaluation of the proposal?
>
> The updated API is more consistent and seems the right step to take.
>
> >   * Is the problem being addressed significant enough to warrant a
> change to Swift?
>
> Yes.
>
> >   * Does this proposal fit well with the feel and direction of Swift?
>
> Yes.
>
> >   * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> >   * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> Read the proposal and skimmed through the discussion.
>
> >
> > More information about the Swift evolution process is available at
> >
> >   https://github.com/apple/swift-evolution/blob/master/process.md
> >
> > Thank you,
> >
> > -Chris Lattner
> > Review Manager
> > ___
> > 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Jacob Bandes-Storch via swift-evolution]

>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
>
> * What is your evaluation of the proposal?
>

+1 on drop{First,Last}() → removing{First,Last}().
+1 on drop{First,Last}(_:) → removing{Prefix,Suffix}(_:).
+1 on drop(while:) → removingPrefix(while:).
+1 on starts(with:[by:]) → hasPrefix(_:[by:]).
+1 on index({of:,where:}) → firstIndex({of:,where:}).
+1 on prefix and postfix versions of ..< and the prefix version of the ...
operator. For a while I thought I might prefer labeled subscripts, but
after writing them out I agree the operators are better.

The rest is a stream of consciousness:.

I don't think postfix ... is necessary. When does one ever combine a
ClosedRange with endIndex?

I don't agree that "drop" sounds particularly scary, but I'm fine with
"removing" as an alternative to "drop"/"dropping". Scatologists will be
disappointed, I'm sure.

I'd forgotten about prefix(while:), which apparently isn't implemented yet.
I think I'd prefer if this were named prefix(where:) instead.

I'm struggling a little with the distinction between length-based and
index-based methods/subscripts. Are "prefix(_ length: Int)" and
"prefix(upTo end: Index)" really different enough that one of them should
be a subscript and the other a method? The same question applies to
prefix(through:) and suffix(from:). I kinda wish these could all be methods
or all subscripts.

I have to say I don't fully understand the need for (or benefits of)
RangeExpression and the relative(to:) API (perhaps because I don't have
much experience using the most recent collection/index/range APIs). Since
the conforming type's Bound is already required to be the collection's
Index, it seems pointless to have an API to access this as a Range...there
should just be Collection subscript methods which accept the conforming
types. I suppose it's nice to get all these for free by implementing just
one subscript function (excepting the current lack of generic
subscripts)...but is it even possible to express every RangeExpression as a
Range? What about a ClosedRange whose upperBound is Int.max? (Wasn't
that the whole point of introducing ClosedRange in the first place?)

Random question: why do we have both removeFirst and popFirst?  ...on
further reading I see you covered this in Future Directions. I'd be happy
to discuss merging these. I wonder if it's important to do for Swift 3
(although we're basically out of time)?

The name IncompleteRange makes sense, but could be a little misleading if
..<(Bound?,Bound?) is called with two non-nil operands: based on my
reading, it sounds like the returned IncompleteRange wouldn't actually
change when you call completed(by:) (since it's not actually incomplete).
However, I can't come up with any better naming suggestions.


> * Is the problem being addressed significant enough to warrant a
> change to Swift?
>

Yes.


> * Does this proposal fit well with the feel and direction of Swift?
>

Mostly. Not sure there's enough consistency between
subsequence-length-based and index-based APIs, namely that prefix(upTo:)
becomes a subscript but prefix(_:) doesn't.

* If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>

I've used Python and Mathematica, which both have functionality similar to
"incomplete range subscripts":

Python: http://stackoverflow.com/a/509295/23649
Mathematica: https://reference.wolfram.com/language/ref/Span.html

Based on my experience there, this is a good first (second?) step for Swift
to take.

Both Mathematica and Python support a *stride* as well as start/end indices
in their subscripting syntax. It would be nice for Swift to support
something like this, but some versions of that would require custom ternary
operators (or weird intermediate types to fake a custom ternary operator).
We might also consider labelled multi-argument subscripts like
"collection[start..) support
multi-dimensional arrays:  matrix[[3;;4, -5;;]] would be the submatrix
containing the last 5 entries in rows 3 and 4 of the original matrix.)


> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>

A mostly-thorough reading of the proposal.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Daniel Duan via swift-evolution]

* What is your evaluation of the proposal?
+1 for option 1.

* Is the problem being addressed significant enough to warrant a change to 
Swift?
Yes, accidental or thoughtless exposure of non-final classes from 3rd party 
libraries are something worth addressing.

* Does this proposal fit well with the feel and direction of Swift?
Yes. Having the privilege of working on a mature, pure Swift app, I can say 
that both code reuse and polymorphism can and should be better achieved without 
class inheritance (or classes at all, most of the time).

As alluded in the motivation section of the proposal, a third party Swift 
library down the line would mostly provide struct/enum types for users. Classes 
may be included to provide objects with reference semantics, these would be 
marked final by a responsible author today. And then, we have rare cases where 
inheritance is intended to provide customization and code reuse. The change in 
this proposal is sensible both for responsible library authors (who would stop 
worrying about missing `final`s), and for sloppy authors (who now are forced 
think about the interface of the library more). Ultimately, we'll get better 
libraries (to an extent) and happier users.

That's a direction I'd like Swift to go.

* If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
No.

* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
Read all 3 versions and all discussions on this list. Also followed a lot of 
related threads on Twitter. Had quite a few discussions of it with ppl smarter 
than me IRL.

Sent from my iPad

> On Jul 21, 2016, at 8:33 AM, Chris Lattner  wrote:
> 
>* What is your evaluation of the proposal?
>* Is the problem being addressed significant enough to warrant a change to 
> Swift?
>* Does this proposal fit well with the feel and direction of Swift?
>* If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>* How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

[Dave Abrahams via swift-evolution]

on Sun Jul 24 2016, Brent Royal-Gordon  wrote:

>> On Jul 24, 2016, at 9:06 PM, Pyry Jahkola via swift-evolution
>  wrote:
>> 
>> Another possible choice would be to return .descending whenever
>> either of the comparands were NaN, while also making <, >, <=, and
>> >= return false in such cases. Then we wouldn't see
>> preconditionFailures but instead produced bogus results from sort,
>> partition etc. That's the tradeoff Haskell has chosen for its
>> `compare` function over Double, FWIW.
>
> That's essentially what we currently have. I think we'd like to fix
> it.
>
> Honestly, I think the most natural result is that calls like `sort()`
> and `max()` ignore NaNs—for instance, an Array might have
> fewer elements if you sort it. 

That would be deeply surprising and would create a programming model
that was almost impossible to work with.  I could not support a result
like that.

> That seems to be the behavior implied by
> `FloatingPoint.maximum/minimum(_:_:)`. 

That elements are dropped from a collection when it is sorted?  How do
you figure?

> However, it is still possible to access and use the total ordering if
> you need it.
>
> This sort of suggests we should have two levels of comparisons:
>
> * `===` and `<===>` are total.
>
> * `==` and `<=>` may not work on, or may conflate, some values.

This has really gone off the rails, guys.  There are no generic
algorithms that rely on an under-all-circumstances-substitutability
property, so we shouldn't encode it into a protocol.

Also, think about what “under all circumstances” really means: it means
that there are no implementation details, because it is possible for
code with access rights to inspect them.  It means that no class
instances can ever be substitutable for other instances, because of
ObjectIdentity.  It becomes absurd really quickly.

> How to actually accomplish this is a more difficult question. The
> simplest solution might be something like:
>
>   protocol Equatable {
>   static func === (…) -> Bool
>   static func == (…) -> Bool
>   }
>   extension Equatable {
>   static func == (…) -> Bool {
>   return lhs === rhs
>   }
>   }
>
>   protocol Comparable: Equatable {
>   /// Total ordering which works on and distinguishes
> between all values of the type.
>   static func <===> (…) -> Ordering
>
>   /// "Friendly" ordering which may conflate or not work
> on some values of the type.
>   /// 
>   /// - Precondition: Neither `lhs` nor `rhs` returns
> `true` from `isAberration`.
>   static func <=> (…) -> Ordering
>
>   /// If true, this instance should be ignored when
> using the <=> operator.
>   var isAberration: Bool { get }
>   }
>   extension Comparable {
>   static func === (…) -> Bool {
>   return (lhs <===> rhs) == .same
>   }
>   static func == (…) -> Bool {
>   return (lhs <=> rhs) == .same
>   }
>   static func <=> (…) -> Ordering {
>   return lhs <===> rhs
>   }
>   var isAberration: Bool {
>   return true
>   }
>   }
>
> However, this means that sorting requires two functions, not one (or
> that, when using a custom sorting function, you must separately
> pre-filter the aberrations from your data set). An alternative would
> be to introduce a PartialOrdering type:
>
>   enum PartialOrdering {
>   case ordered (Ordering)
>   case leftUnordered
>   case bothUnordered
>   case rightUnordered
>   }
>   // As above, except...
>   protocol Comparable: Equatable {
>   ...
>
>   /// "Friendly" ordering which may not work on some
> values of the type.
>   /// 
>   /// - Precondition: Neither `lhs` nor `rhs` returns
> `true` from `isAberration`.
>   static func <=> (…) -> PartialOrdering
>   }
>
> This wouldn't necessarily handle the `-0.0 == +0.0` case well,
> though. That *could* be handled with extra cases meaning "equal but
> ordered", but this is looking messier and messier.

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

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Charlie Monroe via swift-evolution]

Shouldn't the proposal also mention renaming FlattenCollection, 
FlattenBidirectionalCollection and FlattenSequence to 
Joined*(Collection|Sequence)? Or are these going to keep their name?

> On Jul 25, 2016, at 8:10 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and runs 
> through July 26.  Apologies for the short review cycle, but we’re right up 
> against the end of source breaking changes for Swift 3.  The proposal is 
> available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> ___
> 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

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Charlie Monroe via swift-evolution]

> On Jul 25, 2016, at 8:10 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0132: Rationalizing Sequence end-operation names" begins 
> now and runs through July 26.  Apologies for the short review cycle, but 
> we’re right up against the end of source breaking changes for Swift 3.  The 
> proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?

The updated API is more consistent and seems the right step to take.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes.

>   * Does this proposal fit well with the feel and direction of Swift?

Yes.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Read the proposal and skimmed through the discussion.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> ___
> 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

Re: [swift-evolution] [Pitch] Rename `index(of:)`and `index(where:)` to `firstIndex(of:)` and `firstIndex(where:)` respectively

[Dave Abrahams via swift-evolution]

on Sun Jul 24 2016, Brent Royal-Gordon  wrote:

>> On Jul 24, 2016, at 10:39 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>>> On Jul 24, 2016, at 2:41 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> Jose Cheyo Jimenez via swift-evolution  writes:
>
>>> 
 
 Is your proposal going to make the swift3 window? 
>>> 
>>> It should.  I'm planning on merging it and launching the review 
>>> if Chris L doesn't beat me to it (which I hope he will ;-)).
>> 
>> I’m still waiting to be told that it is ready.  You guys appear to still be 
>> iterating in the PR.
>> 
>> -Chris
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> I consider it ready.

Me 2

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

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Dmitriy Y. Volkov via swift-evolution]

-1 to add this proposal for Swift 3.0

I’ve been reading mailing list for the last two reviews of this proposal and 
discussion turned from “We shouldn’t add this at all” - which was kind of 
justified  to “How actually will it interops with other swift features” - which 
still has a lot of questions of how exactly this modifiers will play out with 
other accessibility modifiers, and it seems like there is still no single 
answer. As Scott said, I have the same feeling that this proposal is being 
rushed to be accepted before the changed to Swift 3 are locked, and this won’t 
do any good to its semantics.

Perhaps, core team can write out their thoughts on how this addition to 
language will fit with all the current class modifiers (final, dynamic etc)? I 
think it might be accepted during the Swift 3.x phase, when all the edge cases 
will be thought out, made non-default and then enabled to its full force in 
Swift 4.0?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Xiaodi Wu via swift-evolution]

On Mon, Jul 25, 2016 at 1:10 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0132: Rationalizing Sequence end-operation names" begins
> now and runs through July 26.  Apologies for the short review cycle, but
> we’re right up against the end of source breaking changes for Swift 3.  The
> proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
> * What is your evaluation of the proposal?
>

The end product is really quite beautiful. This proposal very much succeeds
at rationalizing all names without introducing terminology that's
unprecedented. I very much appreciate that properties or functions named
`first` now always return one or zero elements and that ranges are always
indicated with range operators. The only quibble is that `hasPrefix(_:by:)`
might be more appropriately `hasPrefix(_:comparingBy:)`, as the standalone
preposition doesn't quite make sense IMO.


> * Is the problem being addressed significant enough to warrant a
> change to Swift?
>

Yes.


> * Does this proposal fit well with the feel and direction of Swift?
>

Yes, very much so.


> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>

This proposal rationalizes Swift-specific names, so not sure how to compare
to other languages.


> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>

A quick reading of this version; I followed the original discussion and
thought about it more in-depth then.


> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
> ___
> 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

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Xiaodi Wu via swift-evolution]

On Mon, Jul 25, 2016 at 1:10 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and
> runs through July 26.  Apologies for the short review cycle, but we’re
> right up against the end of source breaking changes for Swift 3.  The
> proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
> * What is your evaluation of the proposal?
>

+1. A sensible simplification of the public API. Moreover, `flatten()` was
apparently treated as a term-of-art and doesn't observe the noun/verb
guidelines for non-mutating vs. mutating methods. So `joined()` is the
superior choice.


> * Is the problem being addressed significant enough to warrant a
> change to Swift?
>

Sure; unnecessary inconsistency in the stdlib APIs are best reduced or
eliminated where possible.


> * Does this proposal fit well with the feel and direction of Swift?
>

Yes.


> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>

It reminds me of Python `join`, although in that language the default
separator for joining strings is " ". Arguably, a more convenient default
for Western languages, but a more universally appropriate default would
indeed be "" as proposed.


> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>

A quick reading, but followed the original discussion.


>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
> ___
> 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

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

[Xiaodi Wu via swift-evolution]

On Mon, Jul 25, 2016 at 1:12 AM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > On Jul 24, 2016, at 9:06 PM, Pyry Jahkola via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Another possible choice would be to return .descending whenever either
> of the comparands were NaN, while also making <, >, <=, and >= return false
> in such cases. Then we wouldn't see preconditionFailures but instead
> produced bogus results from sort, partition etc. That's the tradeoff
> Haskell has chosen for its `compare` function over Double, FWIW.
>
> That's essentially what we currently have. I think we'd like to fix it.
>
> Honestly, I think the most natural result is that calls like `sort()` and
> `max()` ignore NaNs—for instance, an Array might have fewer
> elements if you sort it. That seems to be the behavior implied by
> `FloatingPoint.maximum/minimum(_:_:)`. However, it is still possible to
> access and use the total ordering if you need it.
>
> This sort of suggests we should have two levels of comparisons:
>
> * `===` and `<===>` are total.
>
> * `==` and `<=>` may not work on, or may conflate, some values.
>

Agreed very much. Although, any "friendly" `<=>` can be derived from what
you call `<===>` and `==`.

I've been playing with a variation where I have a "friendly" equivalence
relation `==?` (returns `Bool?` so that it's `nil` when there's a argument
that doesn't make sense to compare) and a finer equivalence relation `===`
as protocol requirements on Equatable, with a generic `==` defined as `{
return (lhs ==? rhs) ?? (lhs === rhs) }`. In that model, traditional
comparison operators can be synthesized from a total ordering (which you
call `<===>` and the original proposal calls `<=>`) by first consulting the
value of the friendly `==?` to determine if two operands are the same.

How to actually accomplish this is a more difficult question. The simplest
> solution might be something like:
>
> protocol Equatable {
> static func === (…) -> Bool
> static func == (…) -> Bool
> }
> extension Equatable {
> static func == (…) -> Bool {
> return lhs === rhs
> }
> }
>
> protocol Comparable: Equatable {
> /// Total ordering which works on and distinguishes
> between all values of the type.
> static func <===> (…) -> Ordering
>
> /// "Friendly" ordering which may conflate or not work on
> some values of the type.
> ///
> /// - Precondition: Neither `lhs` nor `rhs` returns `true`
> from `isAberration`.
> static func <=> (…) -> Ordering
>
> /// If true, this instance should be ignored when using
> the <=> operator.
> var isAberration: Bool { get }
> }
> extension Comparable {
> static func === (…) -> Bool {
> return (lhs <===> rhs) == .same
> }
> static func == (…) -> Bool {
> return (lhs <=> rhs) == .same
> }
> static func <=> (…) -> Ordering {
> return lhs <===> rhs
> }
> var isAberration: Bool {
> return true
> }
> }
>
> However, this means that sorting requires two functions, not one (or that,
> when using a custom sorting function, you must separately pre-filter the
> aberrations from your data set). An alternative would be to introduce a
> PartialOrdering type:
>
>
> enum PartialOrdering {
> case ordered (Ordering)
> case leftUnordered
> case bothUnordered
> case rightUnordered
> }
> // As above, except...
> protocol Comparable: Equatable {
> ...
>
> /// "Friendly" ordering which may not work on some values
> of the type.
> ///
> /// - Precondition: Neither `lhs` nor `rhs` returns `true`
> from `isAberration`.
> static func <=> (…) -> PartialOrdering
> }
>
> This wouldn't necessarily handle the `-0.0 == +0.0` case well, though.
> That *could* be handled with extra cases meaning "equal but ordered", but
> this is looking messier and messier.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> 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

[swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0134: Rename two UTF8-related properties on String" begins 
now and runs through July 26.  Apologies for the short review cycle, but we’re 
right up against the end of source breaking changes for Swift 3.  The proposal 
is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager


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

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

[Brent Royal-Gordon via swift-evolution]

> On Jul 24, 2016, at 9:06 PM, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> Another possible choice would be to return .descending whenever either of the 
> comparands were NaN, while also making <, >, <=, and >= return false in such 
> cases. Then we wouldn't see preconditionFailures but instead produced bogus 
> results from sort, partition etc. That's the tradeoff Haskell has chosen for 
> its `compare` function over Double, FWIW.

That's essentially what we currently have. I think we'd like to fix it.

Honestly, I think the most natural result is that calls like `sort()` and 
`max()` ignore NaNs—for instance, an Array might have fewer elements if 
you sort it. That seems to be the behavior implied by 
`FloatingPoint.maximum/minimum(_:_:)`. However, it is still possible to access 
and use the total ordering if you need it.

This sort of suggests we should have two levels of comparisons:

* `===` and `<===>` are total.

* `==` and `<=>` may not work on, or may conflate, some values.

How to actually accomplish this is a more difficult question. The simplest 
solution might be something like:

protocol Equatable {
static func === (…) -> Bool
static func == (…) -> Bool
}
extension Equatable {
static func == (…) -> Bool {
return lhs === rhs
}
}

protocol Comparable: Equatable {
/// Total ordering which works on and distinguishes between all 
values of the type.
static func <===> (…) -> Ordering

/// "Friendly" ordering which may conflate or not work on some 
values of the type.
/// 
/// - Precondition: Neither `lhs` nor `rhs` returns `true` from 
`isAberration`.
static func <=> (…) -> Ordering

/// If true, this instance should be ignored when using the <=> 
operator.
var isAberration: Bool { get }
}
extension Comparable {
static func === (…) -> Bool {
return (lhs <===> rhs) == .same
}
static func == (…) -> Bool {
return (lhs <=> rhs) == .same
}
static func <=> (…) -> Ordering {
return lhs <===> rhs
}
var isAberration: Bool {
return true
}
}

However, this means that sorting requires two functions, not one (or that, when 
using a custom sorting function, you must separately pre-filter the aberrations 
from your data set). An alternative would be to introduce a PartialOrdering 
type:


enum PartialOrdering {
case ordered (Ordering)
case leftUnordered
case bothUnordered
case rightUnordered
}
// As above, except...
protocol Comparable: Equatable {
...

/// "Friendly" ordering which may not work on some values of 
the type.
/// 
/// - Precondition: Neither `lhs` nor `rhs` returns `true` from 
`isAberration`.
static func <=> (…) -> PartialOrdering
}

This wouldn't necessarily handle the `-0.0 == +0.0` case well, though. That 
*could* be handled with extra cases meaning "equal but ordered", but this is 
looking messier and messier.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Rename `index(of:)`and `index(where:)` to `firstIndex(of:)` and `firstIndex(where:)` respectively

[Brent Royal-Gordon via swift-evolution]

> On Jul 24, 2016, at 10:39 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Jul 24, 2016, at 2:41 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> Jose Cheyo Jimenez via swift-evolution  writes:
>> 
>>> 
>>> Is your proposal going to make the swift3 window? 
>> 
>> It should.  I'm planning on merging it and launching the review 
>> if Chris L doesn't beat me to it (which I hope he will ;-)).
> 
> I’m still waiting to be told that it is ready.  You guys appear to still be 
> iterating in the PR.
> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I consider it ready.

-- 
Brent Royal-Gordon
Architechies

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

[swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0132: Rationalizing Sequence end-operation names" begins now 
and runs through July 26.  Apologies for the short review cycle, but we’re 
right up against the end of source breaking changes for Swift 3.  The proposal 
is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and runs 
through July 26.  Apologies for the short review cycle, but we’re right up 
against the end of source breaking changes for Swift 3.  The proposal is 
available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution