Re: [swift-evolution] Learning from SE-0025, a breeding group for Swift proposals

[Ted Kremenek via swift-evolution]

> On Apr 18, 2017, at 12:00 AM, David Hart via swift-evolution 
> > wrote:
> 
> Here's my rough idea:
> The Swift compiler gains a new off-by-default `next` version triggerable with 
> the `-swift-version next` flag.
> All controversial proposals start their implementation in that version.
> Once one of the poposals feels stable enough, it is brought into an official 
> version.
> Developers would be encouraged to try the `next` features while being warned 
> that source compatibility on that version will *not* be garanteed.
> As the vast majority of the Swift user base are still Apple platform 
> developers, I think it would be important for the success of that strategy 
> that the applications compiled with the `next` flag be accepted on the Apple 
> stores or it will reduce the group of developers ready to play in this 
> "breeding-group".

Hi David,

I think this is a well-intentioned suggestion, but I see several problems with 
this approach.

The first problem is one of expectations.  Developers invest in using features 
because they want to write code to get their work done.  Once someone starts 
shipping something that depends on a feature they get very grumpy when it gets 
taken away.  It doesn’t really matter if the feature is “official” or not.  
Once enough people invest in using a feature it becomes “unofficially” part of 
the language.  IMO, that doesn’t promote a model where changes to the language 
are well-considered.

The second problem is that within the compiler there is still vestigial 
remnants of earlier days in Swift when we were doing a lot of experimentation.  
Before Swift 1 was released we toyed around quite a bit with the syntax, the 
type checker, pretty much everything.  We’d have a design meeting and then 
immediately someone would go implement something in the compiler.  During those 
days such rapid experimentation was helpful to see how ideas would work out and 
to get a feel for the language we were crafting.  But as time has gone by we’ve 
repeatedly found ourselves removing cruft from the compiler’s implementation 
and fixing bugs from technical debt of incompletely implemented features or 
features that didn’t work well together.  Features added for the purpose of 
experimentation are almost always incomplete — it’s the very nature of 
experimentation.  It is also very easy to convince yourself that a new language 
feature “works” when you try it out on a few examples.

No design process is going to be perfect.  We made a lot design decisions 
before Swift was publicly announced that were made based on our intuition and 
experiences, but really those decisions weren’t evaluated until people started 
writing a lot of Swift code.  We then have gone back — several times — and have 
revised core design decisions in the language based on learning from real-world 
usage of Swift.  With the access control saga I think we saw another instance 
of that story: a lot of discussion happened in the Swift 3 timeframe, but some 
important factors/implications of the design being discussed that are now 
obvious in hindsight just weren’t apparent when the discussions were happening. 
 I believe some number of these sagas are inevitable, and hopefully we learn 
from them to better inform our design decisions in the future.

I know the idea behind having a “-swift-version next” is to allow people to 
invest in experimental ideas to provide real feedback, but I don’t think this 
encourages good language design and many developers would be fearful of using 
such experimental features.  Those that fall in love with an experimental 
feature would likely fervently defend their existence, even if they end up 
being a bad idea.  It’s also not clear by what criteria we would take 
experimental features into the compiler in the first place, and adding more 
cruft into the compiler could be very detrimental to its implementation quality.

As Chris said, Xcode betas really are a good time for people to provide 
feedback about features.  With Swift 3 some of that feedback was delayed 
because of the upheaval caused by the Grand API Renaming and the migration work 
projects needed to do to go from Swift 2 to Swift 3.  Going forward the intent 
is that the evolution of Swift provides a much smoother, continuous experience 
for users, and allows them to try out new features of the language more easily 
and thus possible provide feedback sooner.

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

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[David Hart via swift-evolution]

> On 21 Apr 2017, at 01:31, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>>> On Apr 20, 2017, at 3:39 PM, John McCall  wrote:
>>> 
>>> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
 On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor  wrote:
 
 
>> On Apr 20, 2017, at 11:33 AM, Jordan Rose  wrote:
>> 
>> 
>> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> This makes the private/fileprivate distinction meaningful for 
>> extensions. I think also bans the use of "private" at global scope for 
>> non-nominal types or extensions thereof.  A clarifying update to the 
>> proposal is in order, so developers can better understand the semantics. 
> 
> Wait, hang on, then people have to write 'fileprivate' instead of 
> 'private' for top-level typealiases (and functions?). 
 
 That seems like the correct behavior; private is about members with 
 SE-0169. What do you think?
>>> 
>>> ...that seems suboptimal, given that the goal has been to make it possible 
>>> for people to use `private` more and not less frequently. IMO, there's no 
>>> need for `private typealias` at the global level to be prohibited.
>> 
>> Yeah, I see no reason for this to change the behavior of private extensions 
>> to be more restrictive than before.
> 
> So you’re okay with:
> 
>   private extension X {
> func foo() { }
>   }
> 
> being equivalent to
> 
>   extension X {
> fileprivate func foo() { }
>   }
> 
> rather than
> 
>   extension X {
> private func foo() { }
>   }
> 
> ?
> 
> That seems unintuitive at best.

It's more than unintuitive, it goes against the reasons we fought for having a 
more useful private. I want to use the pattern where I declare an extension as 
private to set all functions inside it as private to create a "private zone".

>   - Doug
> 
> 
> ___
> 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-0172: One-sided Ranges

[Brent Royal-Gordon via swift-evolution]

I would add that I expect variadic generics to be used less often than 
one-sided ranges, and also to be a more complex and advanced feature. Both of 
these suggest that one-sided ranges deserve the simpler, friendlier syntax. 

-- 
Brent Royal-Gordon
Sent from my iPhone

> On Apr 20, 2017, at 4:38 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Apr 20, 2017, at 6:36 AM, Matt Whiteside  wrote:
>> 
>> I do like this proposed one-sided range syntax, but a while back it was 
>> pointed out that it might conflict with a candidate syntax for variadic 
>> generics.  Has anything changed there?
> 
> It does conflict with the straw man syntax described in the generics 
> manifesto:
> 
>   
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#variadic-generics
> 
> but variadic generics are a long way off and the syntax is totally up in the 
> air.
> 
>   - Doug
> 
>> -Matt
>> 
>>> On Apr 17, 2017, at 21:40, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of SE-0172 "One-sided Ranges" begins now and runs through April 
>>> 23, 2017. The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.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. When replying, please try to keep the proposal link at the top of 
>>> the message:
>>> 
>>> Proposal link:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md
>>> Reply text
>>> Other replies
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and, eventually, determine 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,
>>> 
>>> -Doug
>>> 
>>> 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] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[John McCall via swift-evolution]

> On Apr 20, 2017, at 7:31 PM, Douglas Gregor  wrote:
>> On Apr 20, 2017, at 3:39 PM, John McCall > > wrote:
>> 
>>> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor >> > wrote:
>>> 
>>> 
 On Apr 20, 2017, at 11:33 AM, Jordan Rose > wrote:
 
 
> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution 
> > wrote:
> 
> This makes the private/fileprivate distinction meaningful for extensions. 
> I think also bans the use of "private" at global scope for non-nominal 
> types or extensions thereof.  A clarifying update to the proposal is in 
> order, so developers can better understand the semantics. 
 
 Wait, hang on, then people have to write 'fileprivate' instead of 
 'private' for top-level typealiases (and functions?). 
>>> 
>>> That seems like the correct behavior; private is about members with 
>>> SE-0169. What do you think?
>>> 
>>> ...that seems suboptimal, given that the goal has been to make it possible 
>>> for people to use `private` more and not less frequently. IMO, there's no 
>>> need for `private typealias` at the global level to be prohibited.
>> 
>> Yeah, I see no reason for this to change the behavior of private extensions 
>> to be more restrictive than before.
> 
> So you’re okay with:
> 
>   private extension X {
> func foo() { }
>   }
> 
> being equivalent to
> 
>   extension X {
> fileprivate func foo() { }
>   }
> 
> rather than
> 
>   extension X {
> private func foo() { }
>   }
> 
> ?
> 
> That seems unintuitive at best.

Perhaps, but it's existing unintuitive behavior.  Are you suggesting that 
SE-0169 rationalizes changing it because (1) it's likely that a private 
extension is just meant for the use of other extensions of that type in the 
current file and (2) SE-0169 already allows such uses and so justifies the 
stricter rule?  That is an interesting theory, but I'm not sure I believe (1).  
More importantly, though, SE-0169 didn't actually propose changing this 
behavior, and it's a very substantial shift in behavior, and we haven't 
actually discussed or gathered any community feedback about it, so I'm really 
struggling to see why it wouldn't need to be a separate evolution proposal.  
And that would be difficult because, as a wise man once said to me, the core 
team considers the access-control matter closed for Swift 4 and will not be 
reviewing any further proposals in this area. :)

John.

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

[swift-evolution] Add MutableCollection.swap

[Ben Cohen via swift-evolution]

Hi Swift community,

Another pitch, this time related to the ownership manifesto.

Add MutableCollection.swap(_:with:)

Proposal: SE- 

Authors: Ben Cohen 
Review Manager: TBD
Status: Awaiting review
Introduction

As part of the introduction of the Law of Exclusivity, the current swap(_:_:) 
function must be addressed, as this most common uses of swap directly violate 
the law. This proposal introduces an alternative: a method onMutableCollection 
that takes two indices for swapping two elements in the same collection,.

Motivation

The primary purpose of the current swap function is to swap two elements within 
a mutable collection. It was originally created to support the sort algorithm, 
which is why it is declared in stdlib/sort.swift.gyb. Here is some typical 
usage from that file:

  while hi != lo {
swap([lo], [hi])
Under changes proposed as part of the ownership manfifesto, this will no longer 
be legal Swift: a single variable (in this case, elements) cannot be passed as 
two different inout arguments to the same function.

For more background on exclusivity and ownership, see the manfiesto 

Proposed solution

Introduce a new method on MutableCollection to the standard library that swaps 
the elements from two indices:

  while hi != lo {
elements.swap(lo, with: hi)
As well as resolving the conflict with the proposed language change, this 
appears to improve readability.

Existing usage on two elements in a collection will need to be migrated to the 
new method.

While swap was only intended to be used on collections, it is possible to use 
on other variables. However, the recommended style for these uses is to not use 
a function at all:

var a = 0
var b = 1

swap(,)
// can be rewritten as:
(a,b) = (b,a)
The existing swap method will remain, as under some circumstances it may result 
in a performance gain, particularly if move-only types are introduced in a 
later release.

Detailed design

Add the following method to the standard library:

extension MutableCollection {
  /// Exchange the values at indices `a` and `b`.
  ///
  /// Has no effect when `a` and `b` are equal.
  public mutating func swap(_ i: Index, with b: Index)
}
The current swap is required to fatalError on attempts to swap an element with 
itself for implementation reasons. This pushes the burden to check this first 
onto the caller. While swapping an element with itself is often a logic errror 
(for example, in a sort algorithm where you have a fenceposts bug), it is 
occasionally a valid situation (for example, it can occur easily in an 
implementation of shuffle). This implementation removes the precondition.

Deprecate the existing swap, and obsolete it in a later version of Swift.

Source compatibility

This is purely additive so should not be source breaking. However, due to 
current compiler behavior, it may be necessary to declare a version of the old 
swap on MutableCollection for Swift 3 compatibility purposes. This version will 
forward to the free function.

Effect on ABI stability

None.

Effect on API resilience

N/A

Alternatives considered

Instead of elements.swap(i, with: j), the following were considered:

elements.swap(at: i, j)
elements.swapElements(i, j)
elements.swap(elements: i, j)

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

Re: [swift-evolution] [Review] SE-0172: One-sided Ranges

[Douglas Gregor via swift-evolution]

> On Apr 20, 2017, at 6:36 AM, Matt Whiteside  wrote:
> 
> I do like this proposed one-sided range syntax, but a while back it was 
> pointed out that it might conflict with a candidate syntax for variadic 
> generics.  Has anything changed there?

It does conflict with the straw man syntax described in the generics manifesto:


https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#variadic-generics
 


but variadic generics are a long way off and the syntax is totally up in the 
air.

- Doug

> -Matt
> 
>> On Apr 17, 2017, at 21:40, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0172 "One-sided Ranges" begins now and runs through April 
>> 23, 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.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. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md
>>  
>> 
>> Reply text
>> Other replies
>>  
>> What
>>  goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine 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,
>> 
>> -Doug
>> 
>> 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] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Xiaodi Wu via swift-evolution]

On Thu, Apr 20, 2017 at 6:31 PM, Douglas Gregor  wrote:

>
> On Apr 20, 2017, at 3:39 PM, John McCall  wrote:
>
> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor  wrote:
>
>>
>>
>> On Apr 20, 2017, at 11:33 AM, Jordan Rose  wrote:
>>
>>
>> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> This makes the private/fileprivate distinction meaningful for extensions.
>> I think also bans the use of "private" at global scope for non-nominal
>> types or extensions thereof.  A clarifying update to the proposal is in
>> order, so developers can better understand the semantics.
>>
>>
>> Wait, hang on, then people have to write 'fileprivate' instead of
>> 'private' for top-level typealiases (and functions?).
>>
>>
>> That seems like the correct behavior; private is about members with
>> SE-0169. What do you think?
>>
>
> ...that seems suboptimal, given that the goal has been to make it possible
> for people to use `private` more and not less frequently. IMO, there's no
> need for `private typealias` at the global level to be prohibited.
>
>
> Yeah, I see no reason for this to change the behavior of private
> extensions to be more restrictive than before.
>
>
> So you’re okay with:
>
> private extension X {
>   func foo() { }
> }
>
> being equivalent to
>
> extension X {
>   fileprivate func foo() { }
> }
>
> rather than
>
> extension X {
>   private func foo() { }
> }
>
> ?
>
> That seems unintuitive at best.
>

Agree, but the rules for access modifiers in front of extensions have
always been different from those for everything else. Surely, we can
rationalize extensions here as you suggest without having to prohibit
private typealiases.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Douglas Gregor via swift-evolution]

> On Apr 20, 2017, at 3:39 PM, John McCall  wrote:
> 
>> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor > > wrote:
>> 
>> 
>>> On Apr 20, 2017, at 11:33 AM, Jordan Rose >> > wrote:
>>> 
>>> 
 On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution 
 > wrote:
 
 This makes the private/fileprivate distinction meaningful for extensions. 
 I think also bans the use of "private" at global scope for non-nominal 
 types or extensions thereof.  A clarifying update to the proposal is in 
 order, so developers can better understand the semantics. 
>>> 
>>> Wait, hang on, then people have to write 'fileprivate' instead of 'private' 
>>> for top-level typealiases (and functions?). 
>> 
>> That seems like the correct behavior; private is about members with SE-0169. 
>> What do you think?
>> 
>> ...that seems suboptimal, given that the goal has been to make it possible 
>> for people to use `private` more and not less frequently. IMO, there's no 
>> need for `private typealias` at the global level to be prohibited.
> 
> Yeah, I see no reason for this to change the behavior of private extensions 
> to be more restrictive than before.

So you’re okay with:

private extension X {
  func foo() { }
}

being equivalent to

extension X {
  fileprivate func foo() { }
}

rather than

extension X {
  private func foo() { }
}

?

That seems unintuitive at best.

- Doug


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

Re: [swift-evolution] [Pitch] Improve the API Design Guidelines about protocol naming

[Jonathan Hull via swift-evolution]

Just to play devil’s advocate, depending on how the protocol actually works, 
you could claim it *is* a RangeExpression (that is, it is something that can be 
turned into a range).  That was one of the proposals… I lost track of which one 
was accepted.

Thanks,
Jon


 
> On Apr 19, 2017, at 8:55 AM, Gwendal Roué via swift-evolution 
>  wrote:
> 
> 
>> Le 19 avr. 2017 à 17:23, Gwendal Roué  a écrit :
>> 
>> Re: [swift-evolution] [Review] SE-0172: One-sided Ranges
>> 
>> "RangeExpression" is an unexpected name. I was expecting "RangeProtocol", as 
>> in IteratorProtocol and LazySequenceProtocol. We need a consistent suffix 
>> for protocols that can't be named in -able,  -ible, or named with a simple 
>> noun because the noun is already used by a concrete type. "-Protocol" should 
>> be that prefix: RangeProtocol.
> 
> A detailed look at API Design Guidelines [1] shows that this subject is not 
> addressed:
> 
>>  • Protocols that describe what something is should read as nouns (e.g. 
>> `Collection`).
>>  • Protocols that describe a capability should be named using the 
>> suffixes `able`, `ible`, or `ing` (e.g. `Equatable`, `ProgressReporting`).
> 
> Nothing is said for "protocols that describe what something but can't be 
> named as nouns", or "protocols that describe a capability but can't be named 
> using the suffixes able, ible, or ing".
> 
> For example: the name of the protocol for all ranges discussed with SE-0172 
> should be addressed by the first rule (because the protocol describes what 
> something is rather than a capability). But that protocol can't be named 
> Range because Range is already taken.
> 
> Such a situation comes rather easily:
> 
> - in an evolving code base, when a protocol is added on top of an existing 
> type hierarchy which should be preserved (RangeProtocol added on top of 
> Range, ClosedRange, etc.)
> - at the birth of a code base, when a protocol coexists with a concrete type 
> which rightfully deserves the noun claimed by the protocol.
> 
> IteratorProtocol and LazySequenceProtocol have set a precedent: maybe we 
> should have the API Design Guidelines evolve with a third rule:
> 
> + When a protocol can't be named with a noun, or with an `able`, `ible`, or 
> `ing` suffix, the protocol should be named using the suffix `Protocol` (e.g. 
> `IteratorProtocol`).
> 
> What do you think?
> 
> Gwendal Roué
> [1] https://swift.org/documentation/api-design-guidelines/
> 
> ___
> 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] [Accepted] SE-0155: Normalize Enum Case Representation

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 20 Apr 2017, at 23:15, John McCall  wrote:
> 
> 
>> On Apr 20, 2017, at 5:50 PM, Goffredo Marocchi  wrote:
>> 
>> One thing I wanted to point out and that was a non trivial issue last year 
>> and that the core team did discuss and agreed to revisit (if I remember the 
>> thread update by Chris Lattner last year):
>> 
>> 
>>> Note that since the labels aren't part of a tuple, they no longer 
>>> participate in type checking, behaving consistently with functions.
>>> 
>>> let f = Expr.elet // f has type ([(String, Expr)], Expr) -> Expr f([], 
>>> anExpr) // Okay! f(locals: [], body: anExpr) // Won't compile.
>> I appreciate effort for consistency, but I hope this is not going to be used 
>> against the effort to bring labels in functions/stored closures/callbacks.
> 
> It will not.  The issues are unrelated.  Whatever rules we use for supporting 
> argument labels on indirect calls to functions will also apply to indirect 
> calls to enum case constructors.
> 

Thanks for your reply :).

> John.
> 
>> Swift, as we discussed last year, made a conscious, intentional effort to 
>> double down on the self documentation and call site readability of argument 
>> labels in general and the status quo after Swift 3/3.1 is not reflecting 
>> that whenever functions are stored in variables and/or passed to other 
>> functions as arguments.
>> 
>> I would like not to miss the Swift 4.0 deadline for this and we should 
>> discuss it sooner rather than later. I brought this up here because, for 
>> consistency, we are doubling down on something we should really be 
>> discussing to improve in my opinion.
> 
>> 
>> Sent from my iPhone
>> 
>>> On 20 Apr 2017, at 21:39, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
 On Thu, Apr 20, 2017 at 3:20 PM, John McCall via swift-evolution 
  wrote:
 Proposal Link: 
 https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
 
 Hello Swift Community,
 
 The review of SE-0155 "Normalize Enum Case Representation” ran from March 
 31st through April 10th, 2017. The proposal is accepted with revisions.
 
 Feedback from the community was positive about most aspects of the 
 proposal.  However, there was substantial disagreement about the right 
 direction for pattern matching.  The core team discussed this issue in 
 depth.
 
 Pattern matching is central to the use of enum types.  It's the only way 
 you can use an enum value, besides general operations like passing it to a 
 function or the special affordances for Optionals.  Pattern matching is as 
 central to enums as stored property access is to structs, and it's fair to 
 be worried about anything that would make it substantially more onerous.  
 Unconditionally requiring associated-value labels in case patterns would 
 certainly do that, and several members of the core team expressed concern 
 that it would be bad enough to discourage the use of associated-value 
 labels completely — in effect, subverting the entire language feature 
 being proposed.
 
 It is true that including associated-value labels in case patterns does 
 preserve a great deal of information in the source code:
 
   - This information can usefully contribute to the clarity of the code 
 following the pattern.
 
   - Hiding this information can lead to bugs that would be self-evident if 
 the case labels were always included.  For example, if a case payload 
 included a number of different boolean flags, it would be easy for a 
 pattern to accidentally label them in the wrong order.
 
   - Finally, this information may be necessary in order to determine which 
 case is being matched, since the proposal adds the ability to distinguish 
 cases purely by the labels on associated values.
 
 However, the core team feels that there are counter-arguments which weaken 
 the force of these considerations:
 
   - While an associated-value label can indeed contribute to the 
 readability of the pattern, the programmer can also choose a meaningful 
 name to bind to the associated value.  This binding name can convey at 
 least as much information as a label would.
 
   - The risk of mis-labelling an associated value grows as the number of 
 associated values grows.  However, very few cases carry a large number of 
 associated values.  As the amount of information which the case should 
 carry grows, it becomes more and more interesting to encapsulate that 
 information in its own struct — among other reasons, to avoid the need to 
 revise every matching case-pattern in the program.  Furthermore, when a 
 case does carry a significant number of associated values, there is often 
 a 

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[John McCall via swift-evolution]

> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor  > wrote:
> 
> 
>> On Apr 20, 2017, at 11:33 AM, Jordan Rose > > wrote:
>> 
>> 
>>> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution 
>>> > wrote:
>>> 
>>> This makes the private/fileprivate distinction meaningful for extensions. I 
>>> think also bans the use of "private" at global scope for non-nominal types 
>>> or extensions thereof.  A clarifying update to the proposal is in order, so 
>>> developers can better understand the semantics. 
>> 
>> Wait, hang on, then people have to write 'fileprivate' instead of 'private' 
>> for top-level typealiases (and functions?).
> 
> That seems like the correct behavior; private is about members with SE-0169. 
> What do you think?
> 
> ...that seems suboptimal, given that the goal has been to make it possible 
> for people to use `private` more and not less frequently. IMO, there's no 
> need for `private typealias` at the global level to be prohibited.

Yeah, I see no reason for this to change the behavior of private extensions to 
be more restrictive than before.

John.

> 
> 
>> Apart from whether or not that's desirable, it's not backwards-compatible.
> 
> Very true! It’s an easy thing to migrate, but it’s a source break 
> nonetheless. Let’s decide if it’s desirable and bring it up with the core 
> team.
> 
>   - Doug
> 
> 
> 
> ___
> 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] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Xiaodi Wu via swift-evolution]

On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor  wrote:

>
>
> On Apr 20, 2017, at 11:33 AM, Jordan Rose  wrote:
>
>
> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This makes the private/fileprivate distinction meaningful for extensions.
> I think also bans the use of "private" at global scope for non-nominal
> types or extensions thereof.  A clarifying update to the proposal is in
> order, so developers can better understand the semantics.
>
>
> Wait, hang on, then people have to write 'fileprivate' instead of
> 'private' for top-level typealiases (and functions?).
>
>
> That seems like the correct behavior; private is about members with
> SE-0169. What do you think?
>

...that seems suboptimal, given that the goal has been to make it possible
for people to use `private` more and not less frequently. IMO, there's no
need for `private typealias` at the global level to be prohibited.


> Apart from whether or not that's desirable, it's not backwards-compatible.
>
>
> Very true! It’s an easy thing to migrate, but it’s a source break
> nonetheless. Let’s decide if it’s desirable and bring it up with the core
> team.
>
> - Doug
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0155: Normalize Enum Case Representation

[John McCall via swift-evolution]

> On Apr 20, 2017, at 5:50 PM, Goffredo Marocchi  wrote:
> 
> One thing I wanted to point out and that was a non trivial issue last year 
> and that the core team did discuss and agreed to revisit (if I remember the 
> thread update by Chris Lattner last year):
> 
> 
>> Note that since the labels aren't part of a tuple, they no longer 
>> participate in type checking, behaving consistently with functions.
>> 
>> let f = Expr.elet // f has type ([(String, Expr)], Expr) -> Expr f([], 
>> anExpr) // Okay! f(locals: [], body: anExpr) // Won't compile.
> I appreciate effort for consistency, but I hope this is not going to be used 
> against the effort to bring labels in functions/stored closures/callbacks.

It will not.  The issues are unrelated.  Whatever rules we use for supporting 
argument labels on indirect calls to functions will also apply to indirect 
calls to enum case constructors.

John.

> Swift, as we discussed last year, made a conscious, intentional effort to 
> double down on the self documentation and call site readability of argument 
> labels in general and the status quo after Swift 3/3.1 is not reflecting that 
> whenever functions are stored in variables and/or passed to other functions 
> as arguments.
> 
> I would like not to miss the Swift 4.0 deadline for this and we should 
> discuss it sooner rather than later. I brought this up here because, for 
> consistency, we are doubling down on something we should really be discussing 
> to improve in my opinion.

> 
> Sent from my iPhone
> 
> On 20 Apr 2017, at 21:39, Xiaodi Wu via swift-evolution 
> > wrote:
> 
>> On Thu, Apr 20, 2017 at 3:20 PM, John McCall via swift-evolution 
>> > wrote:
>> Proposal Link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>>  
>> 
>> 
>> Hello Swift Community,
>> 
>> The review of SE-0155 "Normalize Enum Case Representation” ran from March 
>> 31st through April 10th, 2017. The proposal is accepted with revisions.
>> 
>> Feedback from the community was positive about most aspects of the proposal. 
>>  However, there was substantial disagreement about the right direction for 
>> pattern matching.  The core team discussed this issue in depth.
>> 
>> Pattern matching is central to the use of enum types.  It's the only way you 
>> can use an enum value, besides general operations like passing it to a 
>> function or the special affordances for Optionals.  Pattern matching is as 
>> central to enums as stored property access is to structs, and it's fair to 
>> be worried about anything that would make it substantially more onerous.  
>> Unconditionally requiring associated-value labels in case patterns would 
>> certainly do that, and several members of the core team expressed concern 
>> that it would be bad enough to discourage the use of associated-value labels 
>> completely — in effect, subverting the entire language feature being 
>> proposed.
>> 
>> It is true that including associated-value labels in case patterns does 
>> preserve a great deal of information in the source code:
>> 
>>   - This information can usefully contribute to the clarity of the code 
>> following the pattern.
>> 
>>   - Hiding this information can lead to bugs that would be self-evident if 
>> the case labels were always included.  For example, if a case payload 
>> included a number of different boolean flags, it would be easy for a pattern 
>> to accidentally label them in the wrong order.
>> 
>>   - Finally, this information may be necessary in order to determine which 
>> case is being matched, since the proposal adds the ability to distinguish 
>> cases purely by the labels on associated values.
>> 
>> However, the core team feels that there are counter-arguments which weaken 
>> the force of these considerations:
>> 
>>   - While an associated-value label can indeed contribute to the readability 
>> of the pattern, the programmer can also choose a meaningful name to bind to 
>> the associated value.  This binding name can convey at least as much 
>> information as a label would.
>> 
>>   - The risk of mis-labelling an associated value grows as the number of 
>> associated values grows.  However, very few cases carry a large number of 
>> associated values.  As the amount of information which the case should carry 
>> grows, it becomes more and more interesting to encapsulate that information 
>> in its own struct — among other reasons, to avoid the need to revise every 
>> matching case-pattern in the program.  Furthermore, when a case does carry a 
>> significant number of associated values, there is often a positional 
>> conventional between them that lowers the risk of re-ordering: for example, 
>> the conventional 

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Douglas Gregor via swift-evolution]

> On Apr 20, 2017, at 11:33 AM, Jordan Rose  wrote:
> 
> 
>> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> This makes the private/fileprivate distinction meaningful for extensions. I 
>> think also bans the use of "private" at global scope for non-nominal types 
>> or extensions thereof.  A clarifying update to the proposal is in order, so 
>> developers can better understand the semantics. 
> 
> Wait, hang on, then people have to write 'fileprivate' instead of 'private' 
> for top-level typealiases (and functions?).

That seems like the correct behavior; private is about members with SE-0169. 
What do you think?

> Apart from whether or not that's desirable, it's not backwards-compatible.

Very true! It’s an easy thing to migrate, but it’s a source break nonetheless. 
Let’s decide if it’s desirable and bring it up with the core team.

- Doug


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

Re: [swift-evolution] [Accepted] SE-0155: Normalize Enum Case Representation

[Goffredo Marocchi via swift-evolution]

One thing I wanted to point out and that was a non trivial issue last year and 
that the core team did discuss and agreed to revisit (if I remember the thread 
update by Chris Lattner last year):

> Note that since the labels aren't part of a tuple, they no longer participate 
> in type checking, behaving consistently with functions.
> 
> let f = Expr.elet // f has type ([(String, Expr)], Expr) -> Expr f([], 
> anExpr) // Okay! f(locals: [], body: anExpr) // Won't compile.
I appreciate effort for consistency, but I hope this is not going to be used 
against the effort to bring labels in functions/stored closures/callbacks.

Swift, as we discussed last year, made a conscious, intentional effort to 
double down on the self documentation and call site readability of argument 
labels in general and the status quo after Swift 3/3.1 is not reflecting that 
whenever functions are stored in variables and/or passed to other functions as 
arguments.

I would like not to miss the Swift 4.0 deadline for this and we should discuss 
it sooner rather than later. I brought this up here because, for consistency, 
we are doubling down on something we should really be discussing to improve in 
my opinion.

Sent from my iPhone

> On 20 Apr 2017, at 21:39, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Thu, Apr 20, 2017 at 3:20 PM, John McCall via swift-evolution 
>>  wrote:
>> Proposal Link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>> 
>> Hello Swift Community,
>> 
>> The review of SE-0155 "Normalize Enum Case Representation” ran from March 
>> 31st through April 10th, 2017. The proposal is accepted with revisions.
>> 
>> Feedback from the community was positive about most aspects of the proposal. 
>>  However, there was substantial disagreement about the right direction for 
>> pattern matching.  The core team discussed this issue in depth.
>> 
>> Pattern matching is central to the use of enum types.  It's the only way you 
>> can use an enum value, besides general operations like passing it to a 
>> function or the special affordances for Optionals.  Pattern matching is as 
>> central to enums as stored property access is to structs, and it's fair to 
>> be worried about anything that would make it substantially more onerous.  
>> Unconditionally requiring associated-value labels in case patterns would 
>> certainly do that, and several members of the core team expressed concern 
>> that it would be bad enough to discourage the use of associated-value labels 
>> completely — in effect, subverting the entire language feature being 
>> proposed.
>> 
>> It is true that including associated-value labels in case patterns does 
>> preserve a great deal of information in the source code:
>> 
>>   - This information can usefully contribute to the clarity of the code 
>> following the pattern.
>> 
>>   - Hiding this information can lead to bugs that would be self-evident if 
>> the case labels were always included.  For example, if a case payload 
>> included a number of different boolean flags, it would be easy for a pattern 
>> to accidentally label them in the wrong order.
>> 
>>   - Finally, this information may be necessary in order to determine which 
>> case is being matched, since the proposal adds the ability to distinguish 
>> cases purely by the labels on associated values.
>> 
>> However, the core team feels that there are counter-arguments which weaken 
>> the force of these considerations:
>> 
>>   - While an associated-value label can indeed contribute to the readability 
>> of the pattern, the programmer can also choose a meaningful name to bind to 
>> the associated value.  This binding name can convey at least as much 
>> information as a label would.
>> 
>>   - The risk of mis-labelling an associated value grows as the number of 
>> associated values grows.  However, very few cases carry a large number of 
>> associated values.  As the amount of information which the case should carry 
>> grows, it becomes more and more interesting to encapsulate that information 
>> in its own struct — among other reasons, to avoid the need to revise every 
>> matching case-pattern in the program.  Furthermore, when a case does carry a 
>> significant number of associated values, there is often a positional 
>> conventional between them that lowers the risk of re-ordering: for example, 
>> the conventional left-then-right ordering of a binary search tree.  
>> Therefore this risk is somewhat over-stated, and of course the programmer 
>> should remain free to include labels for cases where they feel the risk is 
>> significant.
>> 
>>   - It is likely that cases will continue to be predominantly distinguished 
>> by their base name alone.  Methods are often distinguished by argument 
>> labels because the base name identifies an entire class of operation with 
>> many possible variants.  In contrast, each 

[swift-evolution] Rationalizing Sequence end-operation names

[James Froggatt via swift-evolution]

What's the status on this proposal?

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

It's currently marked as deferred due to time constraints leading up to the 
release of Swift 3. Is this still in scope for Swift 4, given it's a breaking 
change?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0155: Normalize Enum Case Representation

[John McCall via swift-evolution]

> On Apr 20, 2017, at 4:39 PM, Xiaodi Wu  wrote:
> 
> On Thu, Apr 20, 2017 at 3:20 PM, John McCall via swift-evolution 
> > wrote:
> Proposal Link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>  
> 
> 
> Hello Swift Community,
> 
> The review of SE-0155 "Normalize Enum Case Representation” ran from March 
> 31st through April 10th, 2017. The proposal is accepted with revisions.
> 
> Feedback from the community was positive about most aspects of the proposal.  
> However, there was substantial disagreement about the right direction for 
> pattern matching.  The core team discussed this issue in depth.
> 
> Pattern matching is central to the use of enum types.  It's the only way you 
> can use an enum value, besides general operations like passing it to a 
> function or the special affordances for Optionals.  Pattern matching is as 
> central to enums as stored property access is to structs, and it's fair to be 
> worried about anything that would make it substantially more onerous.  
> Unconditionally requiring associated-value labels in case patterns would 
> certainly do that, and several members of the core team expressed concern 
> that it would be bad enough to discourage the use of associated-value labels 
> completely — in effect, subverting the entire language feature being proposed.
> 
> It is true that including associated-value labels in case patterns does 
> preserve a great deal of information in the source code:
> 
>   - This information can usefully contribute to the clarity of the code 
> following the pattern.
> 
>   - Hiding this information can lead to bugs that would be self-evident if 
> the case labels were always included.  For example, if a case payload 
> included a number of different boolean flags, it would be easy for a pattern 
> to accidentally label them in the wrong order.
> 
>   - Finally, this information may be necessary in order to determine which 
> case is being matched, since the proposal adds the ability to distinguish 
> cases purely by the labels on associated values.
> 
> However, the core team feels that there are counter-arguments which weaken 
> the force of these considerations:
> 
>   - While an associated-value label can indeed contribute to the readability 
> of the pattern, the programmer can also choose a meaningful name to bind to 
> the associated value.  This binding name can convey at least as much 
> information as a label would.
> 
>   - The risk of mis-labelling an associated value grows as the number of 
> associated values grows.  However, very few cases carry a large number of 
> associated values.  As the amount of information which the case should carry 
> grows, it becomes more and more interesting to encapsulate that information 
> in its own struct — among other reasons, to avoid the need to revise every 
> matching case-pattern in the program.  Furthermore, when a case does carry a 
> significant number of associated values, there is often a positional 
> conventional between them that lowers the risk of re-ordering: for example, 
> the conventional left-then-right ordering of a binary search tree.  Therefore 
> this risk is somewhat over-stated, and of course the programmer should remain 
> free to include labels for cases where they feel the risk is significant.
> 
>   - It is likely that cases will continue to be predominantly distinguished 
> by their base name alone.  Methods are often distinguished by argument labels 
> because the base name identifies an entire class of operation with many 
> possible variants.  In contrast, each case of an enum is a kind of data, and 
> its name is conventionally more like the name of a property than the name of 
> a method, and thus likely to be unique among all the cases.  Even when cases 
> are distinguished using only associated value labels, it simply means that 
> the corresponding case-patterns must include those labels; we should not feel 
> required to force that burden on all other case-patterns purely to achieve 
> consistency with this presumably-unusual style.
> 
> Accordingly, while it needs to be possible to include associated value labels 
> in a case-pattern, and in some situations it may be wise to include them, the 
> core team believes that requiring associated value labels would be unduly 
> onerous.  Therefore, the core teams revises the proposal as follows:
> 
> A case pattern may omit labels for the associated values of a case if there 
> is only one case with the same base name and arity.  A pattern must omit all 
> labels if it omits any of them; thus, a case pattern either exactly matches 
> the full name of a case or has no labels at all.  For example:
> 
>   enum E {
> case often(first: Int, second: Int)
> case 

Re: [swift-evolution] [Accepted] SE-0155: Normalize Enum Case Representation

[Xiaodi Wu via swift-evolution]

On Thu, Apr 20, 2017 at 3:20 PM, John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

> Proposal Link: https://github.com/apple/swift-evolution/blob/
> master/proposals/0155-normalize-enum-case-representation.md
>
> Hello Swift Community,
>
> The review of SE-0155 "Normalize Enum Case Representation” ran from March
> 31st through April 10th, 2017. The proposal is *accepted with revisions*.
>
> Feedback from the community was positive about most aspects of the
> proposal.  However, there was substantial disagreement about the right
> direction for pattern matching.  The core team discussed this issue in
> depth.
>
> Pattern matching is central to the use of enum types.  It's the only way
> you can use an enum value, besides general operations like passing it to a
> function or the special affordances for Optionals.  Pattern matching is as
> central to enums as stored property access is to structs, and it's fair to
> be worried about anything that would make it substantially more onerous.
> Unconditionally requiring associated-value labels in case patterns would
> certainly do that, and several members of the core team expressed concern
> that it would be bad enough to discourage the use of associated-value
> labels completely — in effect, subverting the entire language feature being
> proposed.
>
> It is true that including associated-value labels in case patterns does
> preserve a great deal of information in the source code:
>
>   - This information can usefully contribute to the clarity of the code
> following the pattern.
>
>   - Hiding this information can lead to bugs that would be self-evident if
> the case labels were always included.  For example, if a case payload
> included a number of different boolean flags, it would be easy for a
> pattern to accidentally label them in the wrong order.
>
>   - Finally, this information may be necessary in order to determine which
> case is being matched, since the proposal adds the ability to distinguish
> cases purely by the labels on associated values.
>
> However, the core team feels that there are counter-arguments which weaken
> the force of these considerations:
>
>   - While an associated-value label can indeed contribute to the
> readability of the pattern, the programmer can also choose a meaningful
> name to bind to the associated value.  This binding name can convey at
> least as much information as a label would.
>
>   - The risk of mis-labelling an associated value grows as the number of
> associated values grows.  However, very few cases carry a large number of
> associated values.  As the amount of information which the case should
> carry grows, it becomes more and more interesting to encapsulate that
> information in its own struct — among other reasons, to avoid the need to
> revise every matching case-pattern in the program.  Furthermore, when a
> case does carry a significant number of associated values, there is often a
> positional conventional between them that lowers the risk of re-ordering:
> for example, the conventional left-then-right ordering of a binary search
> tree.  Therefore this risk is somewhat over-stated, and of course the
> programmer should remain free to include labels for cases where they feel
> the risk is significant.
>
>   - It is likely that cases will continue to be predominantly
> distinguished by their base name alone.  Methods are often distinguished by
> argument labels because the base name identifies an entire class of
> operation with many possible variants.  In contrast, each case of an enum
> is a kind of data, and its name is conventionally more like the name of a
> property than the name of a method, and thus likely to be unique among all
> the cases.  Even when cases *are* distinguished using only associated
> value labels, it simply means that the corresponding case-patterns must
> include those labels; we should not feel required to force that burden on
> all other case-patterns purely to achieve consistency with this
> presumably-unusual style.
>
> Accordingly, while it needs to be *possible* to include associated value
> labels in a case-pattern, and in some situations it may be *wise* to
> include them, the core team believes that requiring associated value labels
> would be unduly onerous.  Therefore, the core teams revises the proposal as
> follows:
>
> A case pattern may omit labels for the associated values of a case if
> there is only one case with the same base name and arity.  A pattern must
> omit all labels if it omits any of them; thus, a case pattern either
> exactly matches the full name of a case or has no labels at all.  For
> example:
>
>   enum E {
> case often(first: Int, second: Int)
> case lots(first: Int, second: Int)
> case many(value: Int)
> case many(first: Int, second: Int)
> case many(alpha: Int, beta: Int)
> case sometimes(value: Int)
> case sometimes(Int)
>   }
>
>   switch e {
>   // Valid: the sequence of labels exactly 

Re: [swift-evolution] [Pitch] Improve the API Design Guidelines about protocol naming

[Gmail via swift-evolution]

Sorry if my original reply didn’t come across as neutral as I had hoped. I 
actually like the Protocol suffix and have used it when the name I wanted to 
use was already taken by a concrete type. 

I’m not sure yet if a Protocol suffix would “always” be the right choice when a 
protocol can't be named with a noun, or with an `able`, `ible`, or `ing` 
suffix. There might not be that many cases. 

How about a guideline that only covers the case when a protocol coexists with a 
concrete type? Maybe something like:

 + When a protocol and a concrete type contest for the same name, the protocol 
should be named using the suffix `Protocol` (e.g. `IteratorProtocol`).

That would both apply to the Range protocol naming, and would follow the the 
established pattern set by IteratorProtocol, LazySequenceProtocol which seem to 
have come from 
[SE-0006](https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md):

> Strip `Type` suffix from protocol names. In a few special cases this means 
> adding a `Protocol` suffix to get out of the way of type names that are 
> primary (though most of these we expect to be obsoleted by Swift 3 language 
> features).

David

> On 20 Apr 2017, at 18:55, Jordan Rose  wrote:
> 
> Yeah, I wasn't trying to take a side, just identifying where David might have 
> heard "Protocol" in an official Apple presentation. I'm staying out of this 
> one. :-)
> 
> Jordan
> 
>> On Apr 20, 2017, at 00:21, Gwendal Roué > > wrote:
>> 
>> Well, IteratorProtocol, LazySequenceProtocol weren't imported from ObjC.
>> 
>> They set a precedent for the -Protocol suffix.
>> 
>> Now, even if you don't like RangeProtocol, this doesn't make RangeExpression 
>> better.
>> 
>> "Expression" and `1...` don't belong to the same level of the language: one 
>> is a concept of that belongs to the compiler, when the other is a plain 
>> value used in a program:
>> 
>> When a program does `1 + 2`, it both sums two integers, and builds a 
>> expression from two other expressions and an operator. Both are true. Yet 1 
>> is of type `Integer`, not `IntegerExpression`.
>> 
>> Currently all types of the standard library belong the program realm, not to 
>> the compiler realm. I wish we wouldn't break this practice, and avoid 
>> `RangeExpression`.
>> 
>> That's why I suggest `RangeProtocol`. Other options could be `Ranging`, 
>> `Bounds`...
>> 
>> Gwendal Roué
>> 
>> 
>> Le 19 avr. 2017 à 23:35, Jordan Rose > > a écrit :
>> 
>>> That was probably about the ObjC importer, which does this (appends 
>>> "Protocol") when there's a class and protocol with the same name in the 
>>> same module. That doesn't necessarily mean it's the right thing to put in 
>>> the API guidelines, though.
>>> 
>>> Jordan
>>> 
>>> 
 On Apr 19, 2017, at 10:59, Gmail via swift-evolution 
 > wrote:
 
 I seem to recall that something (maybe a WWDC session) mentioned something 
 about protocols that in essence represent a single type would have the 
 Protocol-suffix. 
 
 Unfortunately I couldn’t find it (yet?). The closest I’ve found so far is 
 http://asciiwwdc.com/2014/sessions/407 
  but I’m not sure that was it.
 > essentially when there's a conflict between a class name and a protocol 
 > name, we'll append protocol to the name of the protocol.
 
 David
 
> On 19 Apr 2017, at 17:55, Gwendal Roué via swift-evolution 
> > wrote:
> 
> 
>> Le 19 avr. 2017 à 17:23, Gwendal Roué > > a écrit :
>> 
>> Re: [swift-evolution] [Review] SE-0172: One-sided Ranges
>> 
>> "RangeExpression" is an unexpected name. I was expecting 
>> "RangeProtocol", as in IteratorProtocol and LazySequenceProtocol. We 
>> need a consistent suffix for protocols that can't be named in -able,  
>> -ible, or named with a simple noun because the noun is already used by a 
>> concrete type. "-Protocol" should be that prefix: RangeProtocol.
> 
> A detailed look at API Design Guidelines [1] shows that this subject is 
> not addressed:
> 
>>  • Protocols that describe what something is should read as nouns (e.g. 
>> `Collection`).
>>  • Protocols that describe a capability should be named using the 
>> suffixes `able`, `ible`, or `ing` (e.g. `Equatable`, 
>> `ProgressReporting`).
> 
> Nothing is said for "protocols that describe what something but can't be 
> named as nouns", or "protocols that describe a capability but can't be 
> named using the suffixes able, ible, or ing".
> 
> For example: the name of the protocol 

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

[Xiaodi Wu via swift-evolution]

On Thu, Apr 20, 2017 at 11:48 AM, Adrian Zubarev <
adrian.zuba...@devandartist.com> wrote:

> The multi-line string literal as it’s accepted right now only allows
> pretty code generation with smaller lines.
>

This statement does not make sense to me. Multiline string literals allow
(with the unavoidable exception of some escape sequences) code written
inside the quotations marks to be exactly as pretty as the resulting string
itself. That is why it's a literal.

The literal itself is not reserved for JSON, XML and similar syntaxes only,
> which automatically implies the existence of conventions with longer lines.
> For whatever reasons a developer might have, it’s essential to allow manual
> line wrapping without injecting a new line into the resulting string.
>

You keep re-stating instead of explaining why you think this is essential.
What are the "whatever reasons" for a developer to need this feature? It is
critical enough to be worth complicating the design for something like
literal syntax, which should be as lightweight, straightforward, and simple
as possible?

Not everyone uses the same editor width nor the same editor with exact the
> same settings.
>

Do you think it is a common use case that someone will want to have text
that looks the same only to people reading the code, but not to people
reading the resulting string? Do you think someone might want to put code
inside a string literal, then wrap the literal using 80-character lines,
but write the code inside to wrap using 120-character lines? These seem
like rather implausible use cases.

You simply cannot and really should not rely on any editor or linter for
> that matter,
>

If you are going to view a Swift file, you're going to do it through some
program or other. Is it reasonable to add features to Swift because some
hypothetical text editors might not be able to wrap lines?

nor do I vision it as a strong argument against having the ability to
> escape the new line injection. I don’t think we should ever expect the
> average Swift developer sitting in-front of an ultra wide monitor.
>
> Consider this example:
>
> // Currently it would look like this:
>
> let myLongString = "Ut wisi enim ad minim veniam, quis nostrud exerci tation 
> ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis 
> autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie 
> consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et 
> accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit 
> augue duis dolore te feugait nulla facilisi.\n\nNam liber tempor cum soluta 
> nobis eleifend option congue nihil imperdiet doming id quod mazim placerat 
> facer possim assum. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, 
> sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat 
> volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation 
> ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo 
> consequat.\n\nDuis autem vel eum iriure dolor in hendrerit in vulputate velit 
> esse molestie consequat, vel illum dolore eu feugiat nulla facilisis."
>
> // With the accepted version of the proposal it becomes a little bit better, 
> but still to long,
> // because we can only replace `\n` characters with lines and that's it.
>
> let myLongString = """
>Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper 
> suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum 
> iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel 
> illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto 
> odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore 
> te feugait nulla facilisi.
>
>Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet 
> doming id quod mazim placerat facer possim assum. Lorem ipsum dolor sit amet, 
> consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut 
> laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, 
> quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex 
> ea commodo consequat.
>
>Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse 
> molestie consequat, vel illum dolore eu feugiat nulla facilisis.
>"""
>
> // This is how it should ideally look like and be editor/IDE/linter 
> independent.
> // The string produces the same result as above and does not rely on any
> // soft-wrapping functionality
>
>
Why should one not rely on editors being able to soft wrap? Which editors
cannot soft wrap? What is wrong with soft wrapping?


>  and is written within some smaller line width.
> // The trailing precision is a really good tradeoff at this point.
>
> let myLongString = """
>Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper 
> suscipit \
>lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum 
> iriure 

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

[Ben Rimmington via swift-evolution]

> On 20 Apr 2017, at 17:48, Adrian Zubarev wrote:
> 
> Some words about the trailing precision. Joe said that we could use \("") as 
> workaround, but if I recall correctly literals are banned from the 
> interpolation itself, which will result in us doing something like this:
> 
> let end = ""
> 
> let myString = """
>foo\(end)
>"""
> This is a very dirty and tedious solution for that problem.
> 



* Expressions interpolated in strings may now contain string literals.
  For example, `My name is \(attributes["name"]!)` is now a valid expression.
  **(14050788)**

-- Ben

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

[swift-evolution] [Pitch] Don't require & for UnsafeRawPointer

[Anders Kierulf via swift-evolution]

Summary: Currently, only mutable values can be passed to UnsafeRawPointer, 
except for a special case for arrays. That special case should be generalized, 
allowing any values to be passed to UnsafeRawPointer without using &.

The following code shows the inconsistency in passing values to 
UnsafeRawPointer:

var varArray = [Int](repeating: 0, count: 6)
var varTuple = (0, 0, 0, 0, 0, 0)

let letArray = [Int](repeating: 0, count: 6)
let letTuple = (0, 0, 0, 0, 0, 0)

func get(_ pointer: UnsafeRawPointer, at index: Int) -> Int {
let a = pointer.bindMemory(to: Int.self, capacity: 6)
return a[index]
}

// Array can be passed directly, automatically takes address.
_ = get(varArray, at: 2) // okay
_ = get(letArray, at: 2) // okay

// When explicitly taking address, can only pass mutable variables.
_ = get(, at: 2) // okay, but seems inconsistent
_ = get(, at: 2) // fails: & not allowed

// Passing tuple instead of array fails.
_ = get(varTuple, at: 2) // fails: wrong type
_ = get(letTuple, at: 2) // fails: wrong type

// Adding & to pass a tuple only works for mutable values. Having to
// pass the address using & means that any methods calling this must
// be mutating, even though they don't mutate.
_ = get(, at: 2) // okay, but forces mutating
_ = get(, at: 2) // fails: cannot pass immutable value

Passing a value to an UnsafeRawPointer parameter should not require use of &, 
as that forces all code calling it to be mutating. Having a special case for 
array also doesn't make sense, as the idea of UnsafeRawPointer is that we're 
interpreting that memory content as whatever we want. Logged as SR-4649.

Proposal:
- Never require & when passing value to UnsafeRawPointer.
- Always require & when passing value to UnsafeMutableRawPointer.

(Fixed size arrays are still needed, but with this tweak, workarounds can be 
made to work.)

Anders Kierulf

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

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Jordan Rose via swift-evolution]

> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution 
>  wrote:
> 
> This makes the private/fileprivate distinction meaningful for extensions. I 
> think also bans the use of "private" at global scope for non-nominal types or 
> extensions thereof.  A clarifying update to the proposal is in order, so 
> developers can better understand the semantics. 

Wait, hang on, then people have to write 'fileprivate' instead of 'private' for 
top-level typealiases (and functions?). Apart from whether or not that's 
desirable, it's not backwards-compatible.

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

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Martin R via swift-evolution]

So is it correct to say that for all types T which NSNumber can hold (Double, 
Float, Int, UInt, ... )

T(exactly: someNSNumber)

will succeed if and only if

NSNumber(value: T(truncating: someNSNumber)) == someNSNumber

holds? 

> On 20. Apr 2017, at 18:10, Philippe Hausler  wrote:
> 
>> 
>> On Apr 19, 2017, at 6:09 PM, Xiaodi Wu > > wrote:
>> 
>> 
>> 
>> On Wed, Apr 19, 2017 at 6:35 PM, Philippe Hausler > > wrote:
>> 
>> 
>>> On Apr 19, 2017, at 16:17, Xiaodi Wu >> > wrote:
>>> 
>>> On Wed, Apr 19, 2017 at 6:00 PM, Philippe Hausler >> > wrote:
>>> 
 On Apr 19, 2017, at 3:23 PM, Xiaodi Wu > wrote:
 
 On Wed, Apr 19, 2017 at 3:19 PM, Martin R > wrote:
> On 19. Apr 2017, at 01:48, Xiaodi Wu  > wrote:
> 
> So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would 
> expect NSNumber to behave similarly (a notion with which Martin 
> disagrees, I guess). I don't see a test that shows whether NSNumber 
> behaves or does not behave in that way.
 
 At present they behave differently: 
 
 print(Float(exactly: Double.pi) as Any)
 // nil
 print(Float(exactly: NSNumber(value: Double.pi)) as Any)
 // Optional(3.14159274)
 
 I realize that identical behavior would be logical and least surprising. 
 My only concern was about cases like
 
 let num = ... // some NSNumber from a JSON deserialization
 let fval = Float(exactly: num)
 
 where one cannot know how the number is represented internally and what 
 precision it needs. But then one could use the truncating conversion or 
 `.floatValue` instead.
 
 JSON numbers are double-precision floating point, unless I'm 
 misunderstanding something. If someone writes `Float(exactly: 
 valueParsedFromJSON)`, surely, that can only mean that they *really, 
 really* prefer nil over an imprecise value. I can see no other reason to 
 insist on using both Float and .init(exactly:).
>>> 
>>> JSON does not claim 32 or 64 bit floating point, or for that matter 128 or 
>>> infinite bit floating point :(
>>> 
>>> 
>>> Oops, you're right. I see they've wanted to future-proof this. That said, 
>>> RFC 7159 *does* say:
>>> 
>>> This specification allows implementations to set limits on the range
>>> and precision of numbers accepted.  Since software that implements
>>> IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
>>> generally available and widely used, good interoperability can be
>>> achieved by implementations that expect no more precision or range
>>> than these provide, in the sense that implementations will
>>> approximate JSON numbers within the expected precision.
>>> 
>>> So JSON doesn't set limits on how numbers are represented, but JSON 
>>> implementations are permitted to (and I'd imagine that all in fact do). A 
>>> user of a JSON deserialization library can rightly expect to know the 
>>> numeric limits of that implementation; for the purposes of bridging 
>>> NSNumber, if the answer is that the implementation parses JSON numbers as 
>>> double-precision values, Double(exactly:) would be the right choice; 
>>> otherwise, if it's 80-bit values, then Float80(exactly:) would be the right 
>>> choice, etc.
>>> 
>> 
>> Float80 is not compatible with NSNumber; and is well out of scope for this 
>> proposal.
>> 
>> OK, so Double is the largest floating point type compatible with NSNumber? 
>> It stands to reason that any Swift JSON implementation that uses NSNumber 
>> for parsed floating point values would at most have that much range and 
>> precision, right?
> 
> For JSONSerialization (which I am most familiar with and ships with 
> Foundation); it can emit both NSNumbers and NSDecimalNumber. A rough 
> approximation of the behavior: if it can store the value in an integer type 
> it stores it as such in a NSNumber (iirc up to UINT64_MAX) and then if it has 
> a decimal point it will attempt to parse as a double but if that is not 
> enough storage it will store the best possible value into NSDecimalNumber. 
> 
> So NSNumber itself (excluding subclasses) can only store up to a 64 bit 
> value. 
> 
>> 
>> If so, then every floating point value parsed by any such Swift JSON 
>> implementation would be exactly representable as a Double: regardless of 
>> whether that specific implementation uses Float or Double under the hood, 
>> every Float can be represented exactly as a Double. If a user is trying to 
>> bridge such a NSNumber instance specifically to *Float* instead of Double, 
>> and they are asking for an 

[swift-evolution] "Universal Error" testing method

[Joshua Marner via swift-evolution]

I propose adding some kind of mechanism that allows better reporting in
unit tests dealing with Universal Errors

(and Logic Failures
).
Currently the attitude is very RTFM-esq concerning implicit unwrap
operators and other runtime exceptions (eg, "the programmer should know
better than to use ! incorrectly"). This is very unhelpful for running
acceptance tests for large projects with many contributors, as the current
behavior will actually crash the entire test running process resulting in
no opportunities for reporting the error and logging it as a test failure
if a programmer made a mistake. This is made even more frustrating by the
fact that these are often simple fixes once they are located, but are
impossible to locate by reviewing test results or even console output in
many cases. At best, we get the name of the failing test buried in the
console output.

My proposal is to add an optional mechanism by which implicit, runtime
errors can be propagated on a "best effort" basis (starting with implicit
unwraps, asserts and array out-of-bounds array accesses) to allow calling
code to report the error. For example, we could use a keyword like "unsafe
do/catch" or something similar to enable this behavior on all code within
the block, or we could extend the "@testable import" keyword to also enable
unwinding runtime errors for the import in question. This would preserve
behavior in existing code by making it completely opt-in.

Using the "@testable import" keyword should prevent abuse of this feature
in normal applications. It also has the side benefit of encouraging the
programmer of writing tests if they get better error reporting in the
context of a testing framework.

The rollout of such a feature will be nice in that it doesn't have to be
completely implemented in order to be useful, since we are only talking
about affecting test results.

Any concerns? This feature suggestion has been borne out of much
frustration, so there are undoubtedly aspects that I missed.

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

Re: [swift-evolution] SE-0068 MIA? - Self.classMethod() from instance methods

[Joe Groff via swift-evolution]

> On Apr 20, 2017, at 8:13 AM, John Holdsworth via swift-evolution 
>  wrote:
> 
> I was going to have a look at creating a new proposal for this but I see 
> there already
> is one 
> 
>  and the start of an implementation 
> . Is there any chance this is in 
> the pipeline?

We haven't had time to invest in implementing this yet. Since it's a purely 
additive feature, the acceptance of the proposal still stand, and we would 
accept a good implementation of it at any time. It does however require some 
relatively deep refactoring of the modeling of Self types across the AST and 
SIL layers, which is currently very superficial, in order to successfully 
implement, which is part of why we haven't gotten around to it yet.

-Joe

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

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Xiaodi Wu via swift-evolution]

Right. I think we're in vigorous agreement.


On Thu, Apr 20, 2017 at 11:11 Philippe Hausler  wrote:

> On Apr 19, 2017, at 6:09 PM, Xiaodi Wu  wrote:
>
>
>
> On Wed, Apr 19, 2017 at 6:35 PM, Philippe Hausler 
> wrote:
>
>>
>>
>> On Apr 19, 2017, at 16:17, Xiaodi Wu  wrote:
>>
>> On Wed, Apr 19, 2017 at 6:00 PM, Philippe Hausler 
>> wrote:
>>
>>>
>>> On Apr 19, 2017, at 3:23 PM, Xiaodi Wu  wrote:
>>>
>>> On Wed, Apr 19, 2017 at 3:19 PM, Martin R  wrote:
>>>
 On 19. Apr 2017, at 01:48, Xiaodi Wu  wrote:

 So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I
 would expect NSNumber to behave similarly (a notion with which Martin
 disagrees, I guess). I don't see a test that shows whether NSNumber behaves
 or does not behave in that way.


 At present they behave differently:

 print(Float(exactly: Double.pi) as Any)
 // nil
 print(Float(exactly: NSNumber(value: Double.pi)) as Any)
 // Optional(3.14159274)

 I realize that identical behavior would be logical and least
 surprising. My only concern was about cases like

 let num = ... // some NSNumber from a JSON deserialization
 let fval = Float(exactly: num)

 where one cannot know how the number is represented internally and what
 precision it needs. But then one could use the truncating conversion or
 `.floatValue` instead.

>>>
>>> JSON numbers are double-precision floating point, unless I'm
>>> misunderstanding something. If someone writes `Float(exactly:
>>> valueParsedFromJSON)`, surely, that can only mean that they *really,
>>> really* prefer nil over an imprecise value. I can see no other reason to
>>> insist on using both Float and .init(exactly:).
>>>
>>>
>>> JSON does not claim 32 or 64 bit floating point, or for that matter 128
>>> or infinite bit floating point :(
>>>
>>
>>
>> Oops, you're right. I see they've wanted to future-proof this. That said,
>> RFC 7159 *does* say:
>>
>> This specification allows implementations to set limits on the range
>>
>> and precision of numbers accepted.  Since software that implements
>>
>> IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
>>> generally available and widely used, good interoperability can be
>>> achieved by implementations that expect no more precision or range
>>> than these provide, in the sense that implementations will
>>> approximate JSON numbers within the expected precision.
>>
>>
>> So JSON doesn't set limits on how numbers are represented, but JSON
>> implementations are permitted to (and I'd imagine that all in fact do). A
>> user of a JSON deserialization library can rightly expect to know the
>> numeric limits of that implementation; for the purposes of bridging
>> NSNumber, if the answer is that the implementation parses JSON numbers as
>> double-precision values, Double(exactly:) would be the right choice;
>> otherwise, if it's 80-bit values, then Float80(exactly:) would be the right
>> choice, etc.
>>
>>
>> Float80 is not compatible with NSNumber; and is well out of scope for
>> this proposal.
>>
>
> OK, so Double is the largest floating point type compatible with NSNumber?
> It stands to reason that any Swift JSON implementation that uses NSNumber
> for parsed floating point values would at most have that much range and
> precision, right?
>
>
> For JSONSerialization (which I am most familiar with and ships with
> Foundation); it can emit both NSNumbers and NSDecimalNumber. A rough
> approximation of the behavior: if it can store the value in an integer type
> it stores it as such in a NSNumber (iirc up to UINT64_MAX) and then if it
> has a decimal point it will attempt to parse as a double but if that is not
> enough storage it will store the best possible value into NSDecimalNumber.
>
> So NSNumber itself (excluding subclasses) can only store up to a 64 bit
> value.
>
>
> If so, then every floating point value parsed by any such Swift JSON
> implementation would be exactly representable as a Double: regardless of
> whether that specific implementation uses Float or Double under the hood,
> every Float can be represented exactly as a Double. If a user is trying to
> bridge such a NSNumber instance specifically to *Float* instead of Double,
> and they are asking for an exact value, there's no a priori reason to think
> that this user would be more likely to care only about the range and not
> the precision, or vice versa. Which is to say, I don't think you'll get too
> many bug reports :)
>
>
> In my mind there are two considerations here; balance against the surprise
> from new developers learning their first programming language versus
> consistency. In the end even if I believe the behavior is sub-par I would
> rather it be consistent. Primarily consistency is easier 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

[Tony Parker via swift-evolution]

Hi everyone,

Thanks for your feedback on this proposal. Based on that plus additional 
feedback from core team members and others who responded off-thread, we are 
making the following small adjustments:

* KeyedEncoderContainerProtocol, KeyedDecodingContainerProtocol, 
UnkeyedEncodingContainer, UnkeyedDecodingContainer, 
SingleValueEncodingContainer, SingleValueDecodingContainer will drop their 
Data-taking functions. Data will conform to Codable, so it just goes through 
the normal paths like other types.
* The above will allow those protocols, plus Encodable, Decodable, typealias 
Codable,  Encoder, Decoder, CodingKey, struct CodingUserInfoKey to be part of 
the standard library (not in Foundation), resolving the concern about reaching 
too far up the stack for the compiler.
* JSONEncoder/Decoder, PropertyListEncoder/Decoder remain in Foundation. These 
are concrete implementations of the above protocols, like the ones that will 
appear in many libraries, we hope.

We are not currently proposing using the integer protocols. The reasoning is 
that using them them confers a requirement upon all possible encoders and 
decoders to support arbitrary-width integers and floating point values. We’re 
not convinced this is feasible, but we will continue to evaluate.

If the core team accepts the modified proposal, we will get this merged as soon 
as possible with the goal of allowing all of you to try everything out via 
Swift’s frequent toolchain snapshots. We will be looking for feedback on how it 
works in more real world scenarios, and we will consider further adjustments to 
the API before Swift 4 is final. We are hoping that this extended trial period 
will allow us to make sure that everything works out the way we expected.

Thanks,
- Tony

> On Apr 6, 2017, at 11:10 AM, Douglas Gregor  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0166 "Swift Archival & Serialization" begins now and runs 
> through April 12, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.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. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
>  
> 
> Reply text
> Other replies
>  
> What
>  goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine 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,
> 
> -Doug
> 
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

[Adrian Zubarev via swift-evolution]

Exactly, thank you for the clarification. That is the correct decision IMO. :)

Here is the formatted version of the example from my last reply:

https://gist.github.com/DevAndArtist/345ce0920de62349c1079e18201aea94



-- 
Adrian Zubarev
Sent with Airmail

Am 20. April 2017 um 18:58:07, Joe Groff via swift-evolution 
(swift-evolution@swift.org) schrieb:


On Apr 19, 2017, at 3:27 PM, Xiaodi Wu  wrote:

On Wed, Apr 19, 2017 at 5:24 PM, Joe Groff  wrote:

> On Apr 19, 2017, at 3:16 PM, Xiaodi Wu via swift-evolution 
>  wrote:
>
> We had a very full debate about which way was superior during review; it was 
> proposed to behave one way and the core team decided on the other. We have to 
> let settled decisions be settled: that's the only way Swift Evolution will 
> continue to work.

I'm asking the core team for clarification on the point of the closing newline.

Cool, thanks. Please do remind them, though, that not stripping the closing 
newline (which is what was originally proposed) *and* not having the option of 
using `\` to elide newlines (which is contrary to what was originally proposed) 
would mean that all multi-line strings would mandatorily end in a newline.

To clarify, the core team's decision is that one trailing newline should be 
elided before the closing delimiter. This maintains one consistent rule for 
both ends of the literal, so """\n and \n""" can be mentally understood as 
balanced delimiters. as Xiaodi noted, it would otherwise be impossible to write 
a literal without a trailing newline without scope-creeping the design with 
additional features.

-Joe
___
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] [Accepted] SE-0168: Multi-Line String Literals

[Joe Groff via swift-evolution]

> On Apr 19, 2017, at 3:27 PM, Xiaodi Wu  wrote:
> 
> On Wed, Apr 19, 2017 at 5:24 PM, Joe Groff  > wrote:
> 
> > On Apr 19, 2017, at 3:16 PM, Xiaodi Wu via swift-evolution 
> > > wrote:
> >
> > We had a very full debate about which way was superior during review; it 
> > was proposed to behave one way and the core team decided on the other. We 
> > have to let settled decisions be settled: that's the only way Swift 
> > Evolution will continue to work.
> 
> I'm asking the core team for clarification on the point of the closing 
> newline.
> 
> Cool, thanks. Please do remind them, though, that not stripping the closing 
> newline (which is what was originally proposed) *and* not having the option 
> of using `\` to elide newlines (which is contrary to what was originally 
> proposed) would mean that all multi-line strings would mandatorily end in a 
> newline.

To clarify, the core team's decision is that one trailing newline should be 
elided before the closing delimiter. This maintains one consistent rule for 
both ends of the literal, so """\n and \n""" can be mentally understood as 
balanced delimiters. as Xiaodi noted, it would otherwise be impossible to write 
a literal without a trailing newline without scope-creeping the design with 
additional features.

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

Re: [swift-evolution] [Pitch] Improve the API Design Guidelines about protocol naming

[Jordan Rose via swift-evolution]

Yeah, I wasn't trying to take a side, just identifying where David might have 
heard "Protocol" in an official Apple presentation. I'm staying out of this 
one. :-)

Jordan

> On Apr 20, 2017, at 00:21, Gwendal Roué  wrote:
> 
> Well, IteratorProtocol, LazySequenceProtocol weren't imported from ObjC.
> 
> They set a precedent for the -Protocol suffix.
> 
> Now, even if you don't like RangeProtocol, this doesn't make RangeExpression 
> better.
> 
> "Expression" and `1...` don't belong to the same level of the language: one 
> is a concept of that belongs to the compiler, when the other is a plain value 
> used in a program:
> 
> When a program does `1 + 2`, it both sums two integers, and builds a 
> expression from two other expressions and an operator. Both are true. Yet 1 
> is of type `Integer`, not `IntegerExpression`.
> 
> Currently all types of the standard library belong the program realm, not to 
> the compiler realm. I wish we wouldn't break this practice, and avoid 
> `RangeExpression`.
> 
> That's why I suggest `RangeProtocol`. Other options could be `Ranging`, 
> `Bounds`...
> 
> Gwendal Roué
> 
> 
> Le 19 avr. 2017 à 23:35, Jordan Rose  > a écrit :
> 
>> That was probably about the ObjC importer, which does this (appends 
>> "Protocol") when there's a class and protocol with the same name in the same 
>> module. That doesn't necessarily mean it's the right thing to put in the API 
>> guidelines, though.
>> 
>> Jordan
>> 
>> 
>>> On Apr 19, 2017, at 10:59, Gmail via swift-evolution 
>>> > wrote:
>>> 
>>> I seem to recall that something (maybe a WWDC session) mentioned something 
>>> about protocols that in essence represent a single type would have the 
>>> Protocol-suffix. 
>>> 
>>> Unfortunately I couldn’t find it (yet?). The closest I’ve found so far is 
>>> http://asciiwwdc.com/2014/sessions/407 
>>>  but I’m not sure that was it.
>>> > essentially when there's a conflict between a class name and a protocol 
>>> > name, we'll append protocol to the name of the protocol.
>>> 
>>> David
>>> 
 On 19 Apr 2017, at 17:55, Gwendal Roué via swift-evolution 
 > wrote:
 
 
> Le 19 avr. 2017 à 17:23, Gwendal Roué  > a écrit :
> 
> Re: [swift-evolution] [Review] SE-0172: One-sided Ranges
> 
> "RangeExpression" is an unexpected name. I was expecting "RangeProtocol", 
> as in IteratorProtocol and LazySequenceProtocol. We need a consistent 
> suffix for protocols that can't be named in -able,  -ible, or named with 
> a simple noun because the noun is already used by a concrete type. 
> "-Protocol" should be that prefix: RangeProtocol.
 
 A detailed look at API Design Guidelines [1] shows that this subject is 
 not addressed:
 
>   • Protocols that describe what something is should read as nouns (e.g. 
> `Collection`).
>   • Protocols that describe a capability should be named using the 
> suffixes `able`, `ible`, or `ing` (e.g. `Equatable`, `ProgressReporting`).
 
 Nothing is said for "protocols that describe what something but can't be 
 named as nouns", or "protocols that describe a capability but can't be 
 named using the suffixes able, ible, or ing".
 
 For example: the name of the protocol for all ranges discussed with 
 SE-0172 should be addressed by the first rule (because the protocol 
 describes what something is rather than a capability). But that protocol 
 can't be named Range because Range is already taken.
 
 Such a situation comes rather easily:
 
 - in an evolving code base, when a protocol is added on top of an existing 
 type hierarchy which should be preserved (RangeProtocol added on top of 
 Range, ClosedRange, etc.)
 - at the birth of a code base, when a protocol coexists with a concrete 
 type which rightfully deserves the noun claimed by the protocol.
 
 IteratorProtocol and LazySequenceProtocol have set a precedent: maybe we 
 should have the API Design Guidelines evolve with a third rule:
 
 + When a protocol can't be named with a noun, or with an `able`, `ible`, 
 or `ing` suffix, the protocol should be named using the suffix `Protocol` 
 (e.g. `IteratorProtocol`).
 
 What do you think?
 
 Gwendal Roué
 [1] https://swift.org/documentation/api-design-guidelines/ 
 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

[Adrian Zubarev via swift-evolution]

The multi-line string literal as it’s accepted right now only allows pretty 
code generation with smaller lines. The literal itself is not reserved for 
JSON, XML and similar syntaxes only, which automatically implies the existence 
of conventions with longer lines. For whatever reasons a developer might have, 
it’s essential to allow manual line wrapping without injecting a new line into 
the resulting string. Not everyone uses the same editor width nor the same 
editor with exact the same settings. You simply cannot and really should not 
rely on any editor or linter for that matter, nor do I vision it as a strong 
argument against having the ability to escape the new line injection. I don’t 
think we should ever expect the average Swift developer sitting in-front of an 
ultra wide monitor.

Consider this example:

// Currently it would look like this:

let myLongString = "Ut wisi enim ad minim veniam, quis nostrud exerci tation 
ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis 
autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie 
consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan 
et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis 
dolore te feugait nulla facilisi.\n\nNam liber tempor cum soluta nobis eleifend 
option congue nihil imperdiet doming id quod mazim placerat facer possim assum. 
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh 
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim 
ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl 
ut aliquip ex ea commodo consequat.\n\nDuis autem vel eum iriure dolor in 
hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu 
feugiat nulla facilisis."

// With the accepted version of the proposal it becomes a little bit better, 
but still to long,
// because we can only replace `\n` characters with lines and that's it.

let myLongString = """
   Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper 
suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum 
iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum 
dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio 
dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te 
feugait nulla facilisi.  

   Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet 
doming id quod mazim placerat facer possim assum. Lorem ipsum dolor sit amet, 
consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut 
laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis 
nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea 
commodo consequat.  

   Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse 
molestie consequat, vel illum dolore eu feugiat nulla facilisis.  
   """

// This is how it should ideally look like and be editor/IDE/linter 
independent.  
// The string produces the same result as above and does not rely on any  
// soft-wrapping functionality and is written within some smaller line width.
// The trailing precision is a really good tradeoff at this point.

let myLongString = """
   Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper 
suscipit \
   lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure \
   dolor in hendrerit in vulputate velit esse molestie consequat, vel illum 
dolore \
   eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim 
qui \
   blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla 
facilisi.  

   Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet 
doming \
   id quod mazim placerat facer possim assum. Lorem ipsum dolor sit amet, 
consectetuer \
   adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore 
magna \
   aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci 
tation \
   ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.  

   Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse 
molestie \
   consequat, vel illum dolore eu feugiat nulla facilisis.
   """
The string concatenation uses optimization magic behind the scenes which is not 
obvious for everyone. I personally think that every operation involved in 
concatenation or any operation in-general adds a performance overhead and 
theoretically needs more time to resolve the expression at runtime, which is 
the natural way of thinking without any knowledge about the optimization the 
compiler is able to do for you. A string literal is able to solve that issue 
during compile time is simply the perfect place for that.

Some words about the trailing precision. Joe said that we could use \("") as 
workaround, but if I recall correctly literals are banned from 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

> On Apr 19, 2017, at 6:09 PM, Xiaodi Wu  wrote:
> 
> 
> 
> On Wed, Apr 19, 2017 at 6:35 PM, Philippe Hausler  > wrote:
> 
> 
>> On Apr 19, 2017, at 16:17, Xiaodi Wu > > wrote:
>> 
>> On Wed, Apr 19, 2017 at 6:00 PM, Philippe Hausler > > wrote:
>> 
>>> On Apr 19, 2017, at 3:23 PM, Xiaodi Wu >> > wrote:
>>> 
>>> On Wed, Apr 19, 2017 at 3:19 PM, Martin R >> > wrote:
 On 19. Apr 2017, at 01:48, Xiaodi Wu > wrote:
 
 So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would 
 expect NSNumber to behave similarly (a notion with which Martin disagrees, 
 I guess). I don't see a test that shows whether NSNumber behaves or does 
 not behave in that way.
>>> 
>>> At present they behave differently: 
>>> 
>>> print(Float(exactly: Double.pi) as Any)
>>> // nil
>>> print(Float(exactly: NSNumber(value: Double.pi)) as Any)
>>> // Optional(3.14159274)
>>> 
>>> I realize that identical behavior would be logical and least surprising. My 
>>> only concern was about cases like
>>> 
>>> let num = ... // some NSNumber from a JSON deserialization
>>> let fval = Float(exactly: num)
>>> 
>>> where one cannot know how the number is represented internally and what 
>>> precision it needs. But then one could use the truncating conversion or 
>>> `.floatValue` instead.
>>> 
>>> JSON numbers are double-precision floating point, unless I'm 
>>> misunderstanding something. If someone writes `Float(exactly: 
>>> valueParsedFromJSON)`, surely, that can only mean that they *really, 
>>> really* prefer nil over an imprecise value. I can see no other reason to 
>>> insist on using both Float and .init(exactly:).
>> 
>> JSON does not claim 32 or 64 bit floating point, or for that matter 128 or 
>> infinite bit floating point :(
>> 
>> 
>> Oops, you're right. I see they've wanted to future-proof this. That said, 
>> RFC 7159 *does* say:
>> 
>> This specification allows implementations to set limits on the range
>> and precision of numbers accepted.  Since software that implements
>> IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
>> generally available and widely used, good interoperability can be
>> achieved by implementations that expect no more precision or range
>> than these provide, in the sense that implementations will
>> approximate JSON numbers within the expected precision.
>> 
>> So JSON doesn't set limits on how numbers are represented, but JSON 
>> implementations are permitted to (and I'd imagine that all in fact do). A 
>> user of a JSON deserialization library can rightly expect to know the 
>> numeric limits of that implementation; for the purposes of bridging 
>> NSNumber, if the answer is that the implementation parses JSON numbers as 
>> double-precision values, Double(exactly:) would be the right choice; 
>> otherwise, if it's 80-bit values, then Float80(exactly:) would be the right 
>> choice, etc.
>> 
> 
> Float80 is not compatible with NSNumber; and is well out of scope for this 
> proposal.
> 
> OK, so Double is the largest floating point type compatible with NSNumber? It 
> stands to reason that any Swift JSON implementation that uses NSNumber for 
> parsed floating point values would at most have that much range and 
> precision, right?

For JSONSerialization (which I am most familiar with and ships with 
Foundation); it can emit both NSNumbers and NSDecimalNumber. A rough 
approximation of the behavior: if it can store the value in an integer type it 
stores it as such in a NSNumber (iirc up to UINT64_MAX) and then if it has a 
decimal point it will attempt to parse as a double but if that is not enough 
storage it will store the best possible value into NSDecimalNumber. 

So NSNumber itself (excluding subclasses) can only store up to a 64 bit value. 

> 
> If so, then every floating point value parsed by any such Swift JSON 
> implementation would be exactly representable as a Double: regardless of 
> whether that specific implementation uses Float or Double under the hood, 
> every Float can be represented exactly as a Double. If a user is trying to 
> bridge such a NSNumber instance specifically to *Float* instead of Double, 
> and they are asking for an exact value, there's no a priori reason to think 
> that this user would be more likely to care only about the range and not the 
> precision, or vice versa. Which is to say, I don't think you'll get too many 
> bug reports :)

In my mind there are two considerations here; balance against the surprise from 
new developers learning their first programming language versus consistency. In 
the end even if I believe the behavior is sub-par I would rather it be 

[swift-evolution] SE-0068 MIA? - Self.classMethod() from instance methods

[John Holdsworth via swift-evolution]

I was going to have a look at creating a new proposal for this but I see there 
already
is one 

 and the start of an implementation . 
Is there any chance this is in the pipeline?

- John

> On 13 Dec 2016, at 02:13, Xiaodi Wu  wrote:
> 
> On Mon, Dec 12, 2016 at 6:15 PM, John Holdsworth via swift-evolution 
> > wrote:
> I’m sure it’s been discussed before but I wish static and class vars and
> functions were in scope for instance methods without having to prefix them
> as they are in Java.
> 
> I agree that it's annoying to have to prefix them with 
> `VeryLongTypeNames.everyTime()`. Fortunately, SE-0068 was already approved a 
> long time ago that makes this a lot better, though it's not the specific 
> solution you're advocating for. Namely, we'll be able to write 
> `Self.everyTime()` instead, and IMO it can't come fast enough. It's just that 
> no one has stepped up to implement it. Santa?
>  
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-165: Dictionary & Set Enhancements

[Ben Cohen via swift-evolution]

Hello Swift Community,

The review of SE-165: Dictionary & Set Enhancements ran from April 6...11, 
2017. The proposal is accepted with some revisions regarding naming:

1) The key/value sequence of init that does not take a closure resolving key 
conflicts will be named init(uniqueKeysWithValues:). The core team felt that 
either possible implementation – a default way of coalescing keys, or 
fatalError-ing on conflicts – could be surprising to users in ways that could 
easily be missed in testing. A failable initializer would probably result in 
frequent force-unwrapping. Giving the initializer an argument label that 
clearly states the uniqueness requirement fulfills the goal of making sure the 
caller is aware of the requirement.

2) The initializer that takes a sequence of pairs and a closure for conflicts 
will be named init(_:uniquingKeysWith:), and the two merge methods (mutating 
and non-mutating) named merge(_:uniquingKeysWith:) and 
merging(_:uniquingKeysWith:).

3) The group-by method on Sequence will be made into an initializer on 
Dictionary: init(grouping elements: S, by: (E) -> Key) where 
Value == [E], S.Iterator.Element == E

The author will revise the proposal according. Thank you to everyone who 
participated in the review of what will be some really useful additions to 
Dictionary!

Ben Cohen
Review Manager


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

Re: [swift-evolution] [Review] SE-0172: One-sided Ranges

[Matt Whiteside via swift-evolution]

I do like this proposed one-sided range syntax, but a while back it was pointed 
out that it might conflict with a candidate syntax for variadic generics.  Has 
anything changed there?

-Matt

> On Apr 17, 2017, at 21:40, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0172 "One-sided Ranges" begins now and runs through April 
> 23, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.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. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md
>  
> 
> Reply text
> Other replies
>  
> What
>  goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine 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,
> 
> -Doug
> 
> 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] Improve the API Design Guidelines about protocol naming

[Riley Testut via swift-evolution]

+1 to the proposal, *especially* the addition of the RangeExpression protocol.

That being said, I agree with the critiques over the chosen name. I also can't 
remember where exactly, but I do remember at some point hearing that the 
-Protocol suffix should be added to protocol names if needed to disambiguate 
them from concrete types (and have followed this convention in my own projects).

While I actually believe taken at face value "RangeExpression" is a better name 
than "RangeProtocol", I believe RangeProtocol is better overall as it is more 
consistent with the naming conventions. (As an aside, I much preferred Swift 
2's "-Type" suffix naming convention for protocols. However, since we're no 
longer using that, might as well be consistent with other protocol names.)

> On Apr 20, 2017, at 12:21 AM, Gwendal Roué via swift-evolution 
>  wrote:
> 
> Well, IteratorProtocol, LazySequenceProtocol weren't imported from ObjC.
> 
> They set a precedent for the -Protocol suffix.
> 
> Now, even if you don't like RangeProtocol, this doesn't make RangeExpression 
> better.
> 
> "Expression" and `1...` don't belong to the same level of the language: one 
> is a concept of that belongs to the compiler, when the other is a plain value 
> used in a program:
> 
> When a program does `1 + 2`, it both sums two integers, and builds a 
> expression from two other expressions and an operator. Both are true. Yet 1 
> is of type `Integer`, not `IntegerExpression`.
> 
> Currently all types of the standard library belong the program realm, not to 
> the compiler realm. I wish we wouldn't break this practice, and avoid 
> `RangeExpression`.
> 
> That's why I suggest `RangeProtocol`. Other options could be `Ranging`, 
> `Bounds`...
> 
> Gwendal Roué
> 
> 
>> Le 19 avr. 2017 à 23:35, Jordan Rose  a écrit :
>> 
>> That was probably about the ObjC importer, which does this (appends 
>> "Protocol") when there's a class and protocol with the same name in the same 
>> module. That doesn't necessarily mean it's the right thing to put in the API 
>> guidelines, though.
>> 
>> Jordan
>> 
>> 
>>> On Apr 19, 2017, at 10:59, Gmail via swift-evolution 
>>>  wrote:
>>> 
>>> I seem to recall that something (maybe a WWDC session) mentioned something 
>>> about protocols that in essence represent a single type would have the 
>>> Protocol-suffix. 
>>> 
>>> Unfortunately I couldn’t find it (yet?). The closest I’ve found so far is 
>>> http://asciiwwdc.com/2014/sessions/407 but I’m not sure that was it.
>>> > essentially when there's a conflict between a class name and a protocol 
>>> > name, we'll append protocol to the name of the protocol.
>>> 
>>> David
>>> 
> On 19 Apr 2017, at 17:55, Gwendal Roué via swift-evolution 
>  wrote:
> 
> 
> Le 19 avr. 2017 à 17:23, Gwendal Roué  a écrit :
> 
> Re: [swift-evolution] [Review] SE-0172: One-sided Ranges
> 
> "RangeExpression" is an unexpected name. I was expecting "RangeProtocol", 
> as in IteratorProtocol and LazySequenceProtocol. We need a consistent 
> suffix for protocols that can't be named in -able,  -ible, or named with 
> a simple noun because the noun is already used by a concrete type. 
> "-Protocol" should be that prefix: RangeProtocol.
 
 A detailed look at API Design Guidelines [1] shows that this subject is 
 not addressed:
 
>   • Protocols that describe what something is should read as nouns (e.g. 
> `Collection`).
>   • Protocols that describe a capability should be named using the 
> suffixes `able`, `ible`, or `ing` (e.g. `Equatable`, `ProgressReporting`).
 
 Nothing is said for "protocols that describe what something but can't be 
 named as nouns", or "protocols that describe a capability but can't be 
 named using the suffixes able, ible, or ing".
 
 For example: the name of the protocol for all ranges discussed with 
 SE-0172 should be addressed by the first rule (because the protocol 
 describes what something is rather than a capability). But that protocol 
 can't be named Range because Range is already taken.
 
 Such a situation comes rather easily:
 
 - in an evolving code base, when a protocol is added on top of an existing 
 type hierarchy which should be preserved (RangeProtocol added on top of 
 Range, ClosedRange, etc.)
 - at the birth of a code base, when a protocol coexists with a concrete 
 type which rightfully deserves the noun claimed by the protocol.
 
 IteratorProtocol and LazySequenceProtocol have set a precedent: maybe we 
 should have the API Design Guidelines evolve with a third rule:
 
 + When a protocol can't be named with a noun, or with an `able`, `ible`, 
 or `ing` suffix, the protocol should be named using the suffix `Protocol` 
 (e.g. 

Re: [swift-evolution] [Pitch] Improve the API Design Guidelines about protocol naming

[Gwendal Roué via swift-evolution]

Well, IteratorProtocol, LazySequenceProtocol weren't imported from ObjC.

They set a precedent for the -Protocol suffix.

Now, even if you don't like RangeProtocol, this doesn't make RangeExpression 
better.

"Expression" and `1...` don't belong to the same level of the language: one is 
a concept of that belongs to the compiler, when the other is a plain value used 
in a program:

When a program does `1 + 2`, it both sums two integers, and builds a expression 
from two other expressions and an operator. Both are true. Yet 1 is of type 
`Integer`, not `IntegerExpression`.

Currently all types of the standard library belong the program realm, not to 
the compiler realm. I wish we wouldn't break this practice, and avoid 
`RangeExpression`.

That's why I suggest `RangeProtocol`. Other options could be `Ranging`, 
`Bounds`...

Gwendal Roué


> Le 19 avr. 2017 à 23:35, Jordan Rose  a écrit :
> 
> That was probably about the ObjC importer, which does this (appends 
> "Protocol") when there's a class and protocol with the same name in the same 
> module. That doesn't necessarily mean it's the right thing to put in the API 
> guidelines, though.
> 
> Jordan
> 
> 
>> On Apr 19, 2017, at 10:59, Gmail via swift-evolution 
>>  wrote:
>> 
>> I seem to recall that something (maybe a WWDC session) mentioned something 
>> about protocols that in essence represent a single type would have the 
>> Protocol-suffix. 
>> 
>> Unfortunately I couldn’t find it (yet?). The closest I’ve found so far is 
>> http://asciiwwdc.com/2014/sessions/407 but I’m not sure that was it.
>> > essentially when there's a conflict between a class name and a protocol 
>> > name, we'll append protocol to the name of the protocol.
>> 
>> David
>> 
 On 19 Apr 2017, at 17:55, Gwendal Roué via swift-evolution 
  wrote:
 
 
 Le 19 avr. 2017 à 17:23, Gwendal Roué  a écrit :
 
 Re: [swift-evolution] [Review] SE-0172: One-sided Ranges
 
 "RangeExpression" is an unexpected name. I was expecting "RangeProtocol", 
 as in IteratorProtocol and LazySequenceProtocol. We need a consistent 
 suffix for protocols that can't be named in -able,  -ible, or named with a 
 simple noun because the noun is already used by a concrete type. 
 "-Protocol" should be that prefix: RangeProtocol.
>>> 
>>> A detailed look at API Design Guidelines [1] shows that this subject is not 
>>> addressed:
>>> 
• Protocols that describe what something is should read as nouns (e.g. 
 `Collection`).
• Protocols that describe a capability should be named using the 
 suffixes `able`, `ible`, or `ing` (e.g. `Equatable`, `ProgressReporting`).
>>> 
>>> Nothing is said for "protocols that describe what something but can't be 
>>> named as nouns", or "protocols that describe a capability but can't be 
>>> named using the suffixes able, ible, or ing".
>>> 
>>> For example: the name of the protocol for all ranges discussed with SE-0172 
>>> should be addressed by the first rule (because the protocol describes what 
>>> something is rather than a capability). But that protocol can't be named 
>>> Range because Range is already taken.
>>> 
>>> Such a situation comes rather easily:
>>> 
>>> - in an evolving code base, when a protocol is added on top of an existing 
>>> type hierarchy which should be preserved (RangeProtocol added on top of 
>>> Range, ClosedRange, etc.)
>>> - at the birth of a code base, when a protocol coexists with a concrete 
>>> type which rightfully deserves the noun claimed by the protocol.
>>> 
>>> IteratorProtocol and LazySequenceProtocol have set a precedent: maybe we 
>>> should have the API Design Guidelines evolve with a third rule:
>>> 
>>> + When a protocol can't be named with a noun, or with an `able`, `ible`, or 
>>> `ing` suffix, the protocol should be named using the suffix `Protocol` 
>>> (e.g. `IteratorProtocol`).
>>> 
>>> What do you think?
>>> 
>>> Gwendal Roué
>>> [1] https://swift.org/documentation/api-design-guidelines/
>>> 
>>> ___
>>> 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