Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Christopher Kornher via swift-evolution]

> On Dec 4, 2017, at 1:12 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> On 04.12.2017 19:27, Joe DeCapo via swift-evolution wrote:
>>> On Dec 4, 2017, at 10:08 AM, Benjamin G via swift-evolution 
>>> > wrote:
>>> 
>>> 1_ From what i understood from this discussion (please correct me if i'm 
>>> wrong) python code is already callable from swift right now, without any 
>>> modification to the compiler, but then the syntax to *some* very generic 
>>> python function would just not be really pretty. If it's just library 
>>> calls, we could just wrap those calls into pretty functions for our needs, 
>>> but then :
>> I think it's worthwhile to add this syntactic sugar to make wrapper 
>> libraries easier to write and reason about. From Chris's example playground:
>> let d = np.call(member: "array", args: Python.array(6, 7, 8),
>> kwargs: [("dtype", "i2")])
>> // Python:d = np.array([1, 2, 3], dtype="i2")
>> // Future Swift:  let d = np.array([6, 7, 8], dtype: "i2")
>> It's far easier (at least for me) to read the sugared Swift version and 
>> understand what it is doing than how it's currently required to be written.
> 
> Yes, it is easier to read, if you just wrote this. But not easier to 
> understand when you are looking into some one's code during the debugging to 
> try to understand what is not working exactly, where is the normal static 
> code and where is next dynamic call.
> I strongly believe that dynamic code should not looks like normal "static" 
> code in Swift, because this is not expected by *Swift* developer.  When we 
> look on method name/property *we* expect it is defined somewhere, we can find 
> definition, we know what rules are applied to that "object" like method or 
> property.
> 
> I'll be glad if more people use Swift, I think that Python/Ruby/etc interop 
> could be useful and we need ergonomic syntax for this, but I don't agree that 
> we should change Swift to be more comfortable for non-Swift devs when this 
> change complicates live of Swift devs.
> 
> Probably the correct way to have dynamic calls in Swift is to 'mark' such 
> code with special flag and we need to find it. For example:
> 
> > // Python:d = np.array([1, 2, 3], dtype="i2")
> > // Future Swift:  let d = np.@array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np@array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np:array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np.~array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np.@array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np."array"([6, 7, 8], dtype: "i2") // name of 
> > dynamic method is like just string, no any guarantee & we can have any 
> > needed symbol in string to express the details of target dynamic 
> > language(if needed)
> > // etc

Unless I am mistaken, an intelligent editor would have enough information to 
demarcate dynamic calls which would accomplish your objective without the need 
for a heavy-handed differentiated call syntax.

This is not relying upon tooling, it is allowing tooling to do what it is 
supposed to: augment the development experience in accordance with a 
developer’s needs.


> 
> Yes, IMO such code should be second class citizen in Swift.
> 
> AnyObject's dynamic calls are not available on Linux, so their existence for 
> apple platforms is just a required feature to talk to ObjC runtime, with 
> headers\annotations for available methods/props, tooling supports. So IMO we 
> can't make our decisions regarding "true" dynamic code design based on how 
> AnyObject's semi-dynamic calls are designed, IMO they are two separate things.
> 
> Vladimir.
> 
>> I'm sure it's true that people coming from a background in a dynamic 
>> language will initially write "bad" Swift code. When I first started writing 
>> Python, I wrote it like Swift/Objective-C/Bash. But eventually I learned 
>> more of the common idioms in Python and rewrote my code to use those idioms. 
>> This is a bridge to allow easy access to the vast number of libraries that 
>> currently exist in those dynamic language domains, and to ease the 
>> transition of the multitudes of those programmers into Swift.
>> From everything I've seen in the Swift community so far, I have faith that 
>> we collectively won't abuse this feature to the point that it poisons what 
>> Swift has achieved so far. And I'm not against some type of "guardrails" 
>> that help prevent unintentional misuse, but I'd like for it not to be so 
>> much as to be punishing to those that want to make use of the proposed 
>> features.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

Re: [swift-evolution] Enums and Source Compatibility

[Christopher Kornher via swift-evolution]

> On Sep 17, 2017, at 5:04 PM, BJ Homer <bjho...@gmail.com> wrote:
> 
> Please note that, as proposed, enums are always treated as exhaustive *within 
> the same module*. A new user writing MyFirstEnum is likely using it within 
> the same module, and will thus get exhaustive behavior with no extra keywords 
> required.

• What is your evaluation of the proposal?
Uh, +1

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

Apologies for wasting everyone’s time...

> -BJ
> 
> On Sep 17, 2017, at 3:20 PM, Christopher Kornher via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>>> On Sep 17, 2017, at 6:33 AM, Rod Brown via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>>> On 17 Sep 2017, at 4:35 am, Christopher Kornher <ckorn...@me.com 
>>>> <mailto:ckorn...@me.com>> wrote:
>>>> 
>>>>> On Sep 16, 2017, at 11:28 AM, Christopher Kornher via swift-evolution 
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>> 
>>>>> If a library writer can’t remember to declare non-exhaustive enums as 
>>>>> such, they probably will forget many more important aspects of creating a 
>>>>> library. They probably should not be writing libraries. Arguments like 
>>>>> this make sense on the surface, but creating libraries involves hundreds 
>>>>> or thousands of decisions. I wish you luck in making that process idiot 
>>>>> proof. A library linter could easily warn that exposed enums are 
>>>>> exhaustive. The exhaustive keyword should be optional to make the 
>>>>> decision obvious and suppress warnings. Complicating the user experience 
>>>>> in a vain attempt to make “expert" coding safer is misguided.
>>> 
>>> I think the same logic goes both ways: If a library author can’t remember 
>>> to declare exhaustive enums as such, they will probably forget many more 
>>> important aspects of creating a library.
>>> 
>>> The problem here is fundamental: Exhaustive is a guarantee. A guarantee 
>>> should require action. Non-Exhaustive guarantees nothing. It makes you 
>>> safer. That is all.
>> 
>> 1) Exhaustive enums are inherently better: they allow a developer to know 
>> that they have covered all possible cases by not using a default.
>> 2) This proposal forces developers to add a keyword to get this behavior in 
>> their apps, which is common to all other languages with enums that I have 
>> used. This proposal breaks the model common to all (?) current 
>> implementations of enums. 
>> 
>> 
>>> 
>>>> 
>>>> This may be a little harsh, but there don’t seem to be many advocates for 
>>>> novice and “ordinary” application developers on this list. That is not 
>>>> unexpected given the number of extremely knowledgeable compiler and 
>>>> library developers on this list (for whom I have the highest respect). I 
>>>> believe that there are more creative (and probably more difficult to 
>>>> build) possible solutions to some of the tough problems in Swift’s future. 
>>>> In that spirit, see below.
>>> 
>>> I personally am an “ordinary” application developer.
>>> 
>>> I think the issue here is that everyone is seeing Swift as *they* intend to 
>>> use it. For App Devs, exhaustive switches are nice, which means they really 
>>> are fighting tooth and nail to keep them. I understand that. But I’m also 
>>> trying to keep my mind open for “what happens to an app I compiled in iOS 
>>> 15 that I compiled for iOS 11?” And this gives me pause. I can’t ask Apple 
>>> or any other library author to be completely knowledgable about every case 
>>> in the future, and to audit every line of code and manually give 
>>> non-exhaustive.
>>> 
>>> Why do people want “exhaustive” to be the default?
>>> Because we like things as they are.
>> 
>> No, because it makes sense to make common things easy and uncommon things 
>> possible. 
>> 
>>> Because we like not having to consider edge cases. Because we want to 
>>> imagine that will give framework developers the control to make our lives 
>>> difficult because they’ll just be lazy and make our lives hard by not 
>>> annotating. And thi

Re: [swift-evolution] Enums and Source Compatibility

[Christopher Kornher via swift-evolution]

> On Sep 16, 2017, at 11:28 AM, Christopher Kornher via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
>> 
>> On Sep 16, 2017, at 8:41 AM, Rod Brown via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> On 16 Sep 2017, at 7:22 pm, Goffredo Marocchi via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> I am still unsure why we are choosing again a default that protects library 
>>> writers more than library users where it is reasonable to expect the former 
>>> to have better mastery of the language, to architect a library with some 
>>> scalability, and ability to add unit test to cover themselves from issues 
>>> than the latter.
>> 
>> Because protecting library owners protects library users.
> 
> If a library writer can’t remember to declare non-exhaustive enums as such, 
> they probably will forget many more important aspects of creating a library. 
> They probably should not be writing libraries. Arguments like this make sense 
> on the surface, but creating libraries involves hundreds or thousands of 
> decisions. I wish you luck in making that process idiot proof. A library 
> linter could easily warn that exposed enums are exhaustive. The exhaustive 
> keyword should be optional to make the decision obvious and suppress 
> warnings. Complicating the user experience in a vain attempt to make “expert" 
> coding safer is misguided.

This may be a little harsh, but there don’t seem to be many advocates for 
novice and “ordinary” application developers on this list. That is not 
unexpected given the number of extremely knowledgeable compiler and library 
developers on this list (for whom I have the highest respect). I believe that 
there are more creative (and probably more difficult to build) possible 
solutions to some of the tough problems in Swift’s future. In that spirit, see 
below.

> 
> 
>> 
>> If you declare it is exhaustive and it was an oversight, and then realise 
>> after the fact that you are wrong, you have to open it up. This will break 
>> third party apps. It will be disallowed by the ABI compatibility 
>> requirements.
>> 
>> If you declare it isn’t exhaustive due to an oversight (or perhaps you’re 
>> just not sure yet), and then realise after the fact it is exhaustive, you 
>> can close it up. This will not break third party apps. It will also be 
>> allowed for ABI compatibility.
>> 
>> This benefits everyone. Make library owners choose a guarantee, rather than 
>> be defaulted into it. Much like they have to declare choose to declare 
>> “final” on a class: you can’t retroactively reneg that promise: it will 
>> break everyone who assumed it to be the case!
> 
> It does not benefit the creation of 90+% of enums. It is one more arcane rule 
> for the vast majority of developers.

The Swift compiler could offer a “strict enum exhaustiveness” (bikeshedding not 
included) switch that could be enabled by default for library targets and 
disabled by default for “application” targets. The switch would make not 
explicitly specifying exhaustiveness an error or warning when enabled. Perhaps 
this could be combined with other options that would tailor the development 
experience for library/application developers. This would help avoid “zero-sum” 
choices between benefitting library or application developers in the future.

Xcode and the SPM should be able to distinguish between the target types and 
generate the proper defaults. I do not believe that this is too mysterious for 
developers. There would be learning step for developers wiring their first 
library, but that is not necessarily a bad thing since creating a reusable 
library requires a different mindset than creating an application.


> 
>> 
>>> 
>>> Exhaustive and open by default with keywords to close things down if the 
>>> framework author wants them.
>>> 
>>> Sent from my iPhone
>>> 
>>> On 16 Sep 2017, at 09:55, David Hart via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> I’m still very much bothered by having 2 new keywords. I would really 
>>>> prefer the following plan:
>>>> 
>>>> Exhaustive by default in Swift 4
>>>> No new keyword in Swift 4 to change that behaviour
>>>> Non-exhaustive by default outside the module in Swift 5
>>>> exhaustive keyword to change the default behaviour
>>>> 
>>>> Like that, we don’t need nonexhaustive.
>>>> 
>>>> Tho

Re: [swift-evolution] Enums and Source Compatibility

[Christopher Kornher via swift-evolution]

> On Sep 16, 2017, at 8:41 AM, Rod Brown via swift-evolution 
>  wrote:
> 
> 
> On 16 Sep 2017, at 7:22 pm, Goffredo Marocchi via swift-evolution 
> > wrote:
> 
>> I am still unsure why we are choosing again a default that protects library 
>> writers more than library users where it is reasonable to expect the former 
>> to have better mastery of the language, to architect a library with some 
>> scalability, and ability to add unit test to cover themselves from issues 
>> than the latter.
> 
> Because protecting library owners protects library users.

If a library writer can’t remember to declare non-exhaustive enums as such, 
they probably will forget many more important aspects of creating a library. 
They probably should not be writing libraries. Arguments like this make sense 
on the surface, but creating libraries involves hundreds or thousands of 
decisions. I wish you luck in making that process idiot proof. A library linter 
could easily warn that exposed enums are exhaustive. The exhaustive keyword 
should be optional to make the decision obvious and suppress warnings. 
Complicating the user experience in a vain attempt to make “expert" coding 
safer is misguided.


> 
> If you declare it is exhaustive and it was an oversight, and then realise 
> after the fact that you are wrong, you have to open it up. This will break 
> third party apps. It will be disallowed by the ABI compatibility requirements.
> 
> If you declare it isn’t exhaustive due to an oversight (or perhaps you’re 
> just not sure yet), and then realise after the fact it is exhaustive, you can 
> close it up. This will not break third party apps. It will also be allowed 
> for ABI compatibility.
> 
> This benefits everyone. Make library owners choose a guarantee, rather than 
> be defaulted into it. Much like they have to declare choose to declare 
> “final” on a class: you can’t retroactively reneg that promise: it will break 
> everyone who assumed it to be the case!

It does not benefit the creation of 90+% of enums. It is one more arcane rule 
for the vast majority of developers.

> 
>> 
>> Exhaustive and open by default with keywords to close things down if the 
>> framework author wants them.
>> 
>> Sent from my iPhone
>> 
>> On 16 Sep 2017, at 09:55, David Hart via swift-evolution 
>> > wrote:
>> 
>>> I’m still very much bothered by having 2 new keywords. I would really 
>>> prefer the following plan:
>>> 
>>> Exhaustive by default in Swift 4
>>> No new keyword in Swift 4 to change that behaviour
>>> Non-exhaustive by default outside the module in Swift 5
>>> exhaustive keyword to change the default behaviour
>>> 
>>> Like that, we don’t need nonexhaustive.
>>> 
>>> Thoughts?
>>> David.
>>> 
 On 13 Sep 2017, at 21:16, Jordan Rose via swift-evolution 
 > wrote:
 
 Proposal updated, same URL: 
 https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md
  
 .
 
 Thanks again for all the feedback so far, everyone!
 Jordan
 
 
> On Sep 12, 2017, at 17:55, Jordan Rose via swift-evolution 
> > wrote:
> 
> Sorry, I got distracted by other tasks! Both the discussion here and 
> within Apple has moved towards making "non-exhaustive" the default, 
> which, to be honest, I too think is the best design. I'll update the 
> proposal today to reflect that, though I still want to keep both the 
> "nonexhaustive" and "exhaustive" keywords for Swift 4 compatibility for 
> now (or whatever we end up naming them). The compatibility design is a 
> little less ambitious than Brent's; as currently proposed, Swift 4 mode 
> continues to default to 'exhaustive' all the time, even in the actual 
> Swift 5 release.
> 
> I still want to respond to Brent's points directly, but I think you and 
> Vladimir have done a good job discussing them already. I'll send out the 
> updated proposal tomorrow, after I have a little more time to think about 
> #invalid.
> 
> Thanks for putting time into this!
> Jordan
> 
> 
>> On Sep 9, 2017, at 17:34, Rod Brown > > wrote:
>> 
>> Jordan,
>> 
>> Do you have any other thoughts about the ongoing discussion here, 
>> especially regarding Chris’ comments? As you’re the one pushing this 
>> forward, I’d really like to know what your thoughts are regarding this?
>> 
>> - Rod
> 
> ___
> swift-evolution 

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

[Christopher Kornher via swift-evolution]

> On Sep 9, 2017, at 12:36 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On Sep 9, 2017, at 11:42 AM, gs.  > wrote:
> 
>> How does fragility play into this? Does this only work for fragile (closed) 
>> and internal/private/fileprivate enums?
> 
> That's a great question.  I think it would have to have that limitation.  
> Using Jordan's terminology, by definition a nonexhaustive cannot provide a 
> complete list of all values.

The runtime “knows” (or could be made to know) all the cases at any given 
moment in time (ignoring runtime-loaded modules, should they ever be 
supported). This is actually a strong argument for the creation of this 
feature. It would be impossible for such a list to be maintained manually. 
Making the list available somehow at compile time would almost guarantee a 
source-breaking/ABI-breaking change in the future.  This raises a question: 
would models want anything other than the complete list of cases at runtime? 
For example, the module containing the root enum may have a use for the cases 
just defined within that module. I propose that the feature be defined to 
include all cases at runtime and that discussions of partial lists of cases be 
deferred until a use is found for them.

> 
>> 
>> TJ 
>> 
>> On Sep 9, 2017, at 15:23, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>> On Sep 9, 2017, at 7:33 AM, Brent Royal-Gordon >> > wrote:
>>> 
> On Sep 8, 2017, at 5:14 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> 
> Here, people just want an array of all cases. Give them an array of all 
> cases. When it's not possible (i.e., in the case of cases with associated 
> values), don't do it.
 
 
 I agree it should be Int-indexed; that seems to be what people want from 
 this.
 
 I seem to recall that there is information about the available enum cases 
 in the module metadata. If so, and if we're willing to lock that in as 
 part of the ABI design, I think we should write—or at least allow for—a 
 custom Int-indexed collection, because this may allow us to recurse into 
 associated value types. If we aren't going to have suitable metadata, 
 though, I agree we should just use an Array. There are pathological cases 
 where instantiating a large Array might be burdensome, but sometimes you 
 just have to ignore the pathological cases.
 
 (The "infinite recursion" problem with associated values is actually 
 relatively easy to solve, by the way: Don't allow, or at least don't 
 generate, `ValuesEnumerable` conformance on enums with `indirect` cases.)
>>> 
>>> This is the direction I think makes the most sense in terms of how we 
>>> should approach synthesis.  The open question in my mind is what the exact 
>>> requirement of the protocol should be.  Should it exactly match what we 
>>> synthesize (`[Self]` or an associated `Collection where Iterator.Element == 
>>> Self, Index == Int`) or whether the protocol should have a more relaxed 
>>> requirement of `Sequence where Iterator.Element == Self` like Tony proposed.
>>> 
 
 -- 
 Brent Royal-Gordon
 Architechies
 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

[Christopher Kornher via swift-evolution]

Apologies for rehashing this, but we seem to be going down that path… I am in 
the minority on this issue and have held my opinions because I thought that 
they would have served as simply a distraction and I was extremely busy at the 
time. That may have been a mistake on my part, because raising these issues now 
is after the fact.

I am airing them now for two reasons:
1) To ensure that at least the agreed upon compromise is implemented.
2) To hopefully improve the evolution process, and help ensure that similar 
proposals are given the scrutiny that they deserve.

I have noticed a pattern in software and other projects over the years. The 
most catastrophic failures and expensive rework has been due to flawed or at 
least incomplete basic assumptions. New postulates / basic assumptions should 
be subjected to rigorous scrutiny. I don’t think that they were in this case.

I am speaking up now because there is a proposal out there to follow what I 
consider to be a flawed basic assumption to its logical conclusion, which seems 
quite reasonable, if you accept the basic assumption, which I don’t, of course. 

Please don’t take this as a personal attack on those on the other side. This is 
a philosophical disagreement with no “right” and “wrong” answer. I don’t 
believe that this proposal is terrible. In fact, the agreed-upon compromise 
does improve the construction and matching of enum values and leaves only edge 
cases that I hope to address in a future proposal — specifically matching is 
made more difficult in some cases of name overloading. 

The history of the process as I saw it:
There was a widely perceived problem with enums involving what could be 
described as “legacy destructuring” which could lead to confusing code and hard 
to discover transposition errors.

A solution was proposed that was based upon an overarching premise: 
that enums should be modeled as much as possible after function calls to 
simplify the language. This led to the original proposal always requiring 
labels (as function calls do, and closures don’t, but that is a discussion for 
another time).

I believe that idea of using function calls as the primary model for enums is 
flawed at its core. The problem is that enums and function calls only resemble 
each other in Swift because some enums can have associated values. 

The purpose of enums is to be matched. Enums that are never matched in some way 
have no purpose. Function calls must always be “matched” (resolved) 
unambiguously so that proper code can be executed. No such requirement exists 
for enums. In fact the language includes rich functionality for matching 
multiple cases and values with a single “case” (predicate). This is not a flaw, 
it improves the expressive power of the language by allowing complex matching 
logic to be expressed tersely and clearly.

So, since the purpose of enums is to be matched, any modification to this 
accepted proposal that makes that more difficult or cluttered should be 
rejected.


> On Sep 4, 2017, at 9:52 AM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> While re-litigating has it's issues, I am for simplifying the rule and always 
> requiring the labels if they exist. This is similar to the change around 
> external labels. Yes, it is slightly less convenient, but it removes a 
> difficult to motivate caveat for beginners.
> 
> On Sun, Sep 3, 2017 at 4:35 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> The desired behavior was the major topic of controversy during review; I’m 
> wary of revisiting this topic as we are essentially relitigating the proposal.
> 
> To start off, the premise, if I recall, going into review was that the author 
> **rejected** the notion that pattern matching should mirror creation. I 
> happen to agree with you on this point, but it was not the prevailing 
> argument. Fortunately, we do not need to settle this to arrive at some 
> clarity for the issues at hand.
> 
> From a practical standpoint, a requirement for labels in all cases would be 
> much more source-breaking, whereas the proposal as it stands would allow 
> currently omitted labels to continue being valid. Moreover, and I think this 
> is a worthy consideration, one argument for permitting the omission of labels 
> during pattern matching is to encourage API designers to use labels to 
> clarify initialization without forcing its use by API consumers during every 
> pattern matching operation.
> 
> In any case, the conclusion reached is precedented in the world of functions:
> 
> func g(a: Int, b: Int) { ... }
> let f = g
> f(1, 2)
> 
> On Sun, Sep 3, 2017 at 15:13 Robert Widmann via swift-evolution 
> > wrote:
> Hello Swift Evolution,
> 
> I took up the cause of implementing SE-0155 
> 

Re: [swift-evolution] Two thoughts on concurrency

[Christopher Kornher via swift-evolution]

I don’t think that there are any simple rules that define “Complexity”. I hope 
that is not too off-topic...

https://www.edwardtufte.com/tufte/books_vdqi
>

It makes sense to make a distinction between adding keywords/modifiers to 
implement a niche feature and implementing fairly well established abstractions 
like "async/await" and “actor”. There should be a lower bar to using well 
established terms if the implementation is faithful to standard (and “modern”) 
usage. Swift does not exist in isolation, but in world where developers 
commonly use multiple languages. The notion of progressive disclosure is 
mentioned as being very important to the design to Swift and a lot of code can 
be written in Swift without ever needing to see "async/await”, so it this 
feature "meets the standard" for progressive disclosure (which probably can be 
more formally defined).

There should be a very high bar to adding keywords to support special cases and 
using common terms in non-standard ways. Of course, there will always be some 
differences in the exact usage of a term in different languages.

It might make sense to create a manifesto-like document of guidelines for 
evolving Swift that would serve as a first test or filter on proposals. The 
danger of creating such a document is that great proposals might fail the test 
“on paper” and be effectively killed.

A small nit: Swift exceptions are (thankfully) kind-of sugar for : `Result` 
not `Result` meaning that Error is a protocol, not a generic 
parameter in Swift standard usage. As I have mentioned (to often already, 
probably) that I believe that whatever benefit `Result` brings is not 
worth the hassle and mismatch with Swift's standard usage of errors. 

> On Aug 24, 2017, at 10:29 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Aug 24, 2017, at 9:17 PM, Félix Cloutier > > wrote:
>> 
>> I feel that it's important to point out that this example feels weird 
>> because even though the compiler doesn't treat "weak" as a reserved term, 
>> most developers perceive it as one. I don't think that David is worried that 
>> we're taking away all the cool words from the realm of identifiers; the 
>> problem is that "technically not a keyword" is a qualifier mostly distinct 
>> from "not perceived as a keyword". Even if attributes don't live in the same 
>> token namespace as identifiers as far as the compiler is perceived, I'd 
>> argue that they add about the same complexity (or more) to the mental model 
>> that developers have to have about the language.
> 
> Obviously details matter here, but there is an important time and place to 
> introduce a “conceptual” keyword: it is when there is an important and 
> distinct concept that needs to be thought about by the humans that interact 
> with the code.
> 
> In the proposal “actor” vs “distributed actor” is one of those really 
> important distinctions, which is why (IMO) it deserves the “complexity” of a 
> new identifier.  It isn’t the identifier that adds the complexity, it is the 
> expansion of the language surface that the identifier designates.
> 
> -Chris
> 
> 
> 
> 
>> Félix
>> 
>>> Le 24 août 2017 à 20:58, Chris Lattner via swift-evolution 
>>> > a écrit :
>>> 
>>> 
 On Aug 24, 2017, at 8:57 PM, Chris Lattner via swift-evolution 
 > wrote:
 
 On Aug 24, 2017, at 1:59 PM, Dave DeLong via swift-evolution 
 > wrote:
> Keyword Explosion
> 
> During the Great Access Control Wars of Swift 4, one of the points that 
> kept coming up was the reluctance to introduce a bazillion new keywords 
> to address all the cases that were being brought up. The impression I got 
> is that adding new keywords was essentially an anti-pattern. And so when 
> I’m reading through this onslaught of emails, I’m troubled by how 
> everything is seeming to require new keywords. There’s the obvious 
> async/await, but there’s also been discussion of actor, reliable, 
> distributed, behavior, message, and signal (and I’ve probably missed 
> others).
 
 I can’t speak for message/signal, but you need to understand a bit more 
 about how Swift works.  There is a distinction between an actual keyword 
 (which ‘async’ would be, and ‘class’ currently is) and “modifiers”.  
 Modifiers occur with attributes ahead of a real keyword, but they are not 
 themselves keywords.  They are things like weak, mutating, reliable, 
 distributed, etc.  If we go with the “actor class” and “actor func” 
 approach, then actor would not be a keyword.
>>> 
>>> Concrete example, this is (weird but) valid code:
>>> 
>>> var weak = 42
>>> weak += 2
>>> print(weak+weak)
>>> 
>>> 

Re: [swift-evolution] typed throws

[Christopher Kornher via swift-evolution]

> On Aug 18, 2017, at 7:38 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> I would like to reiterate the point I made in the question that spawned this 
> thread: there are *many* Swift libraries for writing async code of various 
> sorts which are *already* using typed errors via `Result Error>`.  We don't have to speculate about how this feature might be used and 
> what kind of benefits might be realized.  We can have a discussion about what 
> people are already doing and determine whether this model should be supported 
> in the async / await world or not.  What do you think of putting a call out 
> to the broader Swift community to bring us concrete examples of how they are 
> benefiting from using typed errors in async code.

I have found this “feature" has been painful to use. I have been forced to wrap 
hetrogenous errors in a custom error type just to satisfy these ill-conceived 
APIs. i have never found any benefit to ```ErrorType: Error``` generic 
parameter. … Any. Ever.

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

Re: [swift-evolution] [discussion] Class stored properties?

[Christopher Kornher via swift-evolution]

Class variables are not common, but they are the most natural way to implement 
class-specific functionality. Off the top of my head, I have used class 
variables for:

1) Custom allocation schemes, e.g. pools, LRU implementations
2) Diagnostics, e.g. counting the number of instances of a given class
3) Plugin-in functionality, e.g. customizing behavior of a class at runtime. In 
Swift, the variables would be closures.


You can argue that class variables these are not strictly necessary for these 
tasks, but I have found them to be handy, including during development and 
“Bring-up"

- Chris




> On Aug 9, 2017, at 12:52 PM, Mathew Huusko V via swift-evolution 
>  wrote:
> 
> I don't follow. What's a singleton/how? If you mean my example, the whole 
> point/need for the feature is so it's not. I want `.value` to be unique 
> storage for each subclass.
> 
> On Wed, Aug 9, 2017 at 7:09 PM, Robert Widmann  > wrote:
> This is a singleton, it just happens to be in class scope.
> 
> ~Robert Widmann
> 
> > On Aug 9, 2017, at 3:55 AM, Mathew Huusko V via swift-evolution 
> > > wrote:
> >
> > Curious if class stored properties have ever been discussed (doesn't seem 
> > so..)?
> >
> > Also, assuming no, and assuming there's a good reason no/they're not coming 
> > anytime soon, what are some patterns people have been using in their place? 
> > I was considering something like..
> >
> > class SomeClass {
> > private static var _classValues = [SomeClass.Type: Int]()
> >
> > class var value: Int {
> > get { _classValues[self] }
> > set { _classValues[self] = newValue }
> > }
> > }
> >
> > .. but then I remembered types aren't hashable yet either (so I guess I 
> > need to stringify it first).
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org 
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

[Christopher Kornher via swift-evolution]

I have always found it curious that extensions cannot be named. Since same-file 
extension are considered to be superior to comments as a way of separating 
concerns, wouldn’t it make sense to allow naming of extensions? Extension names 
could possibly be included in symbols for entities in the extension, giving a 
clue as to the reason for the extension, perhaps. Tools with access to 
extension names could automatically provide a richer programming environment, 
without relying upon comments.

Unique names for extensions to protocols and classes would open the door to the 
ability to selectively suppress some extensions when importing a module, which 
might be very valuable in complex code bases with name collisions, for example. 
This can be a real problem for extensions to built-in and foundation types.

Objective C requires inclusion of category headers, thus allowing code to 
manage “extension” (category) namespaces implicitly.

This seem to be an intensional omission of the part of the core team, but I 
have never heard the rationale for it. In the case of protocol conformance 
extensions, a name would probably be redundant, so it would sensible to default 
the name to the protocol(s) being implemented. Names would have to be optional 
for backward compatibility. 

- Chris



> On Aug 2, 2017, at 9:57 AM, Taylor Swift via swift-evolution 
>  wrote:
> 
> I don’t understand how extensions help with code locality. It’s literally a 
> matter of curly braces. I already glue the extension block to the bottom } of 
> the protocol block anyway by omitting the empty linebreak.
> 
> protocol Protocol
> {
> func default_function()
> }
> extension Protocol
> {
> func default_function()
> {
> }
> }
> 
> as opposed to 
> 
> protocol Protocol
> {
> func default_function()
> {
> }
> }
> 
> I would very much appreciate not having to retype Protocol and 
> default_function() over and over. The whole cult-of-same-file-extensions 
> seems to be people refusing to let go of old C++ habits. Have you noticed 
> that nowhere else in Swift is there a concept of separating type declarations 
> from type definitions? That’s because people managed to figure out that 
> typing the same words over and over again doesn’t actually keep code neater 
> at all.
> 
> On Wed, Aug 2, 2017 at 11:27 AM, Gor Gyolchanyan 
> > wrote:
> 
>> On Aug 2, 2017, at 6:15 PM, Taylor Swift > > wrote:
>> 
>> I agree with this, extensions on types defined in the same file are 
>> generally silly, and default implementations belong in the protocol body. I 
>> don’t agree with certain style guides prescription of same-file extensions; 
>> they should only be used to hide protocol conformances that are 
>> “unimportant” to the functionality of the type. In practice this means only 
>> conformances like CustomStringConvertible and CustomDebugStringConvertible 
>> live in extensions.
>> 
>> If you want to group related methods, use linebreaks and whitespace for 
>> that. Don’t split up the type braces since that messes up the whole 
>> one-set-of-braces == one type definition visual rule.
>> 
>> The only time it ever makes sense to extend a non concrete type that you own 
>> is when adding conditional default implementations. Having to extend a bare 
>> protocol is the product of a language limitation.
> 
> Take a look at my replies to Tino Heth about code locality and the rest...
> 
>> On Wed, Aug 2, 2017 at 6:26 AM, Tino Heth via swift-evolution 
>> > wrote:
>> 
>>> That would work as well, but it has the downside of forcing a potentially 
>>> huge number of methods to be implemented in a single place, reducing the 
>>> readability as opposed to packing them into semantically related groups in 
>>> the form of extensions.
>> 
>> I really don't get why people are so obsessed with same-file extensions:
>> They are recommended in style guides, influencers blog about them, and they 
>> motivated a ridiculous complex change in the access rights system. Yet I 
>> haven't seen any evidence that they offer real benefit.
>> Extensions are great for adding useful helpers to existing types, and still 
>> allow you to selectively expose details of your own classes — but most 
>> people seem to ignore those options and focus on something can be done 
>> better with plain old comments.
>> [sorry for the rant — but I think a critical look at extensions is long 
>> overdue: I rarely see someone questioning their role, so basically, we are 
>> making important decisions based on pure superstition]
>> 
>> A protocol itself is already a vehicle to group related methods, and if you 
>> have a huge entity, it doesn't get better just because you split it and hide 
>> its complexity.
>> 
>>> Also, please include the original message for reference 

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Christopher Kornher via swift-evolution]

I am not sure that macros and annotations would be good, either. It may be 
impossible to avoid them, given Swift’s goal of “world domination”. Both 
features are very useful in certain applications.

We could continue to use custom tools like Cog and Sourcery when we need to, or 
standardize and better integrate their functionality. I honestly am not sure 
which is a better solution.

"Hygienic Macros” and “Annotations” have both been discussed. Both of these 
features would bring power and complexity to the language, to be sure. I just 
wanted to voice my opinion that these features, if and when they arrive, should 
be transparent, i.e., the generated code should be visible and sensibly 
formatted so that it can be examined and debugged. This would be a hard 
problem, and I am not sure if it is even possible for complex macro & 
annotation combinations…

C macros are not hygienic and not “transparent”. C preprocessor output, for 
example, is largely unusable.

The uses of macros and annotation overlap. Introducing macros and annotations 
at the same time would provide a chance to sensibly balance the features of 
each and provide a coherent set of guidelines for developers. 

- Chris K

> On Jul 30, 2017, at 12:03 PM, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> I don’t think a Cog-like or Gyb-like macro system would be good. That’s 
> essentially a preprocessor and we all know how that worked out for C. The 
> only a code-generation feature can exist in a safe language like Swift is by 
> making it a first-class citizen as described previously. I’m not sure whether 
> or not the core team would consider such a thing, bit I am very certain that 
> a text-based macro system is something they’d never consider.
> 
>> On Jul 30, 2017, at 8:54 PM, Christopher Kornher > > wrote:
>> 
>> I assume that the planned “hygienic macro” facility, if it has access to 
>> metadata, or “annotations", could be used for these sorts of meta tasks, .
>> 
>> This is slightly off-topic, but I hope that there is a way for macros to be 
>> fully expanded and debuggable (and even formatted). I use Cog with Swift as 
>> a kind of "macro-system on steroids” that provides these features. I would 
>> love to see a Cog-like system included as a standard feature of the language 
>> in the future. It could be a component of annotations, macros, or both.
>> 
>> I would like to see a source code generation pre-pass added for annotations, 
>> and hopefully macros when they arrive, so that developers can see, debug, 
>> and code against the expanded code. I realize that may be difficult or even 
>> impossible for some macros.
>> 
>> GOG uses Python as its macro language, which is certainly compatible with 
>> Apple’s toolchain. Using a real programming language for annotations, is 
>> extremely powerful.
>> 
>> The danger of adding a macro system too early, is that it can be used as a 
>> “cheat” to implement functionality that should be part of the base language 
>> and discourage language development. I trust that the core team will not let 
>> this happen.
>> 
>> See Cog: 
>> https://nedbatchelder.com/code/cog/ 
>> 
>> A fully integrated Cog-like facility this should have language support to 
>> cleanup the (pretty ugly) delimiters and eventually tool support to 
>> selectively toggle expansion, as we can today with code blocks, for example, 
>> in many tools.
>> 
>> I don’t mean to derail this discussion, but it seems that an annotation or 
>> macro system would be appropriate for this kind of feature.
>> 
>> - Chris
>> 
>> 
>>> On Jul 30, 2017, at 11:03 AM, Gor Gyolchanyan via swift-evolution 
>>> > wrote:
>>> 
>>> Tino Heth:
>>> If you read my reply to Daniel Vollmer, you’ll find that we’re thinking 
>>> about the exact same thing. Your code snippers show my vision of 
>>> compiletime beautifully .
>>> Now what I really want at this point is to here the opinions of the core 
>>> team on this topic.
>>> 
>>> Swift Core Team:
>>> Have you guys thought of this? Do you think this is a good idea to put on 
>>> the table or do you have different plans?
>>> 
 On Jul 30, 2017, at 7:56 PM, Tino Heth <2...@gmx.de > 
 wrote:
 
 
> more elaborate compile-time facilities, which would also provide 
> extremely powerful meta programming features
 That's an interesting twist — but whenever you put a "meta" somewhere, 
 things tend to get complicated, and people end up with different 
 associations to the topic… ;-)
 I took a brief look at the C++ document, but it seemed still to much 
 macro-like to me.
 
 My take on the topic would be he ability to express common programming 
 tasks (declaring a class, overriding a method…) in the language itself.
 Imagine
 public class ProxyViewController: 

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Christopher Kornher via swift-evolution]

For completeness: I forgot to mention that I have been meaning to check-out 
Sourcery, which is possibly a more “Swifty” tool. I use Cog’s file-scope 
extensively, and it is unclear to me if that is a feature of Sourcery

https://github.com/krzysztofzablocki/Sourcery

OK, now I am sure that someone is going to tell me that I am off-topic :)

- Chris K

> On Jul 30, 2017, at 11:54 AM, Christopher Kornher  wrote:
> 
> I assume that the planned “hygienic macro” facility, if it has access to 
> metadata, or “annotations", could be used for these sorts of meta tasks, .
> 
> This is slightly off-topic, but I hope that there is a way for macros to be 
> fully expanded and debuggable (and even formatted). I use Cog with Swift as a 
> kind of "macro-system on steroids” that provides these features. I would love 
> to see a Cog-like system included as a standard feature of the language in 
> the future. It could be a component of annotations, macros, or both.
> 
> I would like to see a source code generation pre-pass added for annotations, 
> and hopefully macros when they arrive, so that developers can see, debug, and 
> code against the expanded code. I realize that may be difficult or even 
> impossible for some macros.
> 
> GOG uses Python as its macro language, which is certainly compatible with 
> Apple’s toolchain. Using a real programming language for annotations, is 
> extremely powerful.
> 
> The danger of adding a macro system too early, is that it can be used as a 
> “cheat” to implement functionality that should be part of the base language 
> and discourage language development. I trust that the core team will not let 
> this happen.
> 
> See Cog: 
> https://nedbatchelder.com/code/cog/ 
> 
> A fully integrated Cog-like facility this should have language support to 
> cleanup the (pretty ugly) delimiters and eventually tool support to 
> selectively toggle expansion, as we can today with code blocks, for example, 
> in many tools.
> 
> I don’t mean to derail this discussion, but it seems that an annotation or 
> macro system would be appropriate for this kind of feature.
> 
> - Chris
> 
> 
>> On Jul 30, 2017, at 11:03 AM, Gor Gyolchanyan via swift-evolution 
>> > wrote:
>> 
>> Tino Heth:
>> If you read my reply to Daniel Vollmer, you’ll find that we’re thinking 
>> about the exact same thing. Your code snippers show my vision of compiletime 
>> beautifully .
>> Now what I really want at this point is to here the opinions of the core 
>> team on this topic.
>> 
>> Swift Core Team:
>> Have you guys thought of this? Do you think this is a good idea to put on 
>> the table or do you have different plans?
>> 
>>> On Jul 30, 2017, at 7:56 PM, Tino Heth <2...@gmx.de > 
>>> wrote:
>>> 
>>> 
 more elaborate compile-time facilities, which would also provide extremely 
 powerful meta programming features
>>> That's an interesting twist — but whenever you put a "meta" somewhere, 
>>> things tend to get complicated, and people end up with different 
>>> associations to the topic… ;-)
>>> I took a brief look at the C++ document, but it seemed still to much 
>>> macro-like to me.
>>> 
>>> My take on the topic would be he ability to express common programming 
>>> tasks (declaring a class, overriding a method…) in the language itself.
>>> Imagine
>>> public class ProxyViewController: UIView {}
>>> Could be written as
>>> let subclass = createClass(classname: "ProxyViewController", superclass: 
>>> UIViewController, accessLevel: .public)
>>> 
>>> Quite stupid at first sight, and basically the exact opposite of syntactic 
>>> sugar ("syntactic salt" already has a meaning… so I'd call it "syntactic 
>>> pepper" ;-).
>>> But now imagine that:
>>> 
>>> for (method, implementation) in UIViewController.methods where 
>>> method.accessLevel == .open {
>>> subclass.methods[method] = { parameters in
>>> print("Subclass method \(method) called with \(parameters)")
>>> return implementation(parameters)
>>> }
>>> }
>>> 
>>> 
>>> Not that stupid anymore, isn't it?
>>> I think this would be way cooler than poking around with variants of search 
>>> & replace…
>>> 
>>> - Tino
>>> 
>>> (to get syntax colouring, I wrote ~30 lines of Swift that turn the straw 
>>> man example into valid code… it's fun, maybe I play with it a little bit 
>>> more ;-)
>> 
>> ___
>> 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] [Planning][Request] "constexpr" for Swift 5

[Christopher Kornher via swift-evolution]

I assume that the planned “hygienic macro” facility, if it has access to 
metadata, or “annotations", could be used for these sorts of meta tasks, .

This is slightly off-topic, but I hope that there is a way for macros to be 
fully expanded and debuggable (and even formatted). I use Cog with Swift as a 
kind of "macro-system on steroids” that provides these features. I would love 
to see a Cog-like system included as a standard feature of the language in the 
future. It could be a component of annotations, macros, or both.

I would like to see a source code generation pre-pass added for annotations, 
and hopefully macros when they arrive, so that developers can see, debug, and 
code against the expanded code. I realize that may be difficult or even 
impossible for some macros.

GOG uses Python as its macro language, which is certainly compatible with 
Apple’s toolchain. Using a real programming language for annotations, is 
extremely powerful.

The danger of adding a macro system too early, is that it can be used as a 
“cheat” to implement functionality that should be part of the base language and 
discourage language development. I trust that the core team will not let this 
happen.

See Cog: 
https://nedbatchelder.com/code/cog/ 

A fully integrated Cog-like facility this should have language support to 
cleanup the (pretty ugly) delimiters and eventually tool support to selectively 
toggle expansion, as we can today with code blocks, for example, in many tools.

I don’t mean to derail this discussion, but it seems that an annotation or 
macro system would be appropriate for this kind of feature.

- Chris


> On Jul 30, 2017, at 11:03 AM, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> Tino Heth:
> If you read my reply to Daniel Vollmer, you’ll find that we’re thinking about 
> the exact same thing. Your code snippers show my vision of compiletime 
> beautifully .
> Now what I really want at this point is to here the opinions of the core team 
> on this topic.
> 
> Swift Core Team:
> Have you guys thought of this? Do you think this is a good idea to put on the 
> table or do you have different plans?
> 
>> On Jul 30, 2017, at 7:56 PM, Tino Heth <2...@gmx.de > 
>> wrote:
>> 
>> 
>>> more elaborate compile-time facilities, which would also provide extremely 
>>> powerful meta programming features
>> That's an interesting twist — but whenever you put a "meta" somewhere, 
>> things tend to get complicated, and people end up with different 
>> associations to the topic… ;-)
>> I took a brief look at the C++ document, but it seemed still to much 
>> macro-like to me.
>> 
>> My take on the topic would be he ability to express common programming tasks 
>> (declaring a class, overriding a method…) in the language itself.
>> Imagine
>> public class ProxyViewController: UIView {}
>> Could be written as
>> let subclass = createClass(classname: "ProxyViewController", superclass: 
>> UIViewController, accessLevel: .public)
>> 
>> Quite stupid at first sight, and basically the exact opposite of syntactic 
>> sugar ("syntactic salt" already has a meaning… so I'd call it "syntactic 
>> pepper" ;-).
>> But now imagine that:
>> 
>> for (method, implementation) in UIViewController.methods where 
>> method.accessLevel == .open {
>> subclass.methods[method] = { parameters in
>> print("Subclass method \(method) called with \(parameters)")
>> return implementation(parameters)
>> }
>> }
>> 
>> 
>> Not that stupid anymore, isn't it?
>> I think this would be way cooler than poking around with variants of search 
>> & replace…
>> 
>> - Tino
>> 
>> (to get syntax colouring, I wrote ~30 lines of Swift that turn the straw man 
>> example into valid code… it's fun, maybe I play with it a little bit more ;-)
> 
> ___
> 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] Fwd: [Pitch] Guard/Catch

[Christopher Kornher via swift-evolution]

es, so they shouldn't be collapsed in a 
single call:


guard let x = try doSomething() catch { /// handle and return }
guard let x = x else { /// handle and return }


Also, if a function returns something like "Int??", a guard-let (or if-let) on 
the returned value of that function will still bind an "Int?", thus unwrapping 
only "one level" of optional. If-let and guard-let, as of today, just unwrap a 
single optional level, an do not guaranteed at all that the bound value is not 
optional.

To me guard-let (like if-let) is basically sugar for monadic binding for 
Optionals, with the additional expressivity granted by the forced return. I 
would love to see the same monadic binding structure applied to throwing 
functions.



Elviro




___
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
> Il giorno 09 lug 2017, alle ore 01:16, Christopher Kornher via 
> swift-evolution <swift-evolution@swift.org 
> <mailto:swift-evolution@swift.org>> ha scritto:
> 
> Thanks for you considerate reply. My concern over the proliferation of “sugar 
> proposals” is a general one. This proposal has more merit and general 
> utiliity than many others. I have never used a throwing function in a guard 
> statement that was not itself in a throwing function, but I can see that it 
> could possibly be common in some code. Wrapping a guard statement and all the 
> code that uses variables set in the guard in a do/catch is sub-optimal.
> 
> 
> All catches don’t have to exit the outer scope, so using guard only handles a 
> subset 
> 
> It think that creating the terse try/catch for simple cases has multiple 
> advantages:
> 
>   1) I think that it addresses your desire for a simple way to use 
> throwing functions easily in guard statements.
> 
>   2) It avoids having to change the guard syntax to accomplish this
> 
>   3) It is useful for handling simple one line try/catch constructs in 
> less space in a way that should not seem too foreign to Swift developers.
>   
>   4) It simplifies code that currently uses nested do/try/catch 
> constructs. Even though this is rare, it introduces significant “rightward 
> drift”.
> 
>   5) It can used to return early from void throwing functions easily. 
> e.g. : 
> 
>   ```
>   ```
>   
>   Multiple void throwing functions would probably be better handled by a 
> do/catch block, but there is no danger of needing values from these functions 
> because there are none:
> 
>   ```
>   ```
> 
>   I did not think of this before, but perhaps we could allow `do` to be 
> replaced with `guard`, thereby allowing values to escape to the outer scope, 
> while still ensuring an early exit:
> 
>   ```
>   ```
> I am not sure that “leaky” braces are a good idea, so perhaps some other 
> character could be used to indicate a non-scope or whatever you want to call 
> it:
> 
>   ```
>   ```
> This would make the language even harder to read, so just using braces is 
> probably a better idea.
> 
> This would change the guard syntax slightly, but is a straightforward 
> extrapolation of do/catch and guard, I think. Of course, this could replace 
> the existing guard syntax entirely and its use of semicolons, if we want to 
> go that far…
> 
> Allowing this syntax only if one of the expressions throws is possibly a good 
> backward-compatible solution that would avoid redundant guard syntaxes.
> 
> Anyway there are lot of possibilities here. We are not forced to extend the 
> guard statement as it exists today. The current guard statement syntax was 
> quite controversial when it was introduced and extending it may not be the 
> best option to do what you want.
> 
> - Chris
> 
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> On Jul 8, 2017, at 4:16 PM, Benjamin Spratling via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> 
>> I’ve read your email, but haven’t digested it fully.  One thing I agree with 
>> is that most functions which call throwing functions don’t actually use a 
>> do…catch block, but instead are merely marked “throws” and the error is 
>> propagated back through the stack.  Once I seriously started coding 
>> functions with errors, I realized

Re: [swift-evolution] [Pitch] Guard/Catch

[Christopher Kornher via swift-evolution]

I dashed these emails off very quickly, which is something I should never do 
here. There problems with the “trailing catch” idea. Some of them could be made 
to work, with enough rules added, but it would probably have been best to just 
stick with my original objection to adding special-case syntactic sugar at this 
point in the evolution of the language.

The "trailing catch” would be pretty straightforward for `try?` and `try!` 
calls, since both handle the lack of a return value from the called function. 
There is currently no way to do anything with exceptions thrown from `try?` and 
‘try!’, so there might be some value for these.`try` is more problematic and 
would require an exit or a or an exception to be thrown from the catch block. 
This adds more rules to ‘catch’, which argues against including it in the 
language. Another keyword like “intercept” for catches that would guarantee 
that an exception is thrown from the handling block would be a better choice 
for “try”, I think, but the bar for new keywords is justifiably very high.

In any case, the logic from all uses of a "trailing catch" can be replicated 
with nested do/catch blocks, so I do not think that these ideas should be 
considered now.

The “trailing catch” idea might fit with Dave DeLong’s suggestion of a few days 
ago, in which he wanted support for detailed diagnostics (hopefully that is a 
correct summary). If/when that topic ever is considered, then the "trailing 
catch” may have a place as part of that effort.


> On Jul 8, 2017, at 5:16 PM, Christopher Kornher via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Thanks for you considerate reply. My concern over the proliferation of “sugar 
> proposals” is a general one. This proposal has more merit and general 
> utiliity than many others. I have never used a throwing function in a guard 
> statement that was not itself in a throwing function, but I can see that it 
> could possibly be common in some code. Wrapping a guard statement and all the 
> code that uses variables set in the guard in a do/catch is sub-optimal.
> 
>> On Jul 8, 2017, at 4:16 PM, Benjamin Spratling via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Jul 8, 2017, at 4:08 PM, Christopher Kornher <ckorn...@me.com 
>>> <mailto:ckorn...@me.com>> wrote:
>>> 
>>> I am opposed to this proposal because it muddies up the language to support 
>>> what is essentially an edge case. The standard way to exit a function early 
>>> because an exception is thrown is to make the function itself throw, if it 
>>> is part of a larger operation. The addition of a few lines of try/catch 
>>> code is not a great burden and makes the termination of an an exception 
>>> very clear.
>> 
>> I’ve read your email, but haven’t digested it fully.  One thing I agree with 
>> is that most functions which call throwing functions don’t actually use a 
>> do…catch block, but instead are merely marked “throws” and the error is 
>> propagated back through the stack.  Once I seriously started coding 
>> functions with errors, I realized I almost always wanted my errors to reach 
>> my view-controller or my business logic so I could present separate UI if a 
>> real error occurred, and often my error message depended on the details of 
>> the error instance.
>> 
>>> `guard` statements are generally used to set variables that are needed in 
>>> the body of a function. Using them to save a few lines of exception handing 
>>> code is a very different use. There is no need to mix two relatively clean 
>>> syntaxes for a few edge cases and increase cognitive load one more time, 
>> 
>> 
>> I disagree with your conclusion on this point.
>> The “guard” syntax is specifically designed to achieve early return (and 
>> placing code associated with early return at the point where it happens) and 
>> cleanly installing the returned value into the surrounding scope.  So far it 
>> has been used to achieve early return only with optionals, true.  But is 
>> that inherent to ‘guard’, or is it merely because that’s the only way it has 
>> been used?  The guard does set variables that are needed in the body of the 
>> function, and that’s exactly why using guard with values returned from 
>> throwing functions makes so much sense, because it does exactly the same 
>> thing in a general sense.  The “do”…”catch” structure is intentionally 
>> designed differently, to place the “happy path” in one place and place the 
>> returns in another place.  I think with guard/else, we’re seeing developers 
>> who can handle less cognitive 

Re: [swift-evolution] [Pitch] Guard/Catch

[Christopher Kornher via swift-evolution]

Thanks for you considerate reply. My concern over the proliferation of “sugar 
proposals” is a general one. This proposal has more merit and general utiliity 
than many others. I have never used a throwing function in a guard statement 
that was not itself in a throwing function, but I can see that it could 
possibly be common in some code. Wrapping a guard statement and all the code 
that uses variables set in the guard in a do/catch is sub-optimal.

> On Jul 8, 2017, at 4:16 PM, Benjamin Spratling via swift-evolution 
>  wrote:
> 
> 
>> On Jul 8, 2017, at 4:08 PM, Christopher Kornher  wrote:
>> 
>> I am opposed to this proposal because it muddies up the language to support 
>> what is essentially an edge case. The standard way to exit a function early 
>> because an exception is thrown is to make the function itself throw, if it 
>> is part of a larger operation. The addition of a few lines of try/catch code 
>> is not a great burden and makes the termination of an an exception very 
>> clear.
> 
> I’ve read your email, but haven’t digested it fully.  One thing I agree with 
> is that most functions which call throwing functions don’t actually use a 
> do…catch block, but instead are merely marked “throws” and the error is 
> propagated back through the stack.  Once I seriously started coding functions 
> with errors, I realized I almost always wanted my errors to reach my 
> view-controller or my business logic so I could present separate UI if a real 
> error occurred, and often my error message depended on the details of the 
> error instance.
> 
>> `guard` statements are generally used to set variables that are needed in 
>> the body of a function. Using them to save a few lines of exception handing 
>> code is a very different use. There is no need to mix two relatively clean 
>> syntaxes for a few edge cases and increase cognitive load one more time, 
> 
> 
> I disagree with your conclusion on this point.
> The “guard” syntax is specifically designed to achieve early return (and 
> placing code associated with early return at the point where it happens) and 
> cleanly installing the returned value into the surrounding scope.  So far it 
> has been used to achieve early return only with optionals, true.  But is that 
> inherent to ‘guard’, or is it merely because that’s the only way it has been 
> used?  The guard does set variables that are needed in the body of the 
> function, and that’s exactly why using guard with values returned from 
> throwing functions makes so much sense, because it does exactly the same 
> thing in a general sense.  The “do”…”catch” structure is intentionally 
> designed differently, to place the “happy path” in one place and place the 
> returns in another place.  I think with guard/else, we’re seeing developers 
> who can handle less cognitive loading find it easier to reason about early 
> return than grouping failures after the happy path.  This proposal hopes to 
> introduce that better language architecture to the catching of errors.

All catches don’t have to exit the outer scope, so using guard only handles a 
subset 

It think that creating the terse try/catch for simple cases has multiple 
advantages:

1) I think that it addresses your desire for a simple way to use 
throwing functions easily in guard statements.

2) It avoids having to change the guard syntax to accomplish this

3) It is useful for handling simple one line try/catch constructs in 
less space in a way that should not seem too foreign to Swift developers.

4) It simplifies code that currently uses nested do/try/catch 
constructs. Even though this is rare, it introduces significant “rightward 
drift”.

5) It can used to return early from void throwing functions easily. 
e.g. : 

```
guard try foo( ) catch { return }
```

Multiple void throwing functions would probably be better handled by a 
do/catch block, but there is no danger of needing values from these functions 
because there are none:

```
do {
try fn1()
try fn2()
} catch {
// keep going, return or call a non-returning function, since 
throw is already handled by declaring a throwing enclosing function.
// No varibles are needed by the outer block because none are 
set
// So it is not clearly a guard-like statement
}
```

I did not think of this before, but perhaps we could allow `do` to be 
replaced with `guard`, thereby allowing values to escape to the outer scope, 
while still ensuring an early exit:

```
guard {
try fn1()
try fn2()
let x = fn3()
} catch {
// Must exit
} else {
// Must exit
}
```
I am not sure that “leaky” braces are a 

Re: [swift-evolution] [Pitch] Guard/Catch

[Christopher Kornher via swift-evolution]

I am opposed to this proposal because it muddies up the language to support 
what is essentially an edge case. The standard way to exit a function early 
because an exception is thrown is to make the function itself throw, if it is 
part of a larger operation. The addition of a few lines of try/catch code is 
not a great burden and makes the termination of an an exception very clear.

`guard` statements are generally used to set variables that are needed in the 
body of a function. Using them to save a few lines of exception handing code is 
a very different use. There is no need to mix two relatively clean syntaxes for 
a few edge cases and increase cognitive load one more time, 

If we really want a more compact try/catch syntax, we should not use (abuse?) 
the `guard` statement, but instead allow a training catch which reads similarly 
to a trailing closure:

```
let x = try aFunction() catch ( let e: Error ) {
… 
} 

```

This might be confused with trailing closures, but since most editors will 
highlight the `catch`, the meaning should be pretty clear.


Using this in a `guard` would look like: 

```
guard let x = try aFunction() catch ( let e: Error ) { … // must exit };
let y=y;
let z=x else {
...
}
```
Multiple throwing statements in the guard could be handled like:

```
guard let x = try aFunction();
let xx = try aFunction2() catch ( let e: Error ) { … // must exit };
let y=y;
let z=x else {
...
}
```
but this creeps toward the original proposal and I do not think that the added 
complexity is worth the trouble. I prefer the simpler syntax for the rare cases 
where is more than one throwing statement within the guard:

```
guard let x = try aFunction() catch ( let e: Error ) { … // must exit };
let xx = try aFunction2() catch ( let e: Error ) { … // must exit };
let y=y;
let z=x else {
...
}
```

This addition, I believe, adds much more power to the language and retains the 
simplicity of the “guard” statement.


It helps clean-up code like:

```
func attemptComplexOperation() throws {
do {
let x = try functionA()
} catch ( let e: Error ) {
Log.error( “could not do A: \(String(describing:e)” )
throw e
}

do {
let y = try functionB()
} catch ( let e: Error ) {
Log.error( “could not do B: \(String(describing:e)” )
throw e
}
}
```

to:

```
func attemptComplexOperation() throws {
let x = try functionA() catch ( let e: Error ) {
Log.error( “could not do A: \(String(describing:e)” )
throw e
}

let Y = try functionB() catch ( let e: Error ) {
Log.error( “could not do B: \(String(describing:e)” )
throw e
}
}
```

This this is error-prone because exception rethrowing could be omitted and the 
code would still compile. Perhaps another keyword to act upon an exception, but 
not consume it would be useful (I am sure that this idea will be popular :) )

```
func attemptComplexOperation() throws {
let x = try functionA() intercept ( let e: Error ) {
Log.error( “could not do A: \(String(describing:e)” )
}

let Y = try functionB() intercept ( let e: Error ) {
Log.error( “could not do B: \(String(describing:e)” )
}
}
```

I hope that the themes for Swift 5 comes soon from the core team, so we can 
slow down the discussions of the 'syntactic sugar proposal of the week'. I fear 
that Swift will become a much more complex and difficult to read language if we 
keep adding sugar to handle special cases. I hope that it doesn’t become too 
difficult to understand through all the special-case sugar coating. Perhaps 
more importantly, there are important features awaiting implementation that are 
needed by members of the community that will be delayed and possibly 
complicated by the addition of syntactic sugar.

If the decision is to accept the original proposal, then I vote for #1 below. 
Note that exceptions could be handled within the else clause by changing the 
order. I don’t think that this would be a good idea, however, as it makes the 
statement even harder to understand:


Please, not this:
```
guard let result:Result = try doSomething()
else {  try cleanup() }
catch { ...}
```


> On Jul 8, 2017, at 12:15 PM, Benjamin Spratling via swift-evolution 
>  wrote:
> 
> 
>> func doSomething() throws → Result? { … }
>> 
>> How would you handle both the catch and the let binding of the result?
> 
> I agree this proposal needs to define the behavior, since returning an 
> optional from a throwing function is valid.
> 
> I see a few options:
> 
> 1) find a way to generally incorporate optional binding and error binding 
> into the same guard clause.
> Could it be as simple as 
> guard let result:Result = try doSomething()
> catch { ...}
> else { ... }
> ?
> 
>  In this option, the else block almost acts like "finally" block.  I 
> recommend against this option because IF 

Re: [swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

[Christopher Kornher via swift-evolution]

A full-fledged introspection system should provide this information, which I 
suppose could be useful for creating proxies through code generation or dynamic 
Objective-C like features, should they ever be added to the language. Would 
that be sufficient for your needs? It is not clear to me what problem you are 
trying to solve.

Hopefully I won't stir up too much trouble by saying that this kind of 
capability is very useful in Objective-C for mocking, for example.


> On Jul 2, 2017, at 7:55 PM, Daryle Walker via swift-evolution 
>  wrote:
> 
> 
>> On Jul 1, 2017, at 2:07 AM, Brent Royal-Gordon > > wrote:
>> 
>>> On Jun 30, 2017, at 6:17 PM, Daryle Walker via swift-evolution 
>>> > wrote:
>>> 
>>> Given a type MyType, how can I get a type-alias to the type’s protocols? If 
>>> MyType conforms to Protocol1 and Protocol2, I would want something like
>>> 
>>> typealias MyProtocol = Protocol1 & Protocol2
>>> 
>>> (and Any if MyType doesn’t conform to any protocols). Does this facility 
>>> already exist in Swift? I don’t think it does, so I proposed the hybrid 
>>> “MyType.Protocol” syntax to express the idea.
>> 
>> Leave the syntax aside. What are you planning to do with this feature? I 
>> understand that you want to have some way of saying "composition of all 
>> protocols this type conforms to"; I don't understand *why* you want it or 
>> what kind of code you would need it for.
> 
> 
> It wasn’t until I started this thread that I realized that Swift didn’t have 
> a way to get a bulk list of a type’s protocols. A little later, I came up 
> with a reason why this never came up before (or at least not often): knowing 
> this isn’t really useful.
> 
> You could use this to make MyTypeB conform to all protocols of MyTypeA. But 
> then you’re stuck. The list of protocols for a type is a closed from the 
> linker’s perspective, but open from the user’s perspective. The user couldn’t 
> write all the methods needed unless the unknown ones all have default 
> implementations. The proposal I’m coming up with has a facility to copy all 
> the members of one type to another. You can specify by exact member name, or 
> you can specify a protocol to get copies of all applicable members at once. 
> This is where an all-protocols alias can help. With manual copying, the 
> user’s cardinality of members copied is usually less than what’s available, 
> with an automatic list the cardinalities are always equal.
> 
> — 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com 
> 
> ___
> 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-0176: Enforce Exclusive Access to Memory

[Christopher Kornher via swift-evolution]

https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
 

What is your evaluation of the proposal?
+1 It seems to be a carefully considered and balanced approach to simultaneous 
memory access in single threaded code.
Is the problem being addressed significant enough to warrant a change to Swift?
It sure seems to be.
Does this proposal fit well with the feel and direction of Swift?
Absolutely. Safety is one of the paramount goals of Swift and the ‘gotchas’ 
listed in the document can lead to subtle bugs, with potentially fatal 
consequences.
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
variants of `memcpy()` and similar C functions. Complex manipulation of data 
structures  in C, and C++ could lead to similar issues, I suppose, but the 
simple memory model of these languages puts developers on guard against 
simultaneous memory access. I certainly was not aware of these issues is Swift, 
but I am very cautious around mutating value types.  I expect that many Swift 
developers coming from classical OO languages are similarly wary of mutating 
value types, or should be. Fixing these issues will give me more confidence 
when dealing with mutating value types.
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
I read through the proposal. It is very well written.  While I did not 
carefully study each case, I feel that I have a good understanding of the 
problem and the philosophy behind the solution. I feel confident that this will 
be a big improvement to the safety of Swift.

___
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

[Christopher Kornher via swift-evolution]

> On Apr 21, 2017, at 12:58 PM, Xiaodi Wu  > wrote:
> 
> Sorry, I don't follow. What's this about paragraphs?

This was a common example of the many types of textual input that would benefit 
from concatenation characters in multiline text. Using ‘\’ as a 
continuation/concatenation character has been in common use for decades. Refer 
to the usage section here: https://en.wikipedia.org/wiki/Backslash 


I am sure that you can find many examples if you care to search for them.


> 
> 
> On Fri, Apr 21, 2017 at 1:56 PM, Christopher Kornher  > wrote:
> 
>> 
>> On Apr 21, 2017, at 12:48 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> On Fri, Apr 21, 2017 at 1:45 PM, Erica Sadun > > wrote:
>>> 
>>> 
>>> On Apr 21, 2017, at 12:40 PM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
>>> On Fri, Apr 21, 2017 at 8:48 AM, Robert Bennett via swift-evolution 
>>> > wrote:
 Xiaodi, I think one thing you're neglecting is that users may never print 
 out a multiline literal string at all. A string might never be printed or 
 read by a human outside of the code it resides in. In this case it seems 
 perfectly reasonable to ask that it be possible to format the string 
 nicely in the code and disregard how it would actually be printed.
>>> 
>>> Can you give an example of such a use case, where a string is never seen by 
>>> a human but one cannot insert literal newlines and would need elided ones 
>>> instead?
>>> The most common reason is that the code is maintained by a (non-human) 
>>> developer, who wants to be able to see and update the code in a readable 
>>> form, but that represents a single line that will automatically wrapped by, 
>>> for example, a UITextView for (human) consumption. 
>> 
>> A different scenario from what Robert's describing, but sure. This goes to 
>> my question to David Hart. Isn't this an argument for a feature to allow 
>> breaking a single-line string literal across multiple lines? What makes this 
>> a use case for some feature for _multiline_ string literals in particular?
>> 
>> paragraphs are denoted by `\n` in almost every rich text tool / library
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> Begin forwarded message:
> 
> From: Christopher Kornher 
> Subject: Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals
> Date: April 21, 2017 at 12:56:54 PM MDT
> To: Xiaodi Wu 
> 
> 
>> On Apr 21, 2017, at 12:48 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> On Fri, Apr 21, 2017 at 1:45 PM, Erica Sadun > > wrote:
>>> 
>>> 
>>> On Apr 21, 2017, at 12:40 PM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
>>> On Fri, Apr 21, 2017 at 8:48 AM, Robert Bennett via swift-evolution 
>>> > wrote:
 Xiaodi, I think one thing you're neglecting is that users may never print 
 out a multiline literal string at all. A string might never be printed or 
 read by a human outside of the code it resides in. In this case it seems 
 perfectly reasonable to ask that it be possible to format the string 
 nicely in the code and disregard how it would actually be printed.
>>> 
>>> Can you give an example of such a use case, where a string is never seen by 
>>> a human but one cannot insert literal newlines and would need elided ones 
>>> instead?
>>> The most common reason is that the code is maintained by a (non-human) 
>>> developer, who wants to be able to see and update the code in a readable 
>>> form, but that represents a single line that will automatically wrapped by, 
>>> for example, a UITextView for (human) consumption. 
>> 
>> A different scenario from what Robert's describing, but sure. This goes to 
>> my question to David Hart. Isn't this an argument for a feature to allow 
>> breaking a single-line string literal across multiple lines? What makes this 
>> a use case for some feature for _multiline_ string literals in particular?
> 
> paragraphs are denoted by `\n` in almost every rich text tool / library
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> 

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

[Christopher Kornher via swift-evolution]

I failed to mention that It is currently possible to create a protocol 
extension with a default argument, but this is not ideal. This has made the 
topic complex enough to warrant a new thread and I will not hijack this thread 
any longer. If anyone is interested, I will start a new thread for this 
proposal.


// Currently works 
protocol P {
func ff( a:Int )
}

extension P
{
func ff( a:Int=1 ) {
print( "extension method" ) // I believe that this should be in 
the protocol
fatalError( "There is not sensible default implementation. This method 
exists to make the compiler happy" )
}
}


struct S : P {
func ff( a:Int) {   // Does not override the extension method. Will not be 
called unless `a` is passed. 
}
}


let p:P = S()

p.ff()  // Will crash. Calls the extension method, which is never "overridden"




> On Mar 26, 2017, at 3:09 PM, Christopher Kornher via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> A comment: Your description of #2 is a little confusing. Functions with 
> default arguments can currently satisfy protocols. Perhaps it should be 
> “Allow functions with extra default arguments to satisfy protocols"
> 
> I have not had the need for the features you mentioned, but it would be nice 
> to allow them both. Having closures satisfy protocol requirements would 
> improve support for composition.
> 
> I would like to add one: Allow protocols to define default arguments. 
> Implementations can define default arguments in protocol implementations but 
> that is not particularly useful for protocol oriented programming. Perhaps I 
> should start a different thread, but these are related. Can we call it
> 
> 3) Allow protocols to define default parameters
> 
> protocol P {
> func f( a:Int )
> func ff( a:Int=1 )  // Error: "Default argument not permitted..."
> }
> 
> struct S : P {
> func f( a:Int=2 ) { // Currently legal, but not useful for protocol 
> oriented programming
> }
> 
> func ff( a:Int=3 ) {   // A little confusing to the uninitiated perhaps, 
> but useful
> }  // and consistent with method overrides.
> }
> 
> let p:P = S()
> 
> p.f()   // Fails (as it should since the protocol does 
> not have a default value)
> 
> p.ff()  // Would succeed if the protocol could have a 
> default param.
> // I find myself wanting this behavior frequently
> 
>> On Mar 26, 2017, at 1:04 PM, David Sweeris via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> On Mar 26, 2017, at 11:12, Karl Wagner via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> I’d like to pitch the following two language changes. Both of them are 
>>> technically possible today if you manually write thunks for the relevant 
>>> protocol requirements, but it would be nice if we allowed them to be 
>>> written directly:
>>> 
>>> 1) Allow closures to satisfy function requirements in protocols
>>> 
>>> protocol MyProtocol {
>>> func run(param: Int) -> String
>>> }
>>> 
>>> struct MyStruct : MyProtocol {
>>> var run : (Int)->String   // Satisfies requirement MyProtocol.run
>>> }
>>> 
>>> Among other things, it would make writing type-erased wrappers in the style 
>>> of AnyCollection much easier. The only obvious niggle is that the argument 
>>> label wouldn’t be required when invoking the closure directly. The labels 
>>> have no type-system significance, but it does make it subtly easier to 
>>> write less generic code than you intend do. We could solve this by having 
>>> code-completion favour protocol methods in this situation, or simply to 
>>> require the label when invoking a closure which implements a known protocol 
>>> requirement.
>>> 
>>> 2) Allow functions with default parameters to satisfy function requirements 
>>> in protocols
>>> 
>>> protocol Sportsplayer {
>>> func goalsScored() -> Int
>>> }
>>> 
>>> struct SoccerPlayer: Sportsplayer {
>>> struct GoalType : RawOptionSet {
>>> static let Shot   = GoalType(0x1)
>>> static let Volley = GoalType(0x10)
>>> static let Header = GoalType(0x100)
>>> static let Any= GoalType(0x111)
>>> }
>>> 
>>> // Default value .Any means this confo

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

[Christopher Kornher via swift-evolution]

A comment: Your description of #2 is a little confusing. Functions with default 
arguments can currently satisfy protocols. Perhaps it should be “Allow 
functions with extra default arguments to satisfy protocols"

I have not had the need for the features you mentioned, but it would be nice to 
allow them both. Having closures satisfy protocol requirements would improve 
support for composition.

I would like to add one: Allow protocols to define default arguments. 
Implementations can define default arguments in protocol implementations but 
that is not particularly useful for protocol oriented programming. Perhaps I 
should start a different thread, but these are related. Can we call it

3) Allow protocols to define default parameters

protocol P {
func f( a:Int )
func ff( a:Int=1 )  // Error: "Default argument not permitted..."
}

struct S : P {
func f( a:Int=2 ) { // Currently legal, but not useful for protocol 
oriented programming
}

func ff( a:Int=3 ) {   // A little confusing to the uninitiated perhaps, 
but useful
}  // and consistent with method overrides.
}

let p:P = S()

p.f()   // Fails (as it should since the protocol does not 
have a default value)

p.ff()  // Would succeed if the protocol could have a 
default param.
// I find myself wanting this behavior frequently

> On Mar 26, 2017, at 1:04 PM, David Sweeris via swift-evolution 
>  wrote:
> 
> 
> On Mar 26, 2017, at 11:12, Karl Wagner via swift-evolution 
> > wrote:
> 
>> I’d like to pitch the following two language changes. Both of them are 
>> technically possible today if you manually write thunks for the relevant 
>> protocol requirements, but it would be nice if we allowed them to be written 
>> directly:
>> 
>> 1) Allow closures to satisfy function requirements in protocols
>> 
>> protocol MyProtocol {
>> func run(param: Int) -> String
>> }
>> 
>> struct MyStruct : MyProtocol {
>> var run : (Int)->String   // Satisfies requirement MyProtocol.run
>> }
>> 
>> Among other things, it would make writing type-erased wrappers in the style 
>> of AnyCollection much easier. The only obvious niggle is that the argument 
>> label wouldn’t be required when invoking the closure directly. The labels 
>> have no type-system significance, but it does make it subtly easier to write 
>> less generic code than you intend do. We could solve this by having 
>> code-completion favour protocol methods in this situation, or simply to 
>> require the label when invoking a closure which implements a known protocol 
>> requirement.
>> 
>> 2) Allow functions with default parameters to satisfy function requirements 
>> in protocols
>> 
>> protocol Sportsplayer {
>> func goalsScored() -> Int
>> }
>> 
>> struct SoccerPlayer: Sportsplayer {
>> struct GoalType : RawOptionSet {
>> static let Shot   = GoalType(0x1)
>> static let Volley = GoalType(0x10)
>> static let Header = GoalType(0x100)
>> static let Any= GoalType(0x111)
>> }
>> 
>> // Default value .Any means this conforms to Sportsplayer
>> func goalsScored(type: GoalType = .Any) {
>>   //...
>> }
>> }
>> 
>> struct Footballer: Sportsplayer {
>> struct GoalType : RawOptionSet {
>> static let Touchdown = GoalType(0x1)
>> static let FieldGoal = GoalType(0x10)
>> static let Any   = GoalType(0x11)
>> }
>> 
>> // Default value .Any means this conforms to Sportsplayer
>> func goalsScored(type: GoalType = .Any) {
>>   //...
>> }
>> }
>> 
>> I often find that I want to add some optional, implementation-specific 
>> parameter to a function which implements a protocol requirement. That’s 
>> currently not possible, and it’s a bit annoying.
> 
> IIRC, the issue with #2 is that protocols specify declaration-site details, 
> but default parameters are implemented at the call-site. At least I believe 
> that statement was accurate about a year(ish) ago... Dunno if anything has 
> changed since then.
> 
> If it can be made to work, though, I'd be in favor of it, and I think #1 as 
> well.
> 
> - Dave Sweeris
> ___
> 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-0159: Fix Private Access Levels

[Christopher Kornher via swift-evolution]

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?
-1 

Is the problem being addressed significant enough to warrant a change to Swift?
Not on its own. I believe that it would be better for the community to handle 
this as part of a thorough look at Sub Modules and code organization. It is 
possible that this will be modified yet again when submodules/packages are 
addressed, creating yet more churn.

Access modifiers should not much of an issue for beginners and small projects. 
The current rules are useful for large and security-oriented projects. See the 
response by Drew Crawford.

Does this proposal fit well with the feel and direction of Swift?
File scoping has always seemed like a “C legacy” feature. It encourages large 
files, which is a problem in MacOS and iOS already. This proposal does nothing 
to decrease file size and makes file scoping the only way to get private scope. 
File-based scoping also discourages or at least complicates the development of 
non file-based and non-textual representations of Swift code

If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
C and other macro-assemblers. Isn’t there a better model out there somewhere?

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
I read through the proposal, which is pretty straightforward.

> On Mar 20, 2017, at 5:54 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through 
> March 27, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> 

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

Re: [swift-evolution] Smart KeyPaths

[Christopher Kornher via swift-evolution]

> On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution 
>>  wrote:
>> 
>> +1.  This is my favorite solution so far. 
>> 
>> With ‘Person.keypath.name' it is obvious that we are creating a key path.  
>> There is no ambiguity for the reader.  With autocomplete it will be very 
>> little extra typing anyway…
> 
> But that adds a lot of verbosity. They disregarded #keyPath because it was 
> too verbose.

The syntax in the original proposal is terse and elegant, and will probably be 
fine when a developer who is experienced with Swift and a particular codebase 
is first writing the code. Using “key path” or “keypaths” of perhaps a shorter 
term or even a single leading character (`#` ?) will make this feature more 
discoverable, tool-friendly and its usages more maintainable.

An extra term or character does add verbosity. How much is subjective, but I 
would not call it “a lot”. It does not add any nesting or code complexity. KVO 
code is usually a small fraction of most Objective-C projects (in my 
experience, at least) and it is probably safe to assume that the usage of this 
feature in Swift will be similar.

Verbosity vs clarity is often a tradeoff and I think that on balance, for a 
feature like this a little extra verbosity is worth it. Swift does not have the 
most terse syntax possible. `++` was removed, for example.

Just because an assignment is already implicitly typed in Swift does not mean 
that the ambiguity has to keep increasing without end for implementation of all 
new features, especially for ones that are not used very frequently.


> 
>> Thanks,
>> Jon
>> 
>>> On Mar 19, 2017, at 9:20 PM, Dietmar Planitzer via swift-evolution 
>>>  wrote:
>>> 
>>> Key paths of this form:
>>> 
>>> Person.name
>>> 
>>> will always make it harder than necessary to:
>>> 
>>> * search for all places where we are using key paths
>>> 
>>> * do efficient code completion. Eg you’ll get a mix of static properties 
>>> and key paths
>>> 
>>> 
>>> We’ve been using this kind of setup in our projects for some time now:
>>> 
>>> class Person {
>>> 
>>> struct keypath {
>>> 
>>>static let name = #keyPath(Person.name)
>>>…
>>> }
>>> 
>>> …
>>> }
>>> 
>>> where a keypath is then used like this:
>>> 
>>> Person.keypath.name
>>> 
>>> and this has worked very well. It makes it easy to see where we are using a 
>>> keypath rather than accessing some static property, it works very nicely 
>>> with code completion and it makes it very easy to search for all places 
>>> where we are using key paths from the Person type.
>>> 
>>> I would prefer that the proposed keypath model would automatically organize 
>>> key paths like this.
>>> 
>>> 
>>> Regards,
>>> 
>>> Dietmar Planitzer
>>> 
>>> 
 On Mar 19, 2017, at 20:49, Matthew Johnson via swift-evolution 
  wrote:
 
 
 
 Sent from my iPad
 
> On Mar 19, 2017, at 10:31 PM, Jaden Geller via swift-evolution 
>  wrote:
> 
> I think the clarity desired is more similar to that obtained by the `try` 
> keyword. Ya, the compiler knows that this function throws already, but 
> Swift aims for clarity in the source code. Clarity is often achieved by 
> providing potentially redundant information for the programmer.
> 
> As proposed, it is difficult to distinguish a key path from a static 
> variable. Maybe that's not problematic? Well, it's up to the community to 
> decide.
 
 Why don't we just say all instance properties are shadowed by a static 
 constant property of the same name with the appropriate key path type.  
 This makes it not mysterious at all but instead very straightforward.  We 
 could even say that static and class properties are shadowed by a key path 
 property on the meta type.
 
 
> I do think it is a bit worrisome that static variable access might cause 
> side effects (or at least, might take a while to compute) but creating 
> key paths should not, but that's a fringe case probably.
> 
> On Mar 19, 2017, at 6:32 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>>> On Mar 19, 2017, at 4:47 PM, Charles Srstka  
>>> wrote:
>>> 
 This is true of many things.  It is why IDEs make type information 
 readily available.
>>> 
>>> Is clarity not a thing to be desired?
>> 
>> Clarity is in the eye of the beholder. Here's one notion of clarity:
>> 
>>   sum :: (Num a, Foldable t) => t a -> a
>>   sum = foldl (+) 0
>> 
>> Here's another:
>> 
>>   int sum(int array[], size_t len) {
>>   int total = 0;
>>   for(size_t i = 0; i < len; i++) {
>>   total += array[i];

Re: [swift-evolution] Smart KeyPaths

[Christopher Kornher via swift-evolution]

I love the proposal and it is great to see this feature being considered. This 
provides a great foundation for future functionality. I too find the syntax 
confusing. The syntax is elegant and does not introduce any extra keywords, but 
accessing key paths is an advanced “meta” feature and does not have to be this 
straightforward. I would prefer less potential ambiguity at the expense of a 
little extra verbosity.

I suggest that the all keypaths be grouped under a `keypaths` pseudo-root path. 
This eliminates potential ambiguity with other language constructs and is 
easier for humans ( and as an added benefit, the compiler) to parse, reducing 
potential errors and clearer error diagnostics for name collisions and 
misspellings. Compiler reasoning and error messages are difficult enough deal 
with today. The use of a unique root for all keypaths will also greatly 
simplify searching for uses and code maintenance.

Many of the advanced language features that have been proposed for Swift add 
elegance and power to the language, but they have a cost in comprehensibility 
especially to beginners. The use of `keypaths` greatly improves the 
discoverability of this feature.

Another potential benefit of introducing a keyword-like construct now could 
simplifies the task of adding more metadata with other pseudo-root paths like 
`classKeypaths` and others as the language evolves.

Here is your example, rewritten with `keypaths` highlighted as a keyword. It 
does not add any additional nesting or operators, but clearly identifies the 
construct as something different and provides a simple term to search for in 
documentation.


struct Person {
var name: String
var friends: [Person]
var bestFriend: Person?
}

var han = Person(name: "Han Solo", friends: [])
var luke = Person(name: "Luke Skywalker", friends: [han])

let firstFriendsNameKeyPath = Person.keypaths.friends[0].name

let firstFriend = luke[keypaths.path] // han

// or equivalently, with type inferred from context
let firstFriendName = luke[keypaths.friends[0].name]

// rename Luke's first friend
luke[firstFriendsNameKeyPath] = "A Disreputable Smuggler"

let bestFriendsName = luke[keypaths.bestFriend]?.name  // nil, if he is the 
last jedi



> On Mar 17, 2017, at 12:27 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> On 17.03.2017 20:04, Michael LeHew via swift-evolution wrote:
>> Hi friendly swift-evolution folks,
>> 
>> The Foundation and Swift team  would like for you to consider the following
>> proposal:
>> 
>> Many thanks,
>> -Michael
>> 
>> 
>>  Smart KeyPaths: Better Key-Value Coding for Swift
>> ...
> 
> Just my 2 cents. FWIW, I feel like the proposed syntax is VERY confusing.
> 
> Person.friends[0].name - like access to static property. T.method can't have 
> subscript for it and then some field. So, I believe such key paths deserve 
> its own syntax.
> 
> luke[path] - very close to access the subscript of instance. In compare to 
> T.method, we can call result of T.method(i.e. let m = T.method; m()), just 
> like the T.method itself(foo.method()). But here we are calling some kind of 
> subscript instead of access property by "path".
> 
> There is no some 'special' marker for me that saying "hey, there is 
> references to properties used" from the first look.
> 
> Probably we can consider another separators, like
> 
> Person:friends[0].name
> luke:path
> 
> Person->friends[0].name
> luke->path
> 
> Person[friends[0].name] // single brackets for type
> luke[[path]] // double brackets for instance
> 
> Person@friends[0].name
> luke@path
> 
> or other with help of community.
> ___
> 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-0156: Class and Subtype existentials

[Christopher Kornher via swift-evolution]

What is your evaluation of the proposal?
It seems to be a very straightforward and natural extension of existing syntax 
to bring Swift closer to the functionality of Objective-C and other languages. 

My only concern is that using `AnyObject` at first glance seems less 
descriptive  than ‘class’ when used in a protocol declaration, but it may be 
simply because I already familiar with the `class` syntax.

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

Does this proposal fit well with the feel and direction of Swift?
Yes. It is a sensible extension to existing patters. Eliminating the redundancy 
and ambiguity in `class` and `AnyObject` eliminates a barrier to understanding 
the language and is probably worth the pain of deprecating `class` which I have 
used extensively in my code.

If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
I have used the feature numerous times in Objective-C over the years and this 
proposal is a perfect analog as far as I know.

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
I gave the proposal a thorough reading. It is straightforward enough to not 
require much study.




> On Feb 28, 2017, at 2:11 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0156 "Class and Subtype existentials" begins now and runs 
> through March 7, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.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/0156-subclass-existentials.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] A Comprehensive Rethink of Access Levels in Swift

[Christopher Kornher via swift-evolution]

This is a very elegant improvement.

I think of “fileprivate” as “C legacy”. A submodule system seems to be a much 
better way to implement grouping a set of tightly coupled code elements. After 
all, there is no reasonable upper-limit on how large such a set of components 
might become and it would be unfortunate to force developers and compilers to 
have to parse very large files just because that is the only way to scope such 
elements. Getting rid of it ASAP seems like the right way to go.

> On Feb 23, 2017, at 2:56 PM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> Introduction
> 
> There has been a deluge of discussion about access levels lately, all 
> attempting to simplify the situation. Shortly after Swift 3 was released, 
> many people realized that the new access modifier story was far more complex 
> than the old one, and expressed the belief that the changes may have been a 
> mistake.
> 
> In the months that followed, more and more people came to share the same 
> view, and stage 2 of Swift 4 has seen a profusion of proposals addressing the 
> issue. These proposals are generally small and focus on changing just one 
> aspect of access control. However, given the situation we are in now, it is 
> important to look at the problem in its entirety and arrive at a cohesive 
> solution.
> 
> Background
> 
> During the Swift 3 timeframe there were lengthy debates about access control. 
> The end results were to adopt SE-0025 
> ,
>  which introduced the ‘fileprivate’ keyword and made ‘private’ scope-based, 
> and SE-0117 
> ,
>  which made ‘public’ classes closed by default and introduced the ‘open’ 
> keyword. At the time, there was broad agreement (and some dissent) that these 
> were the right changes to make.
> 
> That belief, as well as the numerous arguments which led to it, were 
> well-informed and thoughtfully considered. However, due to the inevitable 
> linear nature of time, they were not based on first-hand experience with the 
> new changes. Upon the release of Swift 3, we all gained that first-hand 
> experience, and it quickly became apparent to many people that the new access 
> control system was needlessly complicated, and not at all the improvement it 
> had been heralded as.
> 
> Rather than make it easy to encapsulate implementation details of related 
> types across multiple files, we had instead doubled down on requiring that 
> many things go in a single file or else reveal their secrets to the entire 
> module. Even worse, the new scope-based ‘private’ discouraged the preferred 
> style of using extensions to build up a type. To cap it off, we went from 
> needing to know two access modifier keywords (‘public’ and ‘private’) to 
> needing to know four of them (‘private’, ‘fileprivate’, ‘public’, and ‘open’) 
> without even providing a way to share details across a small number of 
> related files.
> 
> Motivation – Overview
> 
> Many different ideas for access control have been expressed on the Swift 
> Evolution mailing list. Some people want ‘protected’ or ‘friend’ or 
> ‘extensible’ or various other combinations of type-based visibility. Other 
> people (*cough* Slava) see no need for any levels finer than ‘internal’ at 
> all. The common points of agreement, though, are that ‘fileprivate’ is an 
> awkward spelling, and that the whole system is too complicated.
> 
> It is important that we as the Swift community are able to recognize our 
> mistakes, and even more important that we fix them. We originally thought 
> that the Swift 3 access control changes would be beneficial. However, 
> experience with them in practice has shown that not to be the case. Instead, 
> the language became more complex, and that has real costs. It is time for a 
> simplification.
> 
> The prevailing view from recent discussions is that there should be just one 
> access level more fine-grained than ‘internal’, and it should be spelled 
> ‘private’. Let us leave aside for the moment what its exact meaning should 
> be, and consider the other end of the scale.
> 
> Motivation – Rethinking ‘public’
> 
> Prior to Swift 3 we had just one access level more broad than ‘internal’, and 
> for simplicity of the model it would be desirable to achieve that again. 
> However, SE-0117 raised the point that certain library designs require a 
> class to have subclasses within the defining module, but not outside. In 
> other words, client code should not be able to create subclasses, even though 
> they exist in the library. Let us be clear: this is a niche use-case, but it 
> is important.
> 
> The most common situations are that a class either should not be subclassable 
> at all—in which case it is ‘final’—or that it should be subclassable anywhere 
> including 

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

[Christopher Kornher via swift-evolution]

> On Feb 20, 2017, at 12:31 PM, Christopher Kornher via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
>> 
>> On Feb 18, 2017, at 6:16 AM, David Rönnqvist via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> +1, two small questions:
>>> 
>>> - If two cases have the same base name but different full names, will 
>>> matching on the base name match both cases, or will it be an error?
>> 
>> I feel that it would be safer if it was an error. If the developer intends 
>> to match both cases, requiring both explicitly is a (slight) inconvenience 
>> but it's also very clear about what's going to match. 
> 
> I disagree. It is simple enough to use different base names if you don’t want 
> the cases to match. An example of why it should not be an error: I intend to 
> for errors with same base names to be handled in the same way and I don’t 
> want to enumerate all the similar cases and change code every time I add a 
> new way to construct an error. I understand that other people want the 
> equivalent of function overloading. Code that needs to access values must 
> deal with unique cases, so type safety is assured in any case.
> 
> Java enums have arguments and match on “base names” (they are quite 
> different, but the precedent exists) and I don’t think that matching on the 
> base name would be confusing. I also do not believe that it is worth adding 
> this feature if all cases are completely unique.The pain of forcing a 
> (probably small) subset of developers to use unique names is preferable to 
> complicating the language for no functional benefit, in my opinion.

A possible compromise: specify that all base names should be matched with a new 
keyword (or?) Here the keyword ```all``` is used to match all base names.

```
enum MyError : Error
{
case e( a: String )
case e( a: Int )
}

func handleError( error: MyError )
{
switch error {
case all .e :
break
}
}
```

> 
> 
>> 
>>> - What are the memory layout optimizations described here? From a first 
>>> glance this looks purely syntactic.
>>> 
>>> Slava
>>> 
>>>> On Feb 17, 2017, at 7:26 PM, John McCall via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> Hello Swift community,
>>>> 
>>>> The review of "SE-0155: Normalize Enum Case Representation" begins now and 
>>>> runs through next Friday, February 26th. The proposal is available here:
>>>>
>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>>>>  
>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.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 
>>>> <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/0155-normalize-enum-case-representation.md
>>>>  
>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.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 langua

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

[Christopher Kornher via swift-evolution]

> On Feb 18, 2017, at 6:16 AM, David Rönnqvist via swift-evolution 
>  wrote:
> 
> On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution 
> > wrote:
> 
>> +1, two small questions:
>> 
>> - If two cases have the same base name but different full names, will 
>> matching on the base name match both cases, or will it be an error?
> 
> I feel that it would be safer if it was an error. If the developer intends to 
> match both cases, requiring both explicitly is a (slight) inconvenience but 
> it's also very clear about what's going to match. 

I disagree. It is simple enough to use different base names if you don’t want 
the cases to match. An example of why it should not be an error: I intend to 
for errors with same base names to be handled in the same way and I don’t want 
to enumerate all the similar cases and change code every time I add a new way 
to construct an error. I understand that other people want the equivalent of 
function overloading. Code that needs to access values must deal with unique 
cases, so type safety is assured in any case.

Java enums have arguments and match on “base names” (they are quite different, 
but the precedent exists) and I don’t think that matching on the base name 
would be confusing. I also do not believe that it is worth adding this feature 
if all cases are completely unique.The pain of forcing a (probably small) 
subset of developers to use unique names is preferable to complicating the 
language for no functional benefit, in my opinion.


> 
>> - What are the memory layout optimizations described here? From a first 
>> glance this looks purely syntactic.
>> 
>> Slava
>> 
>>> On Feb 17, 2017, at 7:26 PM, John McCall via swift-evolution 
>>> > wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of "SE-0155: Normalize Enum Case Representation" begins now and 
>>> runs through next Friday, February 26th. The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.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/0155-normalize-enum-case-representation.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,
>>> 
>>> John McCall
>>> 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

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

Re: [swift-evolution] A case for postponing ABI stability

[Christopher Kornher via swift-evolution]

> On Jan 27, 2017, at 3:08 PM, Freak Show via swift-evolution 
>  wrote:
> 
> Maybe so - but IBM solved this very problem along with release to release 
> binary compatibility for C++ and a number of other languages twenty years ago 
> with the System Object Model (SOM).

As one of the developers of the ill-fated WWDC OpenDoc demos that failed 
spectacularly because of bugs in early versions of SOM, I just want to caution 
everyone not to underestimate the complexity of these solutions and the level 
of effort required to bring them up to production quality.

That being said, it is probably too constraining to assume that one ABI should 
last more than a few years for a language like Swift that is destined for 
“world domination” and will eventually be used for platforms spanning from 
watches (and smaller) to data centers and solutions from scripting to real-time 
systems. This is a great time for language design — the most prolific period of 
language development I have ever seen. There is no reason to expect the pace of 
language innovation to slow down and new ideas will probably force Swift to 
stand still or break ABI compatibility if a system is not developed to support 
ABI migration.

> 
> I'm not arguing for its adoption per se - but good ideas are always worth 
> stealing and there was some solid engineering in there.
> 
> Sent from the road
> 
>> On Jan 27, 2017, at 09:19, Tino Heth via swift-evolution 
>>  wrote:
>> 
>> I wouldn't expect that I can mix language and framework versions freely.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [draft] Compound Names For Enum Cases

[Christopher Kornher via swift-evolution]

Would using arbitrary label names in statements like `case .foo ( let bar )` 
still work?  See my example below? There is some code that does this, but it 
can be fixed with a simple string replacement for nearly all cases, I would 
think.


> On Jan 24, 2017, at 8:10 PM, Xiaodi Wu via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> No code would be broken. Like functions, case `bar(a:)` can be referred to as 
> `bar` as long as there is no ambiguity. No existing code can have more than 
> one case named bar.
> On Tue, Jan 24, 2017 at 19:17 Christopher Kornher <ckorn...@me.com 
> <mailto:ckorn...@me.com>> wrote:
> Sorry for not connecting the dots…yet another example of why we need a better 
> way to handle long discussions :)
> …and the dangers of multitasking, perhaps…
> 
> I guess that this shows that having multiple cases with the same name, 
> distinguished by the type of associated value, is possible without this 
> proposal, for whatever that may be worth.
> 
> It is anecdotal, perhaps, but this proposal will break a lot of my code. I 
> tend to use labels as public names for associated values, and different 
> internal names. Forcing consistent naming is sensible. It would come at the 
> cost of breaking a significant amount of existing code and making the 
> language more “fiddly”.
> 
> Comparisons have been made to function signatures, but enums cases with > 2 
> values are rare in my experience, and functions can often have  > 2 
> arguments. Perhaps enums with more associated values will become more common 
> if enum cases become more like structure declarations with well defined 
> element names.
> 
> Just a random thought: Treating enum cases like structs would become more 
> reasonable as a result of this proposal i.e. they could conform to protocols. 
> I am not sure that anyone wants to worry about functions for enum cases, but 
> it might be useful to pass enum cases directly to functions that would 
> normally need a struct. Unifying enums and structs in this way might an 
> interesting thing to consider. 
> 
> Associated values that can differ for each enum case seems to be a feature 
> unique to Swift. Is this a feature of any other language?
> 
>> On Jan 24, 2017, at 4:55 PM, Xiaodi Wu via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Yes, but *this* proposal is precisely to make the label part of the name.
>> 
>> 
>> On Tue, Jan 24, 2017 at 17:51 Christopher Kornher <ckorn...@me.com 
>> <mailto:ckorn...@me.com>> wrote:
>>> On Jan 24, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I'm now confused who is arguing for what. Enums cases cannot have the same 
>>> name. As far as I'm aware, this proposal does not seek to change that. Each 
>>> case must still be unique. It only changes whether labels are regarded as 
>>> part of the name or part of the associated type.
>> 
>> Labels are currently neither part of the name nor part of the associated 
>> type. See my example (it runs in the playground in Xcode 8.2.1).
>> 
>> Forgive any lack of precise terminology:  Labels for enums with associated 
>> values are currently only used to create a "function signature" for 
>> constructing values for the enum. They are ignored in all other uses of the 
>> enum AFAIK.
>> 
>> My proposal is a way to allow multiple cases with the same name without 
>> breaking existing code. It has the benefit of giving enums a richer meaning, 
>> in simple English:
>> 
>> Here is an example of a way to handle this currently and what it would 
>> become:
>> 
>> // Runs now
>> enum MultipleTypes {
>> case anInt( value: Int )
>> case aString( value: String )
>> }
>> 
>> enum E {
>> case a( a: MultipleTypes )
>> }
>> 
>> let theCurrentWay = E.a( a: .aString( value: "str") )
>> 
>> switch theCurrentWay {
>> case .a( let x ) :
>> switch x {
>> case .anInt( let x ) :
>> break
>> 
>> case .aString( let x ) :
>> break
>> }
>> }
>> 
>> // Proposed:
>> 
>> /*
>> enum theNewWay {
>>  case a( value: Int ) :
>>  case a( value: String ) :
>> }
>> 
>> switch theCurrentWay {
>> case .a( let x: Int ) :
>> break
>> 
>> case .a( let x: String ) :
>>     break
>> }
>> */
>> 
>> 
&

Re: [swift-evolution] [draft] Compound Names For Enum Cases

[Christopher Kornher via swift-evolution]

Sorry for not connecting the dots…yet another example of why we need a better 
way to handle long discussions :)
…and the dangers of multitasking, perhaps…

I guess that this shows that having multiple cases with the same name, 
distinguished by the type of associated value, is possible without this 
proposal, for whatever that may be worth.

It is anecdotal, perhaps, but this proposal will break a lot of my code. I tend 
to use labels as public names for associated values, and different internal 
names. Forcing consistent naming is sensible. It would come at the cost of 
breaking a significant amount of existing code and making the language more 
“fiddly”.

Comparisons have been made to function signatures, but enums cases with > 2 
values are rare in my experience, and functions can often have  > 2 arguments. 
Perhaps enums with more associated values will become more common if enum cases 
become more like structure declarations with well defined element names.

Just a random thought: Treating enum cases like structs would become more 
reasonable as a result of this proposal i.e. they could conform to protocols. I 
am not sure that anyone wants to worry about functions for enum cases, but it 
might be useful to pass enum cases directly to functions that would normally 
need a struct. Unifying enums and structs in this way might an interesting 
thing to consider. 

Associated values that can differ for each enum case seems to be a feature 
unique to Swift. Is this a feature of any other language?

> On Jan 24, 2017, at 4:55 PM, Xiaodi Wu via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Yes, but *this* proposal is precisely to make the label part of the name.
> 
> 
> On Tue, Jan 24, 2017 at 17:51 Christopher Kornher <ckorn...@me.com 
> <mailto:ckorn...@me.com>> wrote:
>> On Jan 24, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> I'm now confused who is arguing for what. Enums cases cannot have the same 
>> name. As far as I'm aware, this proposal does not seek to change that. Each 
>> case must still be unique. It only changes whether labels are regarded as 
>> part of the name or part of the associated type.
> 
> Labels are currently neither part of the name nor part of the associated 
> type. See my example (it runs in the playground in Xcode 8.2.1).
> 
> Forgive any lack of precise terminology:  Labels for enums with associated 
> values are currently only used to create a "function signature" for 
> constructing values for the enum. They are ignored in all other uses of the 
> enum AFAIK.
> 
> My proposal is a way to allow multiple cases with the same name without 
> breaking existing code. It has the benefit of giving enums a richer meaning, 
> in simple English:
> 
> Here is an example of a way to handle this currently and what it would become:
> 
> // Runs now
> enum MultipleTypes {
> case anInt( value: Int )
> case aString( value: String )
> }
> 
> enum E {
> case a( a: MultipleTypes )
> }
> 
> let theCurrentWay = E.a( a: .aString( value: "str") )
> 
> switch theCurrentWay {
> case .a( let x ) :
> switch x {
> case .anInt( let x ) :
> break
> 
> case .aString( let x ) :
> break
> }
> }
> 
> // Proposed:
> 
> /*
> enum theNewWay {
>      case a( value: Int ) :
>  case a( value: String ) :
> }
> 
> switch theCurrentWay {
> case .a( let x: Int ) :
> break
> 
> case .a( let x: String ) :
> break
> }
> */
> 
> 
>> 
>> 
>> On Tue, Jan 24, 2017 at 17:16 Christopher Kornher via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> On Jan 24, 2017, at 4:02 PM, Daniel Duan <dan...@duan.org 
>>> <mailto:dan...@duan.org>> wrote:
>>> 
>>> 
>>> 
>>> Daniel Duan
>>> Sent from my iPhone
>>> 
>>> On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> 
>>>> 
>>>> Daniel Duan
>>>> Sent from my iPhone
>>>> 
>>>> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>>> I agree that  this rule would be consistent with the handing of Swift 
>>>>> function signatures, but my proposal is self-consistent and:
>>>>> 
>>>>> 1) It is more

Re: [swift-evolution] [draft] Compound Names For Enum Cases

[Christopher Kornher via swift-evolution]

> On Jan 24, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> I'm now confused who is arguing for what. Enums cases cannot have the same 
> name. As far as I'm aware, this proposal does not seek to change that. Each 
> case must still be unique. It only changes whether labels are regarded as 
> part of the name or part of the associated type.

Labels are currently neither part of the name nor part of the associated type. 
See my example (it runs in the playground in Xcode 8.2.1).

Forgive any lack of precise terminology:  Labels for enums with associated 
values are currently only used to create a "function signature" for 
constructing values for the enum. They are ignored in all other uses of the 
enum AFAIK.

My proposal is a way to allow multiple cases with the same name without 
breaking existing code. It has the benefit of giving enums a richer meaning, in 
simple English:

Here is an example of a way to handle this currently and what it would become:

// Runs now
enum MultipleTypes {
case anInt( value: Int )
case aString( value: String )
}

enum E {
case a( a: MultipleTypes )
}

let theCurrentWay = E.a( a: .aString( value: "str") )

switch theCurrentWay {
case .a( let x ) :
switch x {
case .anInt( let x ) :
break

case .aString( let x ) :
break
}
}

// Proposed:

/*
enum theNewWay {
 case a( value: Int ) :
 case a( value: String ) :
}

switch theCurrentWay {
case .a( let x: Int ) :
break

case .a( let x: String ) :
break
}
*/


> 
> 
> On Tue, Jan 24, 2017 at 17:16 Christopher Kornher via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> On Jan 24, 2017, at 4:02 PM, Daniel Duan <dan...@duan.org 
>> <mailto:dan...@duan.org>> wrote:
>> 
>> 
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
>> On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
>>> 
>>> Daniel Duan
>>> Sent from my iPhone
>>> 
>>> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> I agree that  this rule would be consistent with the handing of Swift 
>>>> function signatures, but my proposal is self-consistent and:
>>>> 
>>>> 1) It is more powerful, matching on the case name or not as required.
>>>> 2) Is consistent with existing switches that ignore associated values
>>>> 3) Is constant with ignored labels in other Swift constructs (proposed and 
>>>> in past versions of Swift, at least)
>>>> 4) Avoids a possible API change for current enums. This is currently legal 
>>>> but would not be if the enum case “name” is the entire signature for 
>>>> constructing it:
>>>> 
>>>> ```
>>>> enum E {
>>>> case a( a: Int )
>>>> case b( a: Int )
>>>> }
>>>> 
>>>> let anEmum = E.a( a: 4 )
>>>> 
>>>> 
>>>> switch anEmum {
>>>> case .a( let x ) :
>>>> break
>>>> case .b( let x ) :
>>>> break
>>>> }
>>>> 
>>>> switch anEmum {
>>>> case .a( let y ) :
>>>> break
>>>> 
>>>> case .b( let y ) :
>>>> break
>>>> }
>>>> ```
>>>> So is this proposal worth creating a breaking change? I don’t think so.  
>>>> it would be possible to ignore the associated parameter name, but not the 
>>>> type, but that would further confuse case matching, I believe.
>>>> 
>>>> I personally don’t see much purpose in having two enum cases with the same 
>>>> name if they are always treated as distinct and there is no way to reason 
>>>> on the case name.
>>> 
>>> Would you say the same for functions? Our opinions differ in what 
>>> constitute a "name". In Swift, function names include parameters. Each enum 
>>> case declares a function that creates a enum value. That's why it's *more* 
>>> consistent for enum to have a similar definition of "name".
>>> 
>>> As for pattern matching, number of patterns the number of cases being 
>>> matched have a many-to-one relationships. This is true in Swift and many 
>>> 
>> 
>> (Ah, accidentally sent it on my iPhone. My apolog

Re: [swift-evolution] [draft] Compound Names For Enum Cases

[Christopher Kornher via swift-evolution]

> On Jan 24, 2017, at 4:02 PM, Daniel Duan <dan...@duan.org> wrote:
> 
> 
> 
> Daniel Duan
> Sent from my iPhone
> 
> On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
>> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> I agree that  this rule would be consistent with the handing of Swift 
>>> function signatures, but my proposal is self-consistent and:
>>> 
>>> 1) It is more powerful, matching on the case name or not as required.
>>> 2) Is consistent with existing switches that ignore associated values
>>> 3) Is constant with ignored labels in other Swift constructs (proposed and 
>>> in past versions of Swift, at least)
>>> 4) Avoids a possible API change for current enums. This is currently legal 
>>> but would not be if the enum case “name” is the entire signature for 
>>> constructing it:
>>> 
>>> ```
>>> enum E {
>>> case a( a: Int )
>>> case b( a: Int )
>>> }
>>> 
>>> let anEmum = E.a( a: 4 )
>>> 
>>> 
>>> switch anEmum {
>>> case .a( let x ) :
>>> break
>>> case .b( let x ) :
>>> break
>>> }
>>> 
>>> switch anEmum {
>>> case .a( let y ) :
>>> break
>>> 
>>> case .b( let y ) :
>>> break
>>> }
>>> ```
>>> So is this proposal worth creating a breaking change? I don’t think so.  it 
>>> would be possible to ignore the associated parameter name, but not the 
>>> type, but that would further confuse case matching, I believe.
>>> 
>>> I personally don’t see much purpose in having two enum cases with the same 
>>> name if they are always treated as distinct and there is no way to reason 
>>> on the case name.
>> 
>> Would you say the same for functions? Our opinions differ in what constitute 
>> a "name". In Swift, function names include parameters. Each enum case 
>> declares a function that creates a enum value. That's why it's *more* 
>> consistent for enum to have a similar definition of "name".
>> 
>> As for pattern matching, number of patterns the number of cases being 
>> matched have a many-to-one relationships. This is true in Swift and many 
>> 
> 
> (Ah, accidentally sent it on my iPhone. My apologies.)
> 
> … other languages. What you are proposing complicates the rules by making 
> this untrue. We'd have to special-case this feature in our pattern matching 
> algorithm.

I am not proposing a breaking change. I believe that it is the best way to 
handle “overloading” enum names without breaking existing code. I don’t believe 
that this proposal changes any existing logic or rules.

The use of the terms "name” and "signature" is well established in many 
languages. e.g.: https://en.wikipedia.org/wiki/Type_signature 
<https://en.wikipedia.org/wiki/Type_signature> I am trying to use the terms in 
this context.

Sharing a function name (with different signatures)  is an aid to understanding 
the purpose of functions and is part of many languages. I do not believe that 
extending the concept to enums is worth the cost, especially since it will 
break existing Swift code.

You are proposing a source breaking change and I do not agree that is is an 
improvement. What is the benefit of this change?


> 
>>> If they are always distinct, then requiring different names eliminates 
>>> unnecessary cognitive load. There is a good reason for functions to have 
>>> the same “name” and different signatures, and there are precedents in many 
>>> languages. 
>>> 
>>> You may disagree, but I believe that enums exist to support reasoning on 
>>> distinct cases and that muddying that by treating the associated value as 
>>> part of the “signature" increases the language “surface area” while adding 
>>> no tangible benefit.
>>> 
>>> 
>>>> On Jan 24, 2017, at 2:23 PM, Matthew Johnson via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>>> 
>>>>> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution 
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>&

Re: [swift-evolution] [draft] Compound Names For Enum Cases

[Christopher Kornher via swift-evolution]

I agree that  this rule would be consistent with the handing of Swift function 
signatures, but my proposal is self-consistent and:

1) It is more powerful, matching on the case name or not as required.
2) Is consistent with existing switches that ignore associated values
3) Is constant with ignored labels in other Swift constructs (proposed and in 
past versions of Swift, at least)
4) Avoids a possible API change for current enums. This is currently legal but 
would not be if the enum case “name” is the entire signature for constructing 
it:

```
enum E {
case a( a: Int )
case b( a: Int )
}

let anEmum = E.a( a: 4 )


switch anEmum {
case .a( let x ) :
break
case .b( let x ) :
break
}

switch anEmum {
case .a( let y ) :
break

case .b( let y ) :
break
}
```
So is this proposal worth creating a breaking change? I don’t think so.  it 
would be possible to ignore the associated parameter name, but not the type, 
but that would further confuse case matching, I believe.

I personally don’t see much purpose in having two enum cases with the same name 
if they are always treated as distinct and there is no way to reason on the 
case name. If they are always distinct, then requiring different names 
eliminates unnecessary cognitive load. There is a good reason for functions to 
have the same “name” and different signatures, and there are precedents in many 
languages. 

You may disagree, but I believe that enums exist to support reasoning on 
distinct cases and that muddying that by treating the associated value as part 
of the “signature" increases the language “surface area” while adding no 
tangible benefit.


> On Jan 24, 2017, at 2:23 PM, Matthew Johnson via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Your example is only has only one case, which is not typical. Perhaps I am 
>> missing something, but the only reason that I can imagine for having a case 
>> with multiple ways to “construct” it is to have all variants of the case to 
>> match. If you don’t want them to match, use a different case name. 
> 
> It sounds like you are missing something.  The `bar(a:)` and `bar(b:)` are 
> the full case names.  These are *not* the same case.  The `bar` shorthand is 
> allowed when there is no ambiguity, however for an enum with both `bar(a:)` 
> and `bar(b:)` there *is* ambiguity and therefore the `bar` shorthand is not 
> allowed.  The programmer is required to spell out the full name of the case 
> they wish to match.
> 
> 
>> 
>> It would still be possible to match on the different types of bar when 
>> needed:
>> 
>> ```
>> enum Foo {
>> case bar(a: Int)
>> case bar(b: String)
>> case notAbar
>> }
>> 
>> 
>>  switch aFoo {
>> case .bar( let a: Int) : // matches Ints only 
>>  ...
>> 
>> case .bar( let b: String) : // matches Strings only
>>...
>> }
>> 
>> switch aFoo {
>> case .bar :  // Matches both  cases and that is a good thing
>>  …
>> 
>> case notAbar:
>>  ….
>> }
>> 
>> ```
>> 
>>> On Jan 24, 2017, at 5:27 AM, Xiaodi Wu via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I would imagine it would be logical to have it work just like it does now 
>>> with functions. If case bar is distinct, then that should still work, but 
>>> if bar is "overloaded," then case bar should be invalid for ambiguity. 
>>> Seems fine to me, shouldn't break any existing code and therefore we don't 
>>> lose anything.
>>> 
>>> 
>>> On Tue, Jan 24, 2017 at 01:13 David Hart via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> We're not terribly principled about this right now with non-pattern 
>>>> declaration references. You can still reference an unapplied function by 
>>>> its base name alone without its labels, if it's unambiguous:
>>>> 
>>>> func foo(x: Int, y: Int) {}
>>>> 
>>>> let foo_x_y: (Int, Int) -> () = foo
>>>> 
>>>> so it'd be consistent to continue to allow the

Re: [swift-evolution] [draft] Compound Names For Enum Cases

[Christopher Kornher via swift-evolution]

Your example is only has only one case, which is not typical. Perhaps I am 
missing something, but the only reason that I can imagine for having a case 
with multiple ways to “construct” it is to have all variants of the case to 
match. If you don’t want them to match, use a different case name. 

It would still be possible to match on the different types of bar when needed:

```
enum Foo {
case bar(a: Int)
case bar(b: String)
case notAbar
}


 switch aFoo {
case .bar( let a: Int) : // matches Ints only 
...

case .bar( let b: String) : // matches Strings only
   ...
}

switch aFoo {
case .bar :  // Matches both  cases and that is a good thing
…

case notAbar:
….
}

```

> On Jan 24, 2017, at 5:27 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I would imagine it would be logical to have it work just like it does now 
> with functions. If case bar is distinct, then that should still work, but if 
> bar is "overloaded," then case bar should be invalid for ambiguity. Seems 
> fine to me, shouldn't break any existing code and therefore we don't lose 
> anything.
> 
> 
> On Tue, Jan 24, 2017 at 01:13 David Hart via swift-evolution 
> > wrote:
> 
> 
> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution 
> > wrote:
> 
>> We're not terribly principled about this right now with non-pattern 
>> declaration references. You can still reference an unapplied function by its 
>> base name alone without its labels, if it's unambiguous:
>> 
>> func foo(x: Int, y: Int) {}
>> 
>> let foo_x_y: (Int, Int) -> () = foo
>> 
>> so it'd be consistent to continue to allow the same in pattern references.
> 
> WRT ambiguity, do we loose the ability to pattern match on the naked case 
> name when two cases share the same base name?
> 
> enum Foo {
> case bar(a: Int)
> case bar(b: String)
> }
> 
> switch aFoo {
> case .bar: // matches both cases
> break
> }
> ___
> 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] Move placement of 'throws' statement

[Christopher Kornher via swift-evolution]

-1 for addressing this now. Typed throws will undoubtedly affect this change 
and the two issues should be addressed at the same time.

As a Java veteran, I agree with the sentiment to avoid the Java exception 
typing mechanism which complicates using and maintaining large projects. 
Knowing the recoverable exceptions that a function can throw cane be useful, 
however, and some sort of optional listing of exception types is probably the 
best solution.


> On Dec 28, 2016, at 2:36 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> TLDR: I support moving throws, and also think that ‘typed throws’ should fit 
> for Phase 2, at least.
> 
> let x : (_ a : Int) -> (_ b: Float) throws -> Double throws
> Count me in those who cried in anger :)
> 
> I see why current syntax is very logical for currying:
> 
> let x: (Int) throws -> (Float) throws -> Double   // clean
> 
> let x: (Int) -> (Float) -> Double throws throws   // looks ambiguous
> Although, the ambiguity can be resolved using parentheses:
> 
> let x: (Int) -> ((Float) -> Double throws) throws
> 
> let x: (Int) -> ((Float) -> Double throws Error2) throws Error1   // with 
> 'typed throws'
> Compare it to how we incorporate optionals (which are just another form of 
> error handling) in curried functions now:
> 
> let x: (Int) -> ((Float) -> Double?)?
> Overall, current Swift syntax is uniquely nice to error handling in curried 
> functions. Is it worth keeping this advantage? Probably not, if the new form 
> does not contain too much noise and is even more logical. Everything slides 
> into place, if throws is a binary operator on types with precedence higher 
> than ->. Although A throws B is not a type on itself, I can clearly see it 
> becoming one in the future. Then try will handle pattern matching of such 
> types.
> 
> Another point for the suggested syntax: as we now know, Swift users prefer to 
> see results after -> in function declarations. Is it stretching too far to 
> conclude that error type is a possible result, and should also come after ->?
> 
> ___
> 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] Add the DefaultConstructible protocol to the standard library

[Christopher Kornher via swift-evolution]

-1

1) There is no semantic meaning to empty initializers.

2) It is a simple protocol to create and apply for specific (and semantically 
meaningful) purposes

3) This would be a core protocol and I defer to the team. when it comes to 
low-level protocols. This seems to be in conflict with their vision. There are 
already concrete solutions for potential uses (e.g. Initializing Arrays).

- Chris K


> On Dec 27, 2016, at 12:52 AM, Rien via swift-evolution 
>  wrote:
> 
> +1
> 
> Why? well… that is difficult. Mainly because it “feels” right.
> Having read a lot of the discussion (but not all) it seems impossible to make 
> a “must have” case for it. But on a more conceptual level this feels similar 
> to the discovery of zero in mathematics.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
> 
> 
> 
> 
>> On 27 Dec 2016, at 04:01, Daniel Leping via swift-evolution 
>>  wrote:
>> 
>> I can totally agree that it's not something to deal with Zero concept.
>> 
>> Though discussion was completely lost for another use case of _generic 
>> factories_.
>> 
>> Also, the interesting part is that discussion brought us to the question if 
>> Bool.init(), Int.init() and alike should be removed. I'm 100% positive here 
>> as it brings a lot of uncertainty.
>> 
>> In general, I think if we remove inits described above, DefaultConstructable 
>> will be more appealing. I don't see it as a Zero, but rather as a default 
>> factory.
>> 
>> Best,
>> Daniel
>> 
>> On Tue, 27 Dec 2016 at 3:30 Adam Nemecek via swift-evolution 
>>  wrote:
>>> Huh? You just said that one usage scenario was the allocation of buffers of 
>>> known size. If you're unsatisfied with the API for that, you're welcome to 
>>> propose better ones. The point is that this is not a convincing use case, 
>>> as you claim, for `DefaultConstructible`, but rather for better buffer APIs.
>> 
>> I've brought up several situation where I'd use these. I don't want a better 
>> buffer API, I want a way of expressing myself in a way that seems natural to 
>> me.
>> 
>>> There is no nexus between comparability and "some sort of origin or zero" 
>>> from which to measure absolute distance, as you state.
>> 
>> There is. Elements are equal if the distance between them is zero. Why does 
>> Comparability also require Equatability?
>> 
>>> Ooh boy. There is no worldview in music that "doesn't say anything about 
>>> intervals," I can assure you of that.
>> 
>> https://github.com/midiguchi/midiguchi
>> 
>> Do you see the zip operation? Could you tell me what it does? Note that I 
>> have no relationship to this project. I can find more if I really try. So 
>> now there is a precedence, so what's next? Are you going to tell me that 
>> this doesn't count? Why not?  I was aware of this library even before this 
>> discussion btw.
>> 
>>> No, I mean that you are incorrect.
>> 
>> Well if you say so it must be true. Lol. 
>> 
>>> What closure property? My question was, why are you not using `Strideable`? 
>>> You are describing its semantics. I'm not sure what closure you are 
>>> referring to.
>> 
>> Algebraic closure.
>> 
>>> As I explained earlier, your argument _is_ circular. But it's clear now you 
>>> will not accept that being point out to you by multiple people 
>>> independently.
>> 
>> It's not circular, it's I use data point to point out that this is a common 
>> pattern.
>> 
>> 
>> 
>> On Mon, Dec 26, 2016 at 1:43 PM, Xiaodi Wu  wrote:
>> On Mon, Dec 26, 2016 at 4:28 PM, Adam Nemecek  wrote:
>>> `ManagedBuffer` is the standard library base class that offers facilities 
>>> for managing buffers. If there's a concrete use case that isn't served, 
>>> then the argument would be to improve `ManagedBuffer` or to design other 
>>> types or protocols for that use case, not to add a protocol to conform 
>>> every type that implements `init()`.
>> 
>> I'd prefer not to deal with raw storage unless necessary. 
>> 
>> Huh? You just said that one usage scenario was the allocation of buffers of 
>> known size. If you're unsatisfied with the API for that, you're welcome to 
>> propose better ones. The point is that this is not a convincing use case, as 
>> you claim, for `DefaultConstructible`, but rather for better buffer APIs.
>> 
>>> The distance between two values of type T does not itself need to be of 
>>> type T,
>> 
>> Never said otherwise.
>> 
>>> Moreover, one can have distances being strideable opaque types that can't 
>>> even be initialized 
>> 
>> You sure can. Doesn't disprove any of my points.
>> 
>> Sure it does. You asserted that where a type is comparable, it "generally" 
>> makes sense to measure distance from "some sort of origin or zero." And I'm 
>> showing you why it does not generally make sense at all. There is no nexus 

Re: [swift-evolution] Why is AnyObject's bridging so weird in Swift 3?

[Christopher Kornher via swift-evolution]

> On Dec 12, 2016, at 2:09 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Dec 12, 2016, at 12:59 PM, Charles Srstka > > wrote:
>> 
>>> On Dec 12, 2016, at 2:46 PM, Joe Groff >> > wrote:
>>> 
>>> Everything *can* be bridged to an object as a result of SE-0116 
>>> ("id-as-Any"), so there's no longer such a thing as a "non-bridgable value 
>>> type”.
>> 
>> Ah, so that arbitrary Swift types can be stashed in Objective-C userInfo 
>> dictionaries and the like. Of course. Still wish this could have just 
>> happened at the bridge, as part of whatever magic converts Arrays to 
>> NSArrays, Dictionaries to NSDictionaries, etc. Oh well.
>> 
>>> #6 is a bug, since the AnyObject method lookup ought to produce `nil` if 
>>> the ObjC method isn't implemented on the object.
>> 
>> Good to know that it’s a bug. Hopefully it’ll get fixed in a future release 
>> (or at least warn if the ? isn’t before the parens).
>> 
>> By the way, while we’re at it, I managed to find a way to get the property 
>> version to crash by leaving out some question marks, as well:
>> 
>> print((s as AnyObject).foo as Any) // fatal error: unexpectedly found nil 
>> while unwrapping an Optional value
>> 
>> Interestingly, it works in the context of string interpolation. 'print("\((s 
>> as AnyObject).foo)”)’ prints nil, just like you’d expect. It’s just when you 
>> pass it straight to print that the crash happens. Once again, the compiler 
>> doesn’t give us any kind of warning about this.
>> 
 2. Why is there no obvious way to figure out whether something can 
 actually be an object? The already kind of non-obvious “type(of: s) is 
 AnyObject.Type” trick works to tell you if the thing is already a class, 
 but not if something is bridgeable to a class; using it on a string, for 
 example, returns false. And trying something like “type(of: s as 
 AnyObject) is AnyObject.Type” returns true (?!), so that doesn’t work to 
 detect bridgeable things.
>>> 
>>> What are you trying to do that requires you to know whether something is a 
>>> class or bridgable to a class (which, as mentioned above, includes 
>>> everything)?
>> 
>> The immediate use case? Avoiding the crash on #6. ;-) At least there turned 
>> out to be a workaround on that.
>> 
>> Beyond that? Making the whole thing less head-hurtingly complicated, and 
>> avoiding random crashing bugs popping up due to the difficulty of completely 
>> reasoning about how the whole thing works. But I was a fan of the lamentably 
>> departed SE-0083, so grumble, grumble.
> 
> Yeah, it would be nice if we could revisit SE-0083. I think it's still doable 
> in a way that could localize the dynamic bridging complexity to Anys that 
> were sourced from Objective-C.
> 
> -Joe

+1 Perhaps adding a way to specify “bridgeability” e.g. 

struct S : AutoBridged {}



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

Re: [swift-evolution] Passing class protocols to functions accepting AnyObject

[Christopher Kornher via swift-evolution]

This issue bites me frequently and is a barrier to clean "protocol-based” 
programming. This is extremely counter-intuitive to me, at least. Not having a 
good workaround for this really makes the language seem incomplete.

Recently I had the need to use instances of a protocol as keys in a dictionary 
(yes, there was a very good reason for it). I assume that this was the reason 
that I could get it to work. I ended-up having the use instances of an abstract 
class, but of course, the powers that be think that abstract classes should be 
second-class citizens in Swift. This is off-topic, but not having a good 
construct for abstract methods was a mistake in Obj-C and it is a mistake in 
Swift.

- Chris


> On Dec 6, 2016, at 12:30 PM, Андрей Володин via swift-evolution 
>  wrote:
> 
> Been struggling with this kind of problem. My case: I have an array of class 
> protocol and can’t use my extension that removes AnyObject from array by 
> comparing pointers via ===. 
> ___
> 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] Add code to super methods.

[Christopher Kornher via swift-evolution]

If memory serves: the CLOS Metaobject Protocol had features like this. This 
might be good read if you are considering writing a proposal for this. (Dylan 
Lives! :) )

https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Protocol 


As I remember, these sorts of features did have scalability issues.


> On Nov 17, 2016, at 3:54 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> An equivalent of "NS_REQUIRES_SUPER" (hopefully with a better name ;-) has 
> been requested several times, but never got the momentum it deserves.
> Considering the current confusion (especially in UIKit), it would be really 
> nice to have some help from the compiler, and I wonder how composition and 
> protocols would be helpful here at all.
> 
> I guess the problem is that there are to many options for this feature 
> without an obvious favorite: Not only for the keywords, but also for the 
> exact semantic.
> 
> Additionally, there are imho already to many access levels (private, 
> fileprivate, internal, public, extendable?, open), so I hope we'll someday 
> find a solution that is powerful enough to replace the special willSet/didSet 
> treatment for properties as well.
> 
> So unless somebody has a real flash of genius, I guess it's better to delay 
> discussion until there is a chance for new proposals to be accepted.
> 
> Tino
> ___
> 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] Keyword for protocol conformance

[Christopher Kornher via swift-evolution]

> On Aug 25, 2016, at 4:32 PM, Christopher Kornher <ckorn...@me.com> wrote:
> 
> I hope that my brief email wasn’t the final word on this :(
> 
> Does anyone think that a proposal to require “override” for overrides of 
> protocol extension methods and variables (?) would be worth exploring?
> 
> This would address a number of the issues raised in this thread, but not all.
> 
> My intention is not to derail this thread, and I believe that the original 
> topic of this thread, explicit protocol conformance, is worth exploring. I 
> respond here because of these topics are strongly related. I will start a new 
> thread, if there is interest.
> 
> It is possible that tooling could address the remaining issues with 
> overrides. JetBrains products, for example, provide navigable icons to 
> overridden methods. There is no reason that Xcode and other tools could not 
> automatically insert indicators like:
> 
> ```
> class MyClass: MyProtocol {
> 
>   < conforms >
>   func myMethod() -> String {
>   return “..."
>   }
> 
> class MyClass2: MyProtocol1, MyProtocol2 {
> 
>   < conforms MyProtocol2 >
>   func myMethod() -> String {
>   return “..."
>   }
> ```
> Of course, there is no reason that tooling can’t replace “override” 
> completely:
> 
> ```
> class MyClass: MyOtherClass, MyProtocol1, MyProtocol2 {
> 
>   < conforms MyProtocol2 >
>   < overrides TheParentClassOfMyOtherClass>
>   func myMethod() -> String {
>   return “..."
>   }
> ```
> 
> Replace "<…>” with the navigable graphic of your choice and assume that user 
> preferences would exist to show/hide these indicators.
> 
> 

My cut and paste error left out this part:

The roles of language and tooling in making code understandable is largely a 
matter of opinion. I personally like the current use of “override” since 
overriding is a common cause of serious programming errors and a mechanism for 
protecting against them should be built into the language and now, extended to 
overrides of protocol extensions.

It is interesting that adding “override” to structs and enums would help to 
open the door to true inheritance (not polymorphism) for structs and possibly 
even enums, if anyone knows of a use for that. This is a feature that I could 
have used on a few projects, but there are far more important features in the 
queue, and that discussion should probably wait until after Swift 4, if it 
happens at all.


- Chris K



>> On Aug 24, 2016, at 11:13 AM, Christopher Kornher via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Requiring "override" when anything overrides a method defined in a protocol 
>> extension should be added - structure and enumerated included, of course.
>> 
>> Protocol extensions added inheritance to structs and enums and this should 
>> be made explicit.
>> 
>> Sent from my iPad
>> 
>> On Aug 24, 2016, at 12:55 AM, Charles Srstka via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>>> On Aug 24, 2016, at 1:20 AM, Robert Widmann <devteam.cod...@gmail.com 
>>>> <mailto:devteam.cod...@gmail.com>> wrote:
>>>> 2016/08/23 20:52、Charles Srstka <cocoa...@charlessoft.com 
>>>> <mailto:cocoa...@charlessoft.com>> のメッセージ:
>>>> 
>>>>>> On Aug 23, 2016, at 10:34 PM, Robert Widmann <devteam.cod...@gmail.com 
>>>>>> <mailto:devteam.cod...@gmail.com>> wrote:
>>>>>> 
>>>>>> 2016/08/23 15:29、Charles Srstka <cocoa...@charlessoft.com 
>>>>>> <mailto:cocoa...@charlessoft.com>> のメッセージ:
>>>>>> 
>>>>>>>> On Aug 23, 2016, at 2:33 PM, Robert Widmann via swift-evolution 
>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>>>> 
>>>>>>>> 2016/08/22 14:30、David Cordero via swift-evolution 
>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> のメッセージ:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> The problem:
>>>>>>>>> At the moment, looking at the code of a class or a struct 
>>>>>>>>> implementing a protocol, it is hard to know what methods are actually 
>>>>>>>>> implementing the protocol and what othe

Re: [swift-evolution] Keyword for protocol conformance

[Christopher Kornher via swift-evolution]

I hope that my brief email wasn’t the final word on this :(

Does anyone think that a proposal to require “override” for overrides of 
protocol extension methods and variables (?) would be worth exploring?

This would address a number of the issues raised in this thread, but not all.

My intention is not to derail this thread, and I believe that the original 
topic of this thread, explicit protocol conformance, is worth exploring. I 
respond here because of these topics are strongly related. I will start a new 
thread, if there is interest.

It is possible that tooling could address the remaining issues with overrides. 
JetBrains products, for example, provide navigable icons to overridden methods. 
There is no reason that Xcode and other tools could not automatically insert 
indicators like:

```
class MyClass: MyProtocol {

< conforms >
func myMethod() -> String {
return “..."
}

class MyClass2: MyProtocol1, MyProtocol2 {

< conforms MyProtocol2 >
func myMethod() -> String {
return “..."
}
```
Of course, there is no reason that tooling can’t replace “override” completely:

```
class MyClass: MyOtherClass, MyProtocol1, MyProtocol2 {

< conforms MyProtocol2 >
< overrides TheParentClassOfMyOtherClass>
func myMethod() -> String {
return “..."
}
```

Replace "<…>” with the navigable graphic of your choice and assume that user 
preferences would exist to show/hide these indicators.


> On Aug 24, 2016, at 11:13 AM, Christopher Kornher via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Requiring "override" when anything overrides a method defined in a protocol 
> extension should be added - structure and enumerated included, of course.
> 
> Protocol extensions added inheritance to structs and enums and this should be 
> made explicit.
> 
> Sent from my iPad
> 
> On Aug 24, 2016, at 12:55 AM, Charles Srstka via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>>> On Aug 24, 2016, at 1:20 AM, Robert Widmann <devteam.cod...@gmail.com 
>>> <mailto:devteam.cod...@gmail.com>> wrote:
>>> 2016/08/23 20:52、Charles Srstka <cocoa...@charlessoft.com 
>>> <mailto:cocoa...@charlessoft.com>> のメッセージ:
>>> 
>>>>> On Aug 23, 2016, at 10:34 PM, Robert Widmann <devteam.cod...@gmail.com 
>>>>> <mailto:devteam.cod...@gmail.com>> wrote:
>>>>> 
>>>>> 2016/08/23 15:29、Charles Srstka <cocoa...@charlessoft.com 
>>>>> <mailto:cocoa...@charlessoft.com>> のメッセージ:
>>>>> 
>>>>>>> On Aug 23, 2016, at 2:33 PM, Robert Widmann via swift-evolution 
>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>>> 
>>>>>>> 2016/08/22 14:30、David Cordero via swift-evolution 
>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> のメッセージ:
>>>>>>> 
>>>>>>>> 
>>>>>>>> The problem:
>>>>>>>> At the moment, looking at the code of a class or a struct implementing 
>>>>>>>> a protocol, it is hard to know what methods are actually implementing 
>>>>>>>> the protocol and what other methods are just part of the code of the 
>>>>>>>> class or struct.
>>>>>>>> 
>>>>>>> 
>>>>>>> That seems like a feature, not a bug.  Why should I as an author care 
>>>>>>> whether a method contributes to a protocol conformance or not if the 
>>>>>>> compiler can tell me that kind of information itself?
>>>>>> 
>>>>>> Being able to reason about your code, what it does, and what it’s for is 
>>>>>> undesirable?
>>>>> 
>>>>> That's not an answer to the question I asked.  Why is this significant 
>>>>> enough to warrant an entire keyword?  The clutter of a whole keyword that 
>>>>> does nothing but wait for a developer to make a source-compatible 
>>>>> binary-breaking change to an interface does not seem worth it.  Maybe you 
>>>>> can convince me otherwise. 
>>>> 
>>>> Same reason overriding a class method warrants a keyword. It expresses the 
>>>> purpose more clearly, and allows the compiler to catch mistakes for us.
>>>> 
>>> 
>>> That's just it: The

Re: [swift-evolution] Keyword for protocol conformance

[Christopher Kornher via swift-evolution]

Requiring "override" when anything overrides a method defined in a protocol 
extension should be added - structure and enumerated included, of course.

Protocol extensions added inheritance to structs and enums and this should be 
made explicit.

Sent from my iPad

> On Aug 24, 2016, at 12:55 AM, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Aug 24, 2016, at 1:20 AM, Robert Widmann  wrote:
>> 2016/08/23 20:52、Charles Srstka  のメッセージ:
>> 
 On Aug 23, 2016, at 10:34 PM, Robert Widmann  
 wrote:
 
 2016/08/23 15:29、Charles Srstka  のメッセージ:
 
>> On Aug 23, 2016, at 2:33 PM, Robert Widmann via swift-evolution 
>>  wrote:
>> 
>> 2016/08/22 14:30、David Cordero via swift-evolution 
>>  のメッセージ:
>> 
>>> 
>>> The problem:
>>> At the moment, looking at the code of a class or a struct implementing 
>>> a protocol, it is hard to know what methods are actually implementing 
>>> the protocol and what other methods are just part of the code of the 
>>> class or struct.
>>> 
>> 
>> That seems like a feature, not a bug.  Why should I as an author care 
>> whether a method contributes to a protocol conformance or not if the 
>> compiler can tell me that kind of information itself?
> 
> Being able to reason about your code, what it does, and what it’s for is 
> undesirable?
 
 That's not an answer to the question I asked.  Why is this significant 
 enough to warrant an entire keyword?  The clutter of a whole keyword that 
 does nothing but wait for a developer to make a source-compatible 
 binary-breaking change to an interface does not seem worth it.  Maybe you 
 can convince me otherwise. 
>>> 
>>> Same reason overriding a class method warrants a keyword. It expresses the 
>>> purpose more clearly, and allows the compiler to catch mistakes for us.
>>> 
>> 
>> That's just it: The class of mistakes one can make by not being explicit 
>> about overrides is significantly more dangerous than the class of mistakes 
>> caused by dead code leftover from trimming protocols.
> 
> I am in the middle of a large refactor of code that was originally 
> Objective-C and then Swift written like Objective-C, to more idiomatic 
> protocol-oriented Swift. I am finding that in Swift’s POP idiom, protocols 
> with overrides are serving very nearly the same purpose that overrides were 
> serving in the old design; hence, I don’t really think either is more or less 
> dangerous than the other.
> 
>>> ```
>>> protocol MyProtocol {
>>> func myMethod() -> String
>>> }
>>> 
>>> class MyClass: MyProtocol {
>>> 
>>> conform func myMethod() -> String {
>>> return "Yuhuuu,I am conforming \\o//"
>>> }
>>> 
>>> func whatever() {
>>> print("I am a boring method and I don't conform anything")
>>> }
>>> }
>>> ```
>>> 
>>> It would be something similar to the current keyword `override` but for 
>>> protocols. 
>>> 
>>> Apart from improving code readability, It would allow the detection, in 
>>> compilation time, of errors due to code evolution. For example 
>>> redundant methods that no longer conform anything once the requirement 
>>> is removed from the protocol for whatever reason.
>> 
>> If you make a breaking change to a protocol like this, you should have 
>> gone through a deprecation cycle to indicate to your clients the 
>> appropriate changes you're going to make to the protocol.  This aspect 
>> of the change seems to if not encourage, highlight, bad behavior.
> 
> What if it’s your own code and all the callers are internal? What if 
> you’re still developing the protocol and haven’t released the API 
> interface yet?
 
 Then your concerns are local enough that you know where all 
 implementations of the protocol lie and whether they require deletion or 
 not.  The point about deprecation cycles still stands in all the cases you 
 mention.  Just because the interface is private doesn't mean you can't 
 take responsibility for keeping it as clean as you can.
 
> 
> Charles
> 
 
 tl;dr It seems like all of this can be subsumed by us warning about dead 
 code.
>>> 
>>> Did you look at my examples earlier in the thread? Neither of those would 
>>> be caught by warning about dead code.
>> 
>> The example involving the default implementation is most compelling, but it 
>> indicates that your proposed solution should focus on the protocol extension 
>> and not the implementing declaration.  Perhaps reusing one of our existing 
>> keywords can help here
>> 
>> protocol P {
>>   func foo() {}
>> }
>> 
>> extension P {
>>   default 

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Christopher Kornher via swift-evolution]

My 2 cents:

Generic errors have caused me problems on multiple occasions.They often make it 
difficult to handle and pass-through arbitrary errors. This pseudo Swift3 code 
is what I have resorted to doing on some projects. 

```
enum MyError : Error
{
…

case wrappedError( Error )
}
```

I would go so far as to say that generic errors are an anti-pattern in Swift.

- Chris 


> On Aug 14, 2016, at 6:04 PM, Jon Shier via swift-evolution 
>  wrote:
> 
>   Yes, if you return a single error type it works fine. However, since 
> Alamofire wraps the underlying networking frameworks there’s a need to return 
> the errors returned from them as well, which are now returned as Error. In 
> order to let these errors be returned alongside Alamofire’s errors we’d 
> either have to get rid of the generic error and just use Error or wrap all 
> errors in our error type. So far the least painful method seems to be just 
> getting rid of the generic error and returning Error for everything. That way 
> users will use the same logic they would have had to use anyway and can also 
> provide their own error wrapper if they want. Thankfully (or unfortunately, 
> depending on your point of view), the new pattern is to cast out the various 
> error types, so the previous concern about having to do that is no longer an 
> issue.
> 
> 
> Jon
> 
>> On Aug 14, 2016, at 4:18 AM, Charles Srstka > > wrote:
>> 
>>> On Aug 14, 2016, at 2:34 AM, Jon Shier >> > wrote:
>>> 
>>> Sorry Charles, I should’ve been more specific. This isn’t about some 
>>> other type named Error being usable, but about our doubly generic Result 
>>> and other types being usable with Error as the generic error type. If we 
>>> have Result defined as:
>>> 
>>> public enum Result {
>>> case success(Value)
>>> case failure(ErrorType)
>>> }
>>> 
>>> then attempting to create the type Result results in the 
>>> error message I posted. For methods that previously returned 
>>> Result, where the NSError is either a system error or an 
>>> Alamofire one, this is something of a problem. Of course, removing the 
>>> generic error type fixes this but may have an undesirable usability impact, 
>>> as making Result double generic was the primary reason behind the quick 
>>> upgrade between Alamofire 2 and 3. I think it’s less of a problem now, as 
>>> having to enumerate all of the different expected error types is how user’s 
>>> are supposed to interact with Error in the first place, but at the time it 
>>> wasn’t desirable to try and force everything through ErrorProtocol for that 
>>> reason. Perhaps this is a good compromise, where instead of returning all 
>>> NSErrors from the framework and allowing consumers to add their own to the 
>>> mix we’ll just create our own AFError type (whether enum or struct) and 
>>> then anything coming back will have to be checked for that type in addition 
>>> to the system types. From my testing it looks like users could still wrap 
>>> everything coming in by capturing the underlying Error.
>> 
>> Still seems to be working well, unless I’m misunderstanding what you’re 
>> trying to do:
>> 
>> import Foundation
>> 
>> enum Result {
>> case success(Value)
>> case failure(ErrorType)
>> }
>> 
>> struct MyThing {
>> enum Error: Swift.Error, LocalizedError {
>> case doesNotCompute
>> case imSorryDave
>> case mustSterilize
>> case irrelevant
>> case endOfLine
>> 
>> var failureReason: String? {
>> switch self {
>> case .doesNotCompute:
>> return "Does Not Compute! Does Not Compute! Does Not 
>> Compute!"
>> case .imSorryDave:
>> return "I'm sorry Dave, I'm afraid I can't do that."
>> case .mustSterilize:
>> return "Error! Must Sterilize! Must 
>> Steeeiiiizzeee"
>> case .irrelevant:
>> return "Irrelevant. Resistance is futile."
>> case .endOfLine:
>> return "End of Line!"
>> }
>> }
>> }
>> 
>> func trySomething(shouldWork: Bool, completionHandler: (Result> Error>) -> ()) {
>> if shouldWork {
>> completionHandler(.success("It worked!"))
>> } else {
>> completionHandler(.failure(Error.imSorryDave))
>> }
>> }
>> }
>> 
>> let thing = MyThing()
>> 
>> let completionHandler = { (result: Result) in
>> switch result {
>> case let .success(value):
>> print("returned '\(value)'")
>> case let .failure(error):
>> print("error: \(error.localizedDescription)")
>> }
>> }
>> 
>> thing.trySomething(shouldWork: true, 

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Christopher Kornher via swift-evolution]

Would this prevent an object from being “known" to multiple threads? …multiple 
queues? If so, it would be overly restrictive for a general-purpose language. I 
assume that the plan includes a way to allow “unsafe” behavior to support other 
concurrency models.


> On Aug 10, 2016, at 4:24 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> 
>> On Aug 10, 2016, at 3:22 PM, David Sweeris  wrote:
>> 
>>> On Aug 10, 2016, at 4:48 PM, Slava Pestov via swift-evolution 
>>>  wrote:
>>> 
>>> As I understand it, a big weakness of Go's model is that it does not 
>>> actually prevent data races. There's nothing preventing you from sharing 
>>> pointers to mutable values between tasks, but I could be wrong about this.
>> Is that bad? Sharing pointers seems like a cheap way to share data, and as 
>> long as you know what you’re doing, why should the language get in the way? 
>> Now, if said code really does have performance advantages over the “safer” 
>> methods, and it really is safe because for whatever reason the race 
>> condition can’t actually happen, the language (or library) ought to have a 
>> way to express that without having to write “unsafe” code. In the meantime, 
>> though, you’ve gotta ship something that runs and meets performance 
>> requirements.
> 
> Well, ideally, the type system would be able to enforce that values passed 
> across thread boundaries are immutable. Rust's model allows this, I believe.
> 
> The possibility of mutating shared state in an unprincipled manner is "bad" 
> in the same sense that being able to call free() in C is "bad" -- it's an 
> abstraction violation if you get it wrong. Compared to languages with 
> automatic memory management, there are advantages (control over memory 
> management) and disadvantages (fewer static guarantees).
> 
> 
>> 
>> - Dave Sweeris
> 
> ___
> 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] separate syntax of class inheritance and protocol conformance

[Christopher Kornher via swift-evolution]

-1 

I hope that this does not seem too hash but I think that this would be a 
gratuitous change and it would not provide any benefit to me. With protocol 
extensions, the difference between classes and protocols is not that great. As 
far as I am converted, this change would just complicate the syntax and add 
visual clutter.

I know that some language must have a similar feature, but I have never seen 
this feature in any other language and I have not missed it.

I fail to see how knowing if some “parent” of a class is a protocol or a class 
(and this is only an issue for classes) eliminates the need to actually look at 
the parent to determine its significance / capabilities.

- Chris


> On Aug 1, 2016, at 2:40 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
>> 
>> On Aug 1, 2016, at 10:22 PM, Haravikk via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 1 Aug 2016, at 19:05, Goffredo Marocchi via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> Sent from my iPhone
>>> 
 On 31 Jul 2016, at 21:19, Sean Alling via swift-evolution 
  wrote:
 
 I disagree with this suggestion.  Both a protocol conformance & class 
 inheritance define behavior conformance.  If anything the protocol is more 
 explicitly shown because the required properties and methods are conformed 
 to within its declaration.
>>> 
>>> Especially in a language without abstract classes, inheritance and protocol 
>>> conformance have a quite important distinction: protocols are about 
>>> decoupling concrete implementation from behaviour which is not what 
>>> inheritance allows or promises.
>> 
>> But is it a big enough case for its own syntax? I've had to work quite hard 
>> to break myself of old OOP habits, but I've now gotten pretty good at using 
>> protocols with extensions to do much of what I used abstract classes and 
>> such for (took a while though).
>> 
>> Even when I do use classes with inheritance, unless it's a very simple type 
>> I don't usually define protocol conformance as part of the type declaration, 
>> so I know the only thing up there will be inheritance; I put all my protocol 
>> conformances into extensions.
>> 
>> Also, I don't think it's that hard to figure out what a type represents, as 
>> you can alt-click in Xcode to quickly find out whether a type is a class or 
>> a protocol, and of course class inheritance is only possible on classes.
> 
> Xcode (or any other IDE) is not part of the language. Many people here are 
> still forgetting that. Saying that it's not an issue, since Xcode will do 
> this, will highlight that. Github doesn't have an Option-Click. Neither do 
> any other SCM-tools. Try to browse the stdlib on Github using a person seeing 
> the code for the first time.
> 
> Swift is aiming to be cross-platform - any argument that Xcode (or any other 
> IDE) can do something is IMHO irrelevant.
> 
> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

[Christopher Kornher via swift-evolution]

> On Jul 4, 2016, at 2:39 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> -1. I like the underscore. If it turns out you do need the loop variable 
> later, it's easy to see where to add it.
> 
> Karl

-1 I agree with this and doing something a specific number of  times without 
accessing the iteration counter is an edge case in my experience. Creating 
another syntax to save 4 characters for an edge case is a poor 
benefit/complexity tradeoff.  Ignoring with an underscore is universal in Swift 
and, to me at least, expressive and intuitive.

> 
> 
>> On Jul 1, 2016 at 9:38 AM, > > wrote:
>> 
>> When you want a simple `for` loop, for example:
>> 
>> for _ in 1...10 {
>> 
>> // do something 10 times
>> 
>> }
>> 
>> 
>> 
>> Clean-up and simplify the syntax by removing the superfluous underscore and 
>> `in`:
>> 
>> 
>> 
>> for 1...10 {
>> 
>> // do something 10 times
>> 
>> 
>> }
>> 
>> 
>> -- diego
>> ___ swift-evolution mailing list 
>> swift-evolution@swift.org  
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal] Sealed classes by default

[Christopher Kornher via swift-evolution]

> On Jun 28, 2016, at 2:31 PM, John McCall via swift-evolution 
>  wrote:
> 
>> On Jun 28, 2016, at 12:39 PM, Michael Peternell via swift-evolution 
>>  wrote:
>> Sealing classes by default is a terrible idea IMHO. Fortunately, my faith in 
>> the Swift core team is strong enough so that I cannot believe that this has 
>> a chance of ever being implemented at all :)
>> 
>> Why do I think it's terrible? I do subclass classes even when they say that 
>> you shouldn't do it. I even monkey-patched a few classes in the past. Why? 
>> Not because I prefer hacking over clean coding, but to get the job done. 
>> Every few months or so I encounter a situation where such hacking attempts 
>> are the only feasible way to make something work. Or I use them during 
>> research activities or unofficial "feasibility studies". (If that's not the 
>> case for you, then maybe you are working in a different job than I. Monkey 
>> patching is rarely necessary if you make iPhone apps.) These are situations 
>> where everyone else just says "that's not possible". Yes, you can make that 
>> USB driver class stop spamming the console; yes, you can stop that library 
>> from crashing randomly.
>> 
>> There is so much more to say on this topic. Sealing classes is also bad 
>> because it prevents forms of experimental coding. It doesn't solve a real 
>> problem. How often have I seen bugs where someone subclassed a class that 
>> shouldn't be subclassed? That's so rare. But if all classes are sealed by 
>> default this will lead to far worse problems. When a developer subclasses a 
>> class, he usually has a reason. There already is a `final` keyword in Swift, 
>> and a dev really thinks that a class shouldn't be subclass-able, he can use 
>> it already. And if I subclass it from Objective-C anyways, then maybe I know 
>> what I'm doing?
>> 
>> And I'm not buying this "performance" argument. If you want better 
>> performance, write the hot functions in C or maybe even in assembler. The 
>> dynamic dispatch overhead is not the feature that makes programs bad or 
>> slow. It's quadratic algorithms (e.g. unnecessary nested loops), calling 
>> functions multiple times (e.g. if(a.foo.bar(x[2]) == "joo" || 
>> a.foo.bar(x[2]) == "fooo" || a.foo.bar(x[2]) == nil) { ... }), or just 
>> overly complex code: all of them have more impact than dynamic dispatch. 
>> Even worse for performance is unnecessary IO or using graphics APIs 
>> inefficiently. A good profiler can help a lot with these issues.
>> 
>> Swift should be designed for the real world, not for an ideal world that 
>> does not exist and that will never exist.
> 
> The design intent of much of Swift is to allow "free" coding within a 
> module/file/type while encouraging programmers to think more carefully about 
> their public interfaces.  Module interfaces are the most serious and 
> permanent of these interfaces.  It's in keeping with that for declarations to 
> make only minimal public guarantees and require the programmer to be more 
> explicit about the things they want to allow.
> 
> Your arguments about patchability and performance could be applied to every 
> feature in the language.  They are essentially arguments for a fully-dynamic 
> environment.

see https://en.wikipedia.org/wiki/Straw_man

Most OO languages do not seal seal modules (or the equivalent) by default. 
Forcing developers to add “final” does not seem onerous. If authors do not have 
time to audit their frameworks, the language should not pretend do it for them.


> There's no reason to single out subclassing; for everything you can imagine, 
> one programmer's caution will be another's paternalism.  You're just making 
> the argument here because you're used to a particular way of patching 
> Objective-C code, one which will work regardless of this language decision;

That seems personal.


> but most of the old ObjC techniques (e.g. accessing ivars reflectively) 
> already won't work on Swift code without unsafe operations, and subclassing 
> is a very tiny part of that problem.
> 
> And no, we do not and will not accept that performance-sensitive code can 
> only possibly be written in C or assembly, or that algorithmic performance is 
> the only thing worth worrying about, even for the language implementation.

Could many of the performance advantages of sealing could be gained through 
“whole application” optimization?T he benefits could far exceed what is 
possible with whole module optimization. It would probably be extremely 
difficult and hard to scale, but for packaged, signed applications, it should 
be possible some day.

> 
> John.



> 
> 
> 
>> -Michael
>> 
>>> Am 28.06.2016 um 15:09 schrieb L. Mihalkovic via swift-evolution 
>>> :
>>> 
>>> 
>>> Regards
>>> LM
>>> (From mobile)
 On Jun 28, 2016, at 1:57 PM, Alejandro Martinez via swift-evolution 
  wrote:
 
 Anton 

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

[Christopher Kornher via swift-evolution]

> On Jun 27, 2016, at 11:52 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> 
>> On Jun 27, 2016, at 9:10 PM, Christopher Kornher > > wrote:
>> 
>> 
>>> On Jun 26, 2016, at 11:22 PM, Charlie Monroe via swift-evolution 
>>> > wrote:
>>> 
 All object references used within a closure must unwrap successfully for 
 the closure to execute.
>>> I agree with the logic of this proposal, but this is the confusing part or 
>>> a part that I slightly disagree with.
>>> 
>>> By this logic, the block won't be invoked if all captured variables can't 
>>> be unwrapped, which is definitely confusing to the newcomer (to whom this 
>>> is partially targetted as you've mentioned) if he puts a breakpoint in it 
>>> and doesn't get executed even when he's explicitely invoking it somewhere.
>>> 
>>> On the other hand, when it crashes, it gives him some idea that something's 
>>> wrong.
>> 
>> Tooling could alleviate some of this mystery. For example:
>> 
>> 1) In Xcode and other GUIs, closures that will not be executed could be 
>> greyed-out, perhaps with the reason overlaid on the closure perhaps this 
>> would only happen when a breakpoint was set within the closure. Perhaps the 
>> app could break on the on breakpoints within non-executing closures and 
>> notify the user that the closure did not execute.
>> 
>> 2) Debugger console commands could be added to describe the execution state 
>> of closures in scope and closure variables.
>> 
>> 3) Debug apps could bottleneck all closures through a function that that can 
>> be break-pointed. Breakpoints could be edited to filter on specific 
>> closures. 
>> 
>> 4) Some runtime switches could be added to enable verbose login modes for 
>> closures.
> 
> This can solve issues that you may have with a 2KLOC project that does 
> nothing but waits for the user to click on something. When you have a project 
> of 100KLOC, running at 100% CPU on a background thread, I don't think you'd 
> debug anything since console would be flooded by thousands of log messages…

This technique is used with CoreData, OS X Bindings, and probably other 
frameworks and yes, it is often a tool of last resort. Tools like grep and 
spunk are often needed to make use of the output, but this is an effective 
technique, if not a very efficient one. I much prefer interactive debugger 
support. One advantage of global logging options is that they can be to used 
over long periods, on remote machines to capture infrequent errors. 

> 
>> 
>> I don’t think that this is an insurmountable problem. There are many 
>> features of modern applications that are difficult to debug.
>> 
>>> 
>>> 
 
 I believe that these are safe, sensible and understandable rules that will 
 eliminate the need for capture lists for many closures. What do you think?
 
 
 ___
 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

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

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

[Christopher Kornher via swift-evolution]

> On Jun 28, 2016, at 6:53 AM, ad...@wheerd.de wrote:
> 
> Am 27.06.2016 20:55, schrieb Christopher Kornher:
>>> On Jun 27, 2016, at 2:45 AM, Manuel Krebber via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> On 06/26/2016 09:10 PM, Christopher Kornher via swift-evolution wrote:
>>>> The core proposal:
>>>> ——
>>>> Closures capturing object references should automatically capture all
>>>> object references as weak.
>>> In my code, most closures are used in a functional programming capacity,
>>> e.g. with map(), reduce, etc. Hence, most closures are non-escaping and
>>> local, where strong capture is the desired way. Otherwise I would have
>>> to litter everything with optional unwrapping or add the explicit
>>> capture definition which would both make the code less readable in my
>>> opinion.
>> I thought about this some more and it makes sense to treat
>> non-escaping closures are they are treated now. This might increase
>> the burden on the compiler especially because these closures may not
>> be declared inline. This would be far more straightforward than having
>> to worry about changes to object existence within one or more
>> invocations of a @nonescaping closure, especially in multi-threaded
>> code.
>> I do not think that this would be a significant change for developers
>> in practice. Any developer who would try to rely upon object
>> references changing within the application of a @nonescaping closure
>> would probably have read the manual very carefully :)
> 
> I am unsure whether treating closures differently depending on a @nonescaping 
> attribute on a function is a good idea.
> The problem is that, theoretically, the closure might be stored in a variable 
> or used with different functions. Then how do you decide whether the default 
> is strong or weak capture?

The compiler/runtime (in theory at least) knows how a closure is going to be 
applied. I am not a compiler writer, but two versions of the closure could be 
created when necessary and the appropriate one could be used depending upon the 
context.

> 
> Example:
> 
> func f1(_ f : (Int) -> Int) {
> ...
> }
> 
> func f2(_ f : @noescape  (Int) -> Int) {
> ...
> }
> 
> let foo = Foo()
> let f : (Int) -> Int = {
>  return foo.x
> }
> 
> f1(f)
> f2(f)
> 
> In addition different default capture behaviour dependant on context could be 
> confusing for developers I think.

The changes in behavior in the application of @noescaping closures are very 
much] edge case and are as likely to result from actions in other threads as 
anything else. So Capturing references as strong by default makes @noescaping 
closures more predictable and eliminates the potential for really some really 
subtle bug and race conditions.

For the same reason, implicit “let guards” in escaping closures should be 
applied early to improve predicability. Developers wanting to modify reference 
counts within closures are free to use traditional capture lists and capture 
and un-capture references as needed.

Memory management within closures should not be the default behavior, but it 
should be possible and discoverable. 


> 
>>>> 1) Closures with object references could be simplified further by
>>>> implicitly including ‘let’ guards for all object references:
>>> This sounds good for closures without return value, but how would you
>>> handle closures with non-optional non-void return values?
>> Good point.
>> 1) The simplest solution would be to have these closures require
>> capture lists to some or all object references. Given the prevalence
>> of the weak/strong dance, calling these out in some way probably
>> should be done anyway.
>> 2) Another option would be to eliminate the implicit nil check guards,
>> making all object references optional. The compiler would force these
>> to be unwrapped, so users would be guided to do the right thing.
>> 3) Just always weakly capturing all object references would treat all
>> closures uniformly.
> 
> I think I favour 2) out of these, even though it still means the code will 
> potentially be littered with ?. or let guards...
> 
> Kind regards, Manuel
> 

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

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

[Christopher Kornher via swift-evolution]

> On Jun 27, 2016, at 2:35 PM, L. Mihalkovic via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> 
> Regards
> (From mobile)
> 
> On Jun 27, 2016, at 10:18 PM, Dennis Lysenko via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> My 2c:
>> 
>> This proposal is made more appealing to me because it is not simply a 
>> 'beginners will get confused' issue. 
>> 
>> I have written tens of thousands of lines of Swift from Swift 1 to the Swift 
>> 3 preview and I still can't shake occasionally accidentally capturing `self` 
>> strongly when I, for example, assign a closure as a listener/action to a UI 
>> component.
> 
> The problem of is that it is easier for an app to survive an accidental extra 
> capture than it is for it the survive a missing one.. So if this is really 
> for beginners, then it is much better to keep the current behavior which will 
> lead them to have leaky apps, than it is to give them apps whre objects will 
> vanish from under their feet... granted neither is good to begin with.

Not always. large memory leaks are often fatal in iOS because of the limited 
memory footprint. On more constrained devices the problem would e worse.

All of the great feedback has made me realize that my original proposal was 
more UIKit centric that I thought. One size does not fit all. Any errors in 
closure memory management can be fatal and the challenge is to optimize the 
experience for all programming domains and styles.


> 
> 
>> 
>> To spin off of Christopher's last email, my proposal is thus: we could 
>> include the original proposal (without numbered addendums) and use tooling, 
>> but have it alleviate the burden another way: have the tooling insert 
>> `[strong self]` by default when autocompleting a block.
>> 
>> BTW, @Manuel Krebber: this proposal would not affect your run-of-the-mill 
>> map statement. array.map { object in object.property } requires no explicit 
>> capture since object is intuitively strongly captured there.
>> 
>> What do we think? Worth discussing?
>> 
>> On Mon, Jun 27, 2016 at 12:10 PM Christopher Kornher via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> On Jun 26, 2016, at 11:22 PM, Charlie Monroe via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> All object references used within a closure must unwrap successfully for 
>>>> the closure to execute.
>>> I agree with the logic of this proposal, but this is the confusing part or 
>>> a part that I slightly disagree with.
>>> 
>>> By this logic, the block won't be invoked if all captured variables can't 
>>> be unwrapped, which is definitely confusing to the newcomer (to whom this 
>>> is partially targetted as you've mentioned) if he puts a breakpoint in it 
>>> and doesn't get executed even when he's explicitely invoking it somewhere.
>>> 
>>> On the other hand, when it crashes, it gives him some idea that something's 
>>> wrong.
>> 
>> Tooling could alleviate some of this mystery. For example:
>> 
>> 1) In Xcode and other GUIs, closures that will not be executed could be 
>> greyed-out, perhaps with the reason overlaid on the closure perhaps this 
>> would only happen when a breakpoint was set within the closure. Perhaps the 
>> app could break on the on breakpoints within non-executing closures and 
>> notify the user that the closure did not execute.
>> 
>> 2) Debugger console commands could be added to describe the execution state 
>> of closures in scope and closure variables.
>> 
>> 3) Debug apps could bottleneck all closures through a function that that can 
>> be break-pointed. Breakpoints could be edited to filter on specific 
>> closures. 
>> 
>> 4) Some runtime switches could be added to enable verbose login modes for 
>> closures.
>> 
>> I don’t think that this is an insurmountable problem. There are many 
>> features of modern applications that are difficult to debug.
>> 
>>> 
>>> 
>>>> 
>>>> I believe that these are safe, sensible and understandable rules that will 
>>>> eliminate the need for capture lists for many closures. What do you think?
>>>> 
>>>> 
>>>> ___
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> htt

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

[Christopher Kornher via swift-evolution]

> On Jun 27, 2016, at 2:35 PM, L. Mihalkovic via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> 
> Regards
> (From mobile)
> 
> On Jun 27, 2016, at 10:18 PM, Dennis Lysenko via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> My 2c:
>> 
>> This proposal is made more appealing to me because it is not simply a 
>> 'beginners will get confused' issue. 
>> 
>> I have written tens of thousands of lines of Swift from Swift 1 to the Swift 
>> 3 preview and I still can't shake occasionally accidentally capturing `self` 
>> strongly when I, for example, assign a closure as a listener/action to a UI 
>> component.
> 
> The problem of is that it is easier for an app to survive an accidental extra 
> capture than it is for it the survive a missing one.. So if this is really 
> for beginners, then it is much better to keep the current behavior which will 
> lead them to have leaky apps, than it is to give them apps whre objects will 
> vanish from under their feet... granted neither is good to begin with.

For many cases, that is exactly the behavior you want. In my experience, the 
instances of closures being the only live reference to objects not being 
constructed by the closure are rare. 

To clarify, the proposed implicit guard statements would create strong 
references once the closure starts executing, so referenced objects would not 
disappear during the execution of the closure. 


>> To spin off of Christopher's last email, my proposal is thus: we could 
>> include the original proposal (without numbered addendums) and use tooling, 
>> but have it alleviate the burden another way: have the tooling insert 
>> `[strong self]` by default when autocompleting a block.
>> 
>> BTW, @Manuel Krebber: this proposal would not affect your run-of-the-mill 
>> map statement. array.map { object in object.property } requires no explicit 
>> capture since object is intuitively strongly captured there.
>> 
>> What do we think? Worth discussing?
>> 
>> On Mon, Jun 27, 2016 at 12:10 PM Christopher Kornher via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> On Jun 26, 2016, at 11:22 PM, Charlie Monroe via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> All object references used within a closure must unwrap successfully for 
>>>> the closure to execute.
>>> I agree with the logic of this proposal, but this is the confusing part or 
>>> a part that I slightly disagree with.
>>> 
>>> By this logic, the block won't be invoked if all captured variables can't 
>>> be unwrapped, which is definitely confusing to the newcomer (to whom this 
>>> is partially targetted as you've mentioned) if he puts a breakpoint in it 
>>> and doesn't get executed even when he's explicitely invoking it somewhere.
>>> 
>>> On the other hand, when it crashes, it gives him some idea that something's 
>>> wrong.
>> 
>> Tooling could alleviate some of this mystery. For example:
>> 
>> 1) In Xcode and other GUIs, closures that will not be executed could be 
>> greyed-out, perhaps with the reason overlaid on the closure perhaps this 
>> would only happen when a breakpoint was set within the closure. Perhaps the 
>> app could break on the on breakpoints within non-executing closures and 
>> notify the user that the closure did not execute.
>> 
>> 2) Debugger console commands could be added to describe the execution state 
>> of closures in scope and closure variables.
>> 
>> 3) Debug apps could bottleneck all closures through a function that that can 
>> be break-pointed. Breakpoints could be edited to filter on specific 
>> closures. 
>> 
>> 4) Some runtime switches could be added to enable verbose login modes for 
>> closures.
>> 
>> I don’t think that this is an insurmountable problem. There are many 
>> features of modern applications that are difficult to debug.
>> 
>>> 
>>> 
>>>> 
>>>> I believe that these are safe, sensible and understandable rules that will 
>>>> eliminate the need for capture lists for many closures. What do you think?
>>>> 
>>>> 
>>>> ___
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

[Christopher Kornher via swift-evolution]

> On Jun 27, 2016, at 2:51 PM, Russ Bishop via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
>> 
>> On Jun 27, 2016, at 12:35 AM, Christopher Kornher <ckorn...@me.com 
>> <mailto:ckorn...@me.com>> wrote:
>> 
>> 
>>> On Jun 26, 2016, at 4:25 PM, Russ Bishop <xen...@gmail.com 
>>> <mailto:xen...@gmail.com>> wrote:
>>> 
>>> 
>>>> On Jun 26, 2016, at 12:10 PM, Christopher Kornher via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> I may be too late for Swift 3, but I am planning to propose changes to the 
>>>> default behavior for closures capturing object references. The 
>>>> introduction of Swift Playgrounds has raised the importance of simplifying 
>>>> the coding of leak-free, crash-free closures. New developers should not 
>>>> have to understand closure memory management to start writing useful and 
>>>> correct code.
>>>> 
>>>> The topic of the closure weak/strong dance has been discussed on this list 
>>>> before. This proposal differs from previous proposals in that it will 
>>>> eliminate the dance altogether by default. I am very interested in hearing 
>>>> others’ opinions as to whether the benefits outweigh the costs of various 
>>>> options.
>>> 
>>> The problem is that strong reference capture is probably the far more 
>>> common case.
>> 
>> Strong reference capture has not been more common in carefully written code 
>> in my experience. Swift is starting to be used for many different problem 
>> domains, so your experience may be different. Any examples of real-world 
>> code would be greatly appreciated.
> 
> In my experience reference cycles are almost always caused by capturing self 
> strongly.
> 
>> 
>> Sometimes closures contain the only references to objects, but this is not 
>> common in code that I have seen. It would be extremely rare for strong 
>> references to be required for all the references in closure with multiple 
>> references (the current default behavior). Long closures can reference many 
>> objects and it is all too easy to leave a reference out of the capture list 
>> and create a reference cycle. I believe that this pattern should be 
>> called-out (see below).
>> 
>> Strong references are occasionally needed to ensure operations are performed 
>> when objects would otherwise be reclaimed, but I have not seen many of these 
>> cases. This pattern could be more common in other frameworks. I believe that 
>> this pattern should be called-out (see below).
>> 
>> Multiple capture rules for closures can be supported if desired. The 
>> ```[required…``` capture qualifier in the original email is one way todo 
>> this. The question mark could be used in a way analogous to `try?` to 
>> identify closures using the proposed rules: 
>> 
>> ```let a:()->Void = {…}?```
>> or 
>> ``` let a:()->Void = ?{…}```
>> etc.
>> 
>> This would obviously add more complexity but would still be an improvement, 
>> I believe.
> 
> Possibly, though this inevitably ends up with the C++ lambda rules more or 
> less. To put it another way, why would Swift introduce a new way of handling 
> this instead of just requiring all closures to specify whether they want 
> strong default, weak default, or whatever and completely eliminate any 
> automatic behavior? Unfortunately that makes creating closures much more 
> annoying.

I took a quick look at C++ capture lists. Yeah, we don’t want those. But 
another default behavior for captures does make sense for Swift I think. More 
to come.

>> 
>> 
>>> If you wanted to say that @noescape closures capture references strongly by 
>>> default, while escaping closures capture them weakly by default that may be 
>>> closer to reasonable for most situations but now you have magic behavior 
>>> with an even greater cognitive overhead. (I wonder if it would be more 
>>> common that @noescape captures strongly, escaping captures self weak by 
>>> default but other objects strongly… of course that would have even worse 
>>> cognitive overhead.)
>> 
>> I did consider treating self differently, but this leads to some very 
>> strange cases when delegation, factories and other patterns are considered. 
>> 
>> This email was implicitly referring to escaping uses of closures. The same 
>> closure can be used as escaping or non-escaping. The Swift do

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

[Christopher Kornher via swift-evolution]

> On Jun 26, 2016, at 11:22 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
>> All object references used within a closure must unwrap successfully for the 
>> closure to execute.
> I agree with the logic of this proposal, but this is the confusing part or a 
> part that I slightly disagree with.
> 
> By this logic, the block won't be invoked if all captured variables can't be 
> unwrapped, which is definitely confusing to the newcomer (to whom this is 
> partially targetted as you've mentioned) if he puts a breakpoint in it and 
> doesn't get executed even when he's explicitely invoking it somewhere.
> 
> On the other hand, when it crashes, it gives him some idea that something's 
> wrong.

Tooling could alleviate some of this mystery. For example:

1) In Xcode and other GUIs, closures that will not be executed could be 
greyed-out, perhaps with the reason overlaid on the closure perhaps this would 
only happen when a breakpoint was set within the closure. Perhaps the app could 
break on the on breakpoints within non-executing closures and notify the user 
that the closure did not execute.

2) Debugger console commands could be added to describe the execution state of 
closures in scope and closure variables.

3) Debug apps could bottleneck all closures through a function that that can be 
break-pointed. Breakpoints could be edited to filter on specific closures. 

4) Some runtime switches could be added to enable verbose login modes for 
closures.

I don’t think that this is an insurmountable problem. There are many features 
of modern applications that are difficult to debug.

> 
> 
>> 
>> I believe that these are safe, sensible and understandable rules that will 
>> eliminate the need for capture lists for many closures. What do you think?
>> 
>> 
>> ___
>> 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] An upcoming proposal for simplifying leak free, safe closures.

[Christopher Kornher via swift-evolution]

> On Jun 27, 2016, at 2:45 AM, Manuel Krebber via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> On 06/26/2016 09:10 PM, Christopher Kornher via swift-evolution wrote:
>> The core proposal:
>> ——
>> 
>> Closures capturing object references should automatically capture all
>> object references as weak.
> In my code, most closures are used in a functional programming capacity,
> e.g. with map(), reduce, etc. Hence, most closures are non-escaping and
> local, where strong capture is the desired way. Otherwise I would have
> to litter everything with optional unwrapping or add the explicit
> capture definition which would both make the code less readable in my
> opinion.

I thought about this some more and it makes sense to treat non-escaping 
closures are they are treated now. This might increase the burden on the 
compiler especially because these closures may not be declared inline. This 
would be far more straightforward than having to worry about changes to object 
existence within one or more invocations of a @nonescaping closure, especially 
in multi-threaded code.

I do not think that this would be a significant change for developers in 
practice. Any developer who would try to rely upon object references changing 
within the application of a @nonescaping closure would probably have read the 
manual very carefully :)


>> 1) Closures with object references could be simplified further by
>> implicitly including ‘let’ guards for all object references:
> This sounds good for closures without return value, but how would you
> handle closures with non-optional non-void return values?

Good point.

1) The simplest solution would be to have these closures require capture lists 
to some or all object references. Given the prevalence of the weak/strong 
dance, calling these out in some way probably should be done anyway.

2) Another option would be to eliminate the implicit nil check guards, making 
all object references optional. The compiler would force these to be unwrapped, 
so users would be guided to do the right thing.

3) Just always weakly capturing all object references would treat all closures 
uniformly.

> Also I think that explicit error handling in case of "expired" objects
> is safer than silent failure (by not executing the closure).


I believe that it is decision that should be left up to the author of the 
closure. Sometimes it is, sometimes it isn’t.

> 
> Kind regards, Manuel
> 
> 
> ___
> 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] An upcoming proposal for simplifying leak free, safe closures.

[Christopher Kornher via swift-evolution]

> On Jun 26, 2016, at 4:25 PM, Russ Bishop <xen...@gmail.com> wrote:
> 
> 
>> On Jun 26, 2016, at 12:10 PM, Christopher Kornher via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> I may be too late for Swift 3, but I am planning to propose changes to the 
>> default behavior for closures capturing object references. The introduction 
>> of Swift Playgrounds has raised the importance of simplifying the coding of 
>> leak-free, crash-free closures. New developers should not have to understand 
>> closure memory management to start writing useful and correct code.
>> 
>> The topic of the closure weak/strong dance has been discussed on this list 
>> before. This proposal differs from previous proposals in that it will 
>> eliminate the dance altogether by default. I am very interested in hearing 
>> others’ opinions as to whether the benefits outweigh the costs of various 
>> options.
> 
> The problem is that strong reference capture is probably the far more common 
> case.

Strong reference capture has not been more common in carefully written code in 
my experience. Swift is starting to be used for many different problem domains, 
so your experience may be different. Any examples of real-world code would be 
greatly appreciated.

Sometimes closures contain the only references to objects, but this is not 
common in code that I have seen. It would be extremely rare for strong 
references to be required for all the references in closure with multiple 
references (the current default behavior). Long closures can reference many 
objects and it is all too easy to leave a reference out of the capture list and 
create a reference cycle. I believe that this pattern should be called-out (see 
below).

Strong references are occasionally needed to ensure operations are performed 
when objects would otherwise be reclaimed, but I have not seen many of these 
cases. This pattern could be more common in other frameworks. I believe that 
this pattern should be called-out (see below).

Multiple capture rules for closures can be supported if desired. The 
```[required…``` capture qualifier in the original email is one way todo this. 
The question mark could be used in a way analogous to `try?` to identify 
closures using the proposed rules: 

```let a:()->Void = {…}?```
or 
``` let a:()->Void = ?{…}```
etc.

This would obviously add more complexity but would still be an improvement, I 
believe.


> If you wanted to say that @noescape closures capture references strongly by 
> default, while escaping closures capture them weakly by default that may be 
> closer to reasonable for most situations but now you have magic behavior with 
> an even greater cognitive overhead. (I wonder if it would be more common that 
> @noescape captures strongly, escaping captures self weak by default but other 
> objects strongly… of course that would have even worse cognitive overhead.)

I did consider treating self differently, but this leads to some very strange 
cases when delegation, factories and other patterns are considered. 

This email was implicitly referring to escaping uses of closures. The same 
closure can be used as escaping or non-escaping. The Swift documentation states:

 "Marking a closure with @noescape lets the compiler make more aggressive 
optimizations because it knows more information about the closure’s lifespan."

@noescape is essentially a hint to the compiler. Optimizers would be free to 
use strong or unowned references if they can determine that it is safe to do so 
without altering behavior. 

> No matter what, without a garbage collector you are stuck with sub-optimal 
> solutions for fixing reference cycles. I could imagine a language feature 
> that automatically detected trivial cycles (A -> B -> A) but anything more 
> complex just becomes a form of garbage collection anyway.

Object networks are difficult enough with ARC without dozens of closures with 
unnecessary strongly captured references. The new Xcode tools will be a huge 
help with leaks, but they should not be required.

> 
> I don’t think there is a way to square this circle. Either you have one 
> “automagic” behavior that is wrong for some cases (whether strong or weak is 
> the default), or you require everyone to spam their closures with explicit 
> capture annotations even if there’s a default “capture everything strongly” 
> variant (see C++ lambdas).

Yes, we are discussing tradeoffs. Writing correct code with closures will 
always require care.I believe that is is better to have safe, leak free code by 
default than not. I also believe that capturing strong references by default 
can probably lead to at least as many unexpected behaviors as capturing weak 
references. I don’t think that many developers would expect, for example, 

[swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

[Christopher Kornher via swift-evolution]

I may be too late for Swift 3, but I am planning to propose changes to the 
default behavior for closures capturing object references. The introduction of 
Swift Playgrounds has raised the importance of simplifying the coding of 
leak-free, crash-free closures. New developers should not have to understand 
closure memory management to start writing useful and correct code.

The topic of the closure weak/strong dance has been discussed on this list 
before. This proposal differs from previous proposals in that it will eliminate 
the dance altogether by default. I am very interested in hearing others’ 
opinions as to whether the benefits outweigh the costs of various options.

I have found that Swift’s capture lists and rules are a bit of a mystery to 
many experienced developers, even though Swift’s closure capture rules are very 
similar to those of Objective-C. Capture lists are probably thought of as 
opaque incantations by many new Swift developers if they are aware of them at 
all. Capture lists should, ideally, not be needed for sensible and safe default 
behavior.

This discussion is iOS / OS X centric and uses terms from those domains, but 
these issues should be applicable to almost any codebase that uses closures 
capturing object references.

Capture lists are required by the fact that object references are captured as 
`strong` by default, often leading to strong reference cycles and memory leaks.

Use of ‘unowned’ 

Many examples of using closures capture self as `unowned`. Often, this pattern 
does not scale well beyond simple examples. iOS and MacOS applications with 
dynamic UIs, for example, switch between numerous views and view controllers. 
These objects are dereferenced and reclaimed when they are no longer needed. 
Closures capturing these objects as `unowned` crash when the references are 
accessed.

Unfortunately, ‘unowned’ captures are tempting because they eliminate `guard` 
and `if let` constructs and avoid littering code with optional unwrapping. They 
are also slightly more performant, but this difference is probably negligible 
in most application code.

Capturing escaping object references as `unowned` is only safe when object 
lifetimes are perfectly understood. In complex systems, it is difficult to 
predict execution order. Even if object lifetimes are perfectly understood when 
code is originally written, seemingly innocuous changes to complex systems can 
negate original assumptions.

For these reasons, I believe that capturing object references as `unowned` 
should be considered an advanced optimization technique.

I now routinely create closures that capture `self` and other object references 
as ‘weak’ even if I think that I feel that `unowned ` would be safe. This may 
not be the absolutely most performant solution, but it is straightforward and 
robust.


The core proposal:
——

Closures capturing object references should automatically capture all object 
references as weak.

The closure defined in:

```
class ClosureOwner2 {
var aClosure: (() -> Void)?

func aMethod() {
aClosure = { [weak self] in
   self?.someOtherMethod()
   }
}

func someOtherMethod(){}
}
```

would normally be written as: 

```
aClosure = {
   self?.someOtherMethod()
}
```
Closures that can be optimized to safely capture object references as `unowned` 
can use the current syntax.

Swift 2 closure without explicit capture lists for object references will not 
compile.

Capturing strong object references can be very useful in certain circumstances 
and have a straightforward syntax:

```
aClosure = { [strong self] in
   self.someOtherMethod()
}
```


Alternatives / Modifications / Improvements(?):
—

1) Closures with object references could be simplified further by implicitly 
including ‘let’ guards for all object references: 
 
aClosure = {
   // This is included implicitly at the top of the closure:
// guard let strongSelf = self else { return }

/*strongSelf*/ self.someOtherMethod()
print( “This will not appear when self is nil.” )

… other uses of strongSelf…

}

This would have the effect of making the execution of the closure dependent 
upon the successful unwrapping of all of its object references. Object 
references that are not required to unwrap successfully can be captured as 
`weak’ if desired. 


2) Some of the magic in #1 could be eliminated by introducing a new capture 
type:  ‘required’ to specify ‘weak guarded’ captures, allowing the example 
closure to be written:

```
aClosure = { [required self] in
   self.someOtherMethod()
print( “This will not appear when self is nil.” )
print( “This is not the default behavior and the reason for this is 
clearly stated.” ) 
}
```
This reduces the amount of code required, but may increase the cognitive burden 
over using the 

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

[Christopher Kornher via swift-evolution]

> On Jun 10, 2016, at 1:52 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Fri, Jun 10, 2016 at 2:38 PM, Brandon Knope via swift-evolution 
> > wrote:
> Thanks for the laugh!
> 
> The last week or so is actually stressing me out about the direction where 
> swift is going…
> 
> I hope it is just a fleeting feeling but that remains to be seen. I am 
> beginning to think my interests and taste are no longer aligning with the 
> communities or core teams.
> 
> Brandon
> 
> I think, given the usage statistics, we'll find that these amount to small 
> nips and tucks. I can't speak to whether things will be to your taste, but 
> please rest assured that these proposals do not arise out of anyone's taste 
> or distaste (outside that of the core team). If taste were the basis for 
> proposals, I'd be proposing rather larger changes to the syntax, but I 
> appreciate that my personal taste is of no import.

Language design is an art as much as a science. Expressiveness is an extremely 
important feature of a language to me (and of Swift). If we want to be 
scientific about it, character and line counts are very rough metrics for 
expressiveness. How many more characters does changing 'where’s to ‘guards' 
cost?  How many lines would be added by a sensibly formatted replacement?

Java is a great example of a language that did not put a high priority on 
expressiveness and consequently Java code has a very high fraction of 
boilerplate. I do not want to see Swift be “Javaized” in the name of 
“rationalization”. Rationalization does not require the language to be 
dumbed-down to a lowest common denominator syntax.

> 
> But as to interests, please do speak loudly and without reserve if any 
> proposed changes are putting a stop to real-world (or even anticipated) uses 
> you have. That's precisely what this process is about.
>  
> 
> > On Jun 10, 2016, at 3:25 PM, L. Mihalkovic via swift-evolution 
> > > wrote:
> >
> > Goodness... where is this language going.
> >
> >> On Jun 10, 2016, at 9:08 PM, Erica Sadun via swift-evolution 
> >> > wrote:
> >>
> >>
> >>> On Jun 10, 2016, at 1:06 PM, Rob Norback via swift-evolution 
> >>> > wrote:
> >>>
> >>> Following Brent's logic that the for-in where should mimic the switch 
> >>> statement functionality, then this example:
> >>>
> >>> for (eachKey, eachValue)
> >>> where eachValue > 5
> >>> in theKeyValuePairs {... }
> >>
> >> 
> >>
> >> I finally convinced myself of which direction I wanted to go: 
> >> https://github.com/apple/swift-evolution/pull/362/files 
> >> 
> >>
> >> Related blog post here: 
> >> http://ericasadun.com/2016/06/10/swift-where-oh-where-can-my-where-clause-be/
> >>  
> >> 
> >>
> >> Big thanks to Brent and Wux.
> >>
> >> -- E
> >>
> >>
> >>
> >>
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org 
> >> https://lists.swift.org/mailman/listinfo/swift-evolution 
> >> 
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org 
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> ___
> 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] Retiring `where` from for-in loops

[Christopher Kornher via swift-evolution]

> On Jun 10, 2016, at 12:09 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> I don't think the 'where' in 'for' loop adds another dialect of Swift more 
> than using of [Int] vs Array or shorthand syntax for Optionals adds it. 
> (in addition to 'guard' vs 'if')
> So, it's just an opinion if 'where' in 'for' loop introduces new dialect or 
> if it is a handy feature that can be used when it best suits the needs in 
> some situation or even a metter of style(like [Int] vs Array or using 
> .forEach vs for-in etc).
> 
> On 10.06.2016 20:17, Xiaodi Wu via swift-evolution wrote:
>> I think this idea--if you don't like it, then you don't have to use it--is
>> indicative of a key worry here: it's inessential to the language and
>> promotes dialects wherein certain people use it and others wherein they
>> don't. This is an anti-goal.
>> 
>> On Fri, Jun 10, 2016 at 12:10 let var go > > wrote:
>> 
>>   Leave it in!
>> 
>>   It's a great little tool. I don't use it very often, but when I do it
>>   is because I've decided that in the context of that piece of code it
>>   does exactly what I want it to do with the maximum amount of clarity.
>> 
>>   If you don't like it, then don't use it, but I can't see how it
>>   detracts from the language at all.
>> 
>>   The *only* argument that I have heard for removing it is that some
>>   people don't immediately intuit how to use it. I didn't have any
>>   trouble with it at all. It follows one of the most basic programming
>>   patterns ever: "For all x in X, if predicate P is true, do something."
>>   The use of the keyword "where" makes perfect sense in that context, and
>>   when I read it out loud, it sounds natural: "For all x in X where P, do
>>   something." That is an elegant, succinct, and clear way of stating
>>   exactly what I want my program to do.
>> 
>>   I don't doubt that it has caused some confusion for some people, but
>>   I'm not sold that that is a good enough reason to get rid of it. It
>>   seems strange to get rid of a tool because not everyone understands how
>>   to use it immediately, without ever having to ask a single question. As
>>   long as its not a dangerous tool (and it isn't), then keep it in the
>>   workshop for those times when it comes in handy. And even if there is
>>   some initial confusion, it doesn't sound like it lasted that long. It's
>>   more like, "Does this work like X, or does this work like Y? Let's
>>   see...oh, it works like X. Ok." That's the entire learning
>>   curve...about 5 seconds of curiosity followed by the blissful feeling
>>   of resolution.
>> 
>>   On Fri, Jun 10, 2016 at 9:32 AM Xiaodi Wu via swift-evolution
>>   > wrote:
>> 
>>   On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution
>>   > wrote:
>> 
>>> And to follow-up to myself once again, I went to my "Cool 3rd Party Swift 
>>> Repos" folder and did the same search. Among the 15 repos in that folder, a 
>>> joint search returned about 650 hits on for-in (again with some false 
>>> positives) and not a single for-in-while use.
>> 
>>   Weird. My own Swift projects (not on Github :P) use “where” all
>>   the time with for loops. I really like it and think it reads
>>   *and* writes far better as well as makes for nicer one-liners.
>>   In one project, by rough count, I have about 20 that use
>>   “where” vs. 40 in that same project not using “where”.
>> 
>>   In another smaller test project, there are only 10 for loops,
>>   but even so one still managed to use where.
>> 
>>   Not a lot of data without looking at even more projects, I
>>   admit, but this seems to suggest that the usage of “where” is
>>   going to be very developer-dependent. Perhaps there’s some
>>   factor of prior background at work here? (I’ve done a lot of
>>   SQL in another life, for example.)
>> 
>> 
>>   That is worrying if true, because it suggests that it's enabling
>>   'dialects' of Swift, an explicit anti-goal of the language.

Programming styles are not dialects.

>> 
>> 
>> 
>>   I feel like “where” is a more declarative construct and that we
>>   should be encouraging that way of thinking in general. When
>>   using it, it feels like “magic” for some reason - even though
>>   there’s nothing special about it. It feels like I’ve made the
>>   language work *for me* a little bit rather than me having to
>>   contort my solution to the will of the language. This may be
>>   highly subjective.
>> 
>>   l8r
>>   Sean
>> 
>>   ___
>>   swift-evolution mailing list
>>   swift-evolution@swift.org 

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

[Christopher Kornher via swift-evolution]

-1 

An alternative would be to:

1) State clearly in all relevant documentation that ‘where’ filters and 
 ‘while’ terminates.
2) Eliminate the use of ‘where’ within ‘while’ clauses.

This seems pretty straightforward to me. The principle in  #1 should be easy 
for even beginners to grasp.

Using ‘guard’ statements instead of ‘where’ clauses adds a lot of visual noise 
for me. 



> On Jun 10, 2016, at 1:08 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Jun 10, 2016, at 1:06 PM, Rob Norback via swift-evolution 
>>  wrote:
>> 
>> Following Brent's logic that the for-in where should mimic the switch 
>> statement functionality, then this example:
>> 
>> for (eachKey, eachValue) 
>> where eachValue > 5 
>> in theKeyValuePairs {... }
>> 
> 
> 
> 
> I finally convinced myself of which direction I wanted to go: 
> https://github.com/apple/swift-evolution/pull/362/files
> 
> Related blog post here: 
> http://ericasadun.com/2016/06/10/swift-where-oh-where-can-my-where-clause-be/
> 
> Big thanks to Brent and Wux.
> 
> -- E
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

[Christopher Kornher via swift-evolution]

+1

> On Jun 9, 2016, at 1:05 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Gist: https://gist.github.com/erica/86f00c1b8ebf45dcf3507ae6ef642b57 
> 
> 
> Regularizing Where grammar
> 
> Proposal: TBD
> Author: Brent Royal-Gordon , Erica Sadun 
> 
> Status: TBD
> Review manager: TBD
>  
> Introduction
> 
> This proposal fixes an inconsistency for where clause grammar in Swift 
> language for-in loops.
> 
> Swift Evolution Discussion: Add a while clause to for loops 
> 
>  
> Motivation
> 
> Unlike in switch statements and do loops, a for-in loop's where-clause is 
> separated from the pattern it modifies.
> 
> for case? pattern in expression where-clause? code-block
> 
> case-item-list → pattern where-clause? | pattern where-clause? , 
> case-item-list
> 
> catch pattern? where-clause? code-block
> This separation makes the clause harder to associate with the pattern, can 
> confuse users as to whether it modifies the expression or the pattern, and 
> represents an inconsistency in Swift's grammar. This proposal regularizes the 
> grammar to match other uses.
> 
> Note where clauses in case conditions and optional bindings have been removed 
> in SE-0099 
> .
> 
>  
> Detailed
>  Design
> 
> Current:
> 
> for case? pattern in expression where-clause? code-block
> Proposed:
> 
> for case? pattern where-clause? in expression code-block
>  
> Impact
>  on Existing Code
> 
> Migration should be easily addressed with a simple fix-it.
> 
>  
> Alternatives
>  Considered
> 
> Not accepting this proposal
> 
> 
>> On Jun 8, 2016, at 9:23 PM, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> 
>>> This reads to me as “repeat the following block until this fails to be 
>>> true”, the conditional binding in this case fails to be true if 
>>> someCondition(value) isn’t true, so the loop ends. I think the key thing 
>>> here is that the where clause is for the conditional binding and not the 
>>> loop itself, so in this respect it behaves exactly like an if or guard 
>>> statement. Meanwhile:
>>> 
>>> for eachValue in theValues where someCondition(eachValue) { … }
>>> 
>>> Reads as “for everything in theValues do the following if 
>>> someCondition(eachValue) is also true”, in other words this loop always 
>>> tries to visit every element of the sequence (a while loop has no implicit 
>>> awareness of the sequence, it’s really just an if statement that runs over 
>>> and over). In this case the where clause is part of the loop itself. There 
>>> may be an argument that where should be renamed on for loops to better 
>>> distinguish this, but once you consider that there’s no pattern or 
>>> conditional binding here I think it makes a reasonable amount of sense.
>> 
>> The original sin here was in connecting the `where` clause to the for loop's 
>> sequence expression, rather than its pattern. If `where` were positioned 
>> right after the loop variable:
>> 
>>  for eachValue where someCondition(eachValue) in theValues { … }
>> 
>> It would be much clearer that `where` constrains the values seen by the loop 
>> body.
>> 
>> I'm not sure why the `where` clause was placed where it is. I suspect it has 
>> something to do with the `where` clause potentially being more complex than 
>> the sequence expression, but I was not in the room where it happened, so 
>> that's idle speculation.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

[Christopher Kornher via swift-evolution]

While I preferred a different solution, here, I think that the current “do not 
design by committee” process is a good one, and the accepted solution is 
definite improvement. A consistent vision is critical to a project as complex 
as this. It is certainly in Apple’s DNA, and has served it, and the world, well.

This proposal is one step in achieving overarching goal: "to preserve 
higher-level consistency throughout the language in how components of 
expressions and statements are separated” 

Well, if you want consistency, why not work through all the cases before 
freezing on one point solution? Perhaps the process should be expanded to 
formalize the overarching goal and put proposals like this under it. The 
process could be something like:

1) Propose goal, and list of point solutions, e.g. “...condition clauses..."
2) Review, refine and accept the goal
3) Work through tentative point solutions
4) Review the entire set of solutions.
5) Accept the solution set.

There is distinct possibility that working though other tasks can foster a 
deeper understanding and uncover better, more consistent solutions. Of course, 
another proposal can be created to revisit this topic, but that creates more 
churn. Formally reviewing overarching goals and all the aspects of achieving 
them could, in the long run, create a better product more efficiently and 
better involve and align the community.

This might slow down the rate of change in the language and libraries, but that 
is not necessarily a bad thing in something as complex as attempting to create 
a new language for a wide spectrum of applications.

This goal may be the exception, but the current process may not be optimal for 
complex multi-faceted problems that are on the horizon, like creating a 
metadata system, macros, kernel and driver software (?), ...


> On Jun 9, 2016, at 10:16 AM, Brandon Knope via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On Jun 9, 2016, at 11:55 AM, Brent Royal-Gordon  > wrote:
> 
>>> I believe large syntax changes should have more discussion from more 
>>> developers and not a very small subset of them. The review announcement 
>>> needs to be broader: the swift blog needs to announce it so more people 
>>> know.
>> 
>> No.
> 
> G
> 
>> 
>> Firstly, for those who cannot follow the list—and I can't say I blame 
>> them—the -announce list already allows them to ignore everything except the 
>> beginnings of reviews. Anyone who wants to (and who speaks English) can be 
>> notified of any significant proposed change to the language and can submit 
>> their comments for the core team's consideration. That is enough.
> 
> I think your perspective is flawed here. You are precisely one of the "top 
> developers" I have been referring to. Am I surprised this is your opinion? 
> Not one bit.
> 
> Mailing lists are a rather old thing...and I think many will find them 
> daunting or maybe somewhat annoying with all of the announcements. How many 
> people are subscribed to announce? It does not seem like many because 
> well...we don't always get a lot of feedback. We get feedback from the same 
> people over and over. How is this enough? How is this enough variety?
> 
> Just because "announce" is more palatable does not mean that it is being used 
> in the way you are describing. 
> 
> Maybe there is another problem then: people afraid to share their opinions 
> publicly. I wonder why this would be.
> 
>> The purpose of reviews is not to cast ballots for or against a feature. It 
>> is to submit arguments, for and against, for the core team to consider as 
>> they decide whether and how to address the problem the proposal's 
>> "Motivation" section describes. For that purpose, there is no need to 
>> collect hundreds or thousands of reviews, and if we did, the review manager 
>> would be swamped anyway. It is enough to get a reasonable variety of eyes, 
>> from a reasonable variety of perspectives, on the problem.
> 
> Why do people keep saying I am asking for: "hundreds or thousands" of 
> reviews? I am just asking for something like 20 - 25 unique people's 
> feedback. We are not getting that. We get the same people over and 
> over...which makes the feedback seem screwed to this small group's 
> philosophies.
> 
> Getting feedback from the same ~10 people is not a "reasonable variety of 
> eyes" in my opinion. That is a very small sample. And that sample is usually 
> those who are very technically skilled...who I would say do not always design 
> the best interfaces.
> 
>> I think that has happened here. We have not heard from every perspective, 
>> but we have heard from enough of them that adding more will not help all 
>> that much. Feedback always has diminishing returns: going from one person to 
>> two is far more valuable than going from fifty-one to fifty-two.
> 
> I think you will be very surprised come WWDC when people 

Re: [swift-evolution] Marking sort and sorted with rethrows

[Christopher Kornher via swift-evolution]

+1 This is straightforward and self-documenting.

> On Jun 8, 2016, at 11:21 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jun 8, 2016, at 7:52 AM, Brent Royal-Gordon  
>> wrote:
>> 
>>> Is there a widely used comparison function that throws?
>> 
>> Any comparison function that examines external data related to the instance:
>> 
>> * Sorting filenames by the data in the corresponding files
>> * Instances backed by a database where actually loading the data could fail
>> * Etc.
> 
> Ok, instead of using rethrows, would it be a better overall design be to 
> define two overloads, one that takes a throwing closure and one that doesn’t? 
>  This allows the throw-supporting implementation to be slower without 
> punishing the normal case..
> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

[Christopher Kornher via swift-evolution]

> On Jun 6, 2016, at 12:02 PM, Rob Norback via swift-evolution 
>  wrote:
> 
> First of all, thank you all for bringing me up to date so quickly.  I looked 
> over the proposal and it looks awesome.
> 
> But as Chris mentioned, this doesn't solve the expected behavior and 
> ambiguity of ```Array```

I think that name is reserved word on this list :) Just to be clear, I am 
another Chris (Chris K).
I forgot to mention that I like the proposal.

> In this case I would expect the default behavior (myArray[4]) without using 
> myArray[checking: 4] should return a nil in this case.
> 
> And Chris, I think it would make the most sense to have myArray[0] = nil to 
> be stored if the index is in Range, and for myArray[100] = nil to give a 
> warning of no assignment being made because index is out of range, kind of 
> like an unused variable.  Right now myArray[100] = nil gives you 
> EXC_BAD_INSTRUCTION.  Then if you assigned myArray[100] = 200, that would 
> have to simply change the Range.

Yes, Arrays should store the value and I do not believe that the syntax for 
allays would be ambiguous. I do believe that since this is in the same general 
territory, the syntax for dictionaries should be improved at the same time, to 
simplify the story for users… perhaps with another keyword(?)

``` 
var d = Dictionary
...
d[setting:0] = nil  // I did not give much thought to the name of 
the keyword.
```
A solution that uses the same new syntax should probably be in the same 
proposal. A separate proposal might be more appropriate for a different 
solution.  

> 
> Chris, I honestly have to think more about that ambiguity with dictionaries.
> 
> I can see that this would definitely need some further fleshing out, but it 
> seems to be sufficiently different from Luis' proposal to perhaps merit it's 
> own proposal.
> 
> It's up to you Luis, but I think this might be a bit more controversial then 
> the changes you've proposed, making it possible for your proposal getting 
> rejected.  (I want your proposal accepted, since I would use those features 
> today).  Partial acceptance of a proposal doesn't seem to be a thing. (Once 
> again please correct me if I'm wrong).
> 
> On Mon, Jun 6, 2016 at 11:46 AM Luis Henrique B. Sousa  > wrote:
> Thanks Vladimir,
> 
> The correct link is this one (with the additional min/max operations in the 
> implementation): 
> https://github.com/luish/swift-evolution/blob/proposal-lenient-collection-subscripts/proposals/-more-lenient-collections-subscripts.md
>  
> 
> 
> Here is the pull request on the swift-evolution repo: 
> https://github.com/apple/swift-evolution/pull/328 
> 
> 
> Any help or suggestion to improve the proposal is welcome. :-)
> 
> - Luis
> 
> On Mon, Jun 6, 2016 at 6:10 PM, Vladimir.S via swift-evolution 
> > wrote:
> Please find this draft of proposal(hope this is correct link for latest 
> version):
> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md
>  
> 
> 
> The main idea is to introduce 2 new subscript methods:  [clamping:] and 
> [checking:]
> 
> There was discussion in "[Proposal] More lenient subscript methods over 
> Collections" and (older) "[Proposal] Safer half-open range operator"
> 
> 
> On 06.06.2016 19:50, Rob Norback via swift-evolution wrote:
> Hi Everyone!
> 
> This is my first time emailing the swift evolution list, so if this topic
> has already been discussed please let me know.  I looked through all the
> accepted and rejected proposals and it doesn't seem to be on there.
> 
> The main thought is that dictionaries return optionals, so why not arrays?
> Or other CollectionTypes for that matter.  I would think this would be the
> expected behavior in this situation:
> 
> var myArray:[String?] = []
> print(myArray[4])
> // EXC_BAD_INSTRUCTION, but could just be Optional(nil)
> 
> Then you could do things like
> 
> if let arrayValue = myArray[4] {
>// do something
> }
> 
> Of course you could simply check with with the count, but considering
> Swift's use of optionals to represent empty variables rather than erroring
> out or returning an empty String, I think this functionality would be
> appropriate to include in the Swift standard library.
> 
> And there's about 15,000 people who've looked for this functionality in the
> last year:
> http://stackoverflow.com/questions/25329186/safe-bounds-checked-array-lookup-in-swift-through-optional-bindings
>  
> 

Re: [swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

[Christopher Kornher via swift-evolution]

The proposal needs to discuss arrays of optionals  e.g.:  ```Array```
These are not just legal, they are quite handy as well.

Dictionaries can also be declared with optional values, of course: 
```Dictionary```
These can be pretty confusing to deal with and we should not add to confusion 
with arrays.

An example of the confusion:

var d = Dictionary
...
d[0] = nil  // Does this delete the element or set it to nil? 
Honestly, I forget. The point is, the syntax is ambiguous.

It would be nice to create a completely unambiguous syntax for collections with 
optional values.

- Chris K


> On Jun 6, 2016, at 11:10 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> Please find this draft of proposal(hope this is correct link for latest 
> version):
> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md
> 
> The main idea is to introduce 2 new subscript methods:  [clamping:] and 
> [checking:]
> 
> There was discussion in "[Proposal] More lenient subscript methods over 
> Collections" and (older) "[Proposal] Safer half-open range operator"
> 
> On 06.06.2016 19:50, Rob Norback via swift-evolution wrote:
>> Hi Everyone!
>> 
>> This is my first time emailing the swift evolution list, so if this topic
>> has already been discussed please let me know.  I looked through all the
>> accepted and rejected proposals and it doesn't seem to be on there.
>> 
>> The main thought is that dictionaries return optionals, so why not arrays?
>> Or other CollectionTypes for that matter.  I would think this would be the
>> expected behavior in this situation:
>> 
>> var myArray:[String?] = []
>> print(myArray[4])
>> // EXC_BAD_INSTRUCTION, but could just be Optional(nil)
>> 
>> Then you could do things like
>> 
>> if let arrayValue = myArray[4] {
>>   // do something
>> }
>> 
>> Of course you could simply check with with the count, but considering
>> Swift's use of optionals to represent empty variables rather than erroring
>> out or returning an empty String, I think this functionality would be
>> appropriate to include in the Swift standard library.
>> 
>> And there's about 15,000 people who've looked for this functionality in the
>> last year:
>> http://stackoverflow.com/questions/25329186/safe-bounds-checked-array-lookup-in-swift-through-optional-bindings.
>> 
>> Please let me know what you think.
>> 
>> Best,
>> Rob Norback
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal] Enum subsets

[Christopher Kornher via swift-evolution]

The syntax I described here has a number of problems, among them being: 
1) Creating a supersets in the way described breaks down badly when the 
declarations exist within multiple modules. 
2) The empty enum declaration is currently illegal and probably should 
be
3) The superset declaration contains no clue as to what it really is.
4) Possibly the most commonly needed use case is not possible with this 
syntax: Extending enums defined in other modules

I believe that best solution is explicit ```subset:``` and ‘’’superset:``` 
relationships. They could be added to the language at the same time, or not, 
but it seems to make sense to consider the possibility of creating supersets 
along with creating subsets.

I will take more time to think this through before I reply again. It would be 
nice not to add a variation to ```:``` but that is the best syntax I could 
think of at the time.


> On Jun 3, 2016, at 2:18 PM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> My only hesitation with using `enum LCDColors : Colors` is that that syntax 
> usually signals extending a type and I am not sure whether I am advocating 
> for the ability to add something to `LCDColors` without adding it to 
> `Colors`. I envisioned it as 'simply a subset of cases' but that is probably 
> just limited vision on my part.

I agree.

> 
> Using the subtype syntax works for the most part, so I could certainly live 
> with it. 
> 
> On Fri, Jun 3, 2016 at 3:56 PM, Christopher Kornher  > wrote:
> Your original syntax makes  LCDColors clearly a type. The typealias obscures 
> the fact that a new type is being created. An alternative might be something 
> like:
> 
> ```
> enum LCDColors : Colors {
>   case red, green, blue
> }
> ```
> 
> or perhaps
> 
> ```
> enum LCDColors subset: Colors {
>   case red, green, blue
> }
> ```
> 
> This would would be compatible with something that I have been hoping for, 
> creating superset enums from multiple enums for things like errors:
> 
> ```
> enum AppErrors  {
>   // Defined by its subsets
> }
> 
> enum NetworkingErrors  subset: AppErrors {
>   case NWError1 = 1000, NWError2. NWError3
> }
> 
>  
> enum UserInputErrors  subset: AppErrors {
>   case UIError1 = 2000, UIError2. UIError3
> }
>  ```
> The compiler would have to check for rawValue collisions.
> 
> having the superset enum define values that could be used in children would 
> allow:
> 
>  ```
> enum AppErrors  {
>   // Defined by its subsets
>   case NetworkingErrorBase = 1000
>   case UIErrorBase = 2000
> }
> 
> enum NetworkingErrors  subset: AppErrors {
>   case NWError1 = NetworkingErrorBase, NWError2. NWError3
> }
> 
> enum UserInputErrors  subset: AppErrors {
>   case UIError1 = UIErrorBase, UIError2. UIError3
> }
>  ```
> 
>> On Jun 3, 2016, at 10:39 AM, T.J. Usiyan via swift-evolution 
>> > wrote:
>> 
>> I don't have a problem with something as explicit as that. I was mostly 
>> avoiding adding keywords with my proposed syntax. I have basically no tie to 
>> the proposed syntax.
>> 
>> TJ
>> 
>> On Fri, Jun 3, 2016 at 12:32 PM, Christopher Kornher > > wrote:
>> This could be useful in categorizing and grouping within large enums 
>> ErrorType enums come to mind. Would there be any problem with making the 
>> subset more explicit? e.g.
>> 
>> 
>> 
>> ``` swift
>> enum Colors {
>>  case red, orange, yellow, green, blue, indigo, violet
>>  …
>> }
>> 
>> extension Colors {
>>  subset  LCDColors  red, green, blue
>> }
>> ```
>> 
>>> On Jun 3, 2016, at 7:22 AM, T.J. Usiyan via swift-evolution 
>>> > wrote:
>>> 
>>> This is loosely related to but not meant to 'compete' with the ad hoc enum 
>>> proposal.
>>> 
>>> ## Introduction
>>> 
>>> This proposal adds/creates syntax to allow ad hoc creation of enums whose 
>>> members are strict subsets of explicitly defined enums.
>>> 
>>> Swift-evolution thread: [Discussion thread topic for that 
>>> proposal](http://news.gmane.org/gmane.comp.lang.swift.evolution 
>>> )
>>> 
>>> ## Motivation
>>> Consider a situation where we have an enum `Colors` which represents the 
>>> entire set of colors relevant to your application with many salient methods 
>>> and operations. We have also declared an enum `LCDColorModel` with only 
>>> three colors, `red, blue, green` .
>>> 
>>> ``` swift
>>> enum Colors {
>>> case red, orange, yellow, green, blue, indigo, violet
>>> …
>>> }
>>> 
>>> enum LCDColors {
>>> case red, green, blue
>>> }
>>> ```
>>> 
>>> The cases in `LCDColors` in our scenario do not require different behavior 
>>> from their similarly named cases in `Colors`. We would like, simply stated, 
>>> to explicitly 

Re: [swift-evolution] [Proposal] Enum subsets

[Christopher Kornher via swift-evolution]

Your original syntax makes  LCDColors clearly a type. The typealias obscures 
the fact that a new type is being created. An alternative might be something 
like:

```
enum LCDColors : Colors {
case red, green, blue
}
```

or perhaps

```
enum LCDColors subset: Colors {
case red, green, blue
}
```

This would would be compatible with something that I have been hoping for, 
creating superset enums from multiple enums for things like errors:

```
enum AppErrors  {
// Defined by its subsets
}

enum NetworkingErrors  subset: AppErrors {
case NWError1 = 1000, NWError2. NWError3
}

 
enum UserInputErrors  subset: AppErrors {
case UIError1 = 2000, UIError2. UIError3
}
 ```
The compiler would have to check for rawValue collisions.

having the superset enum define values that could be used in children would 
allow:

 ```
enum AppErrors  {
// Defined by its subsets
case NetworkingErrorBase = 1000
case UIErrorBase = 2000
}

enum NetworkingErrors  subset: AppErrors {
case NWError1 = NetworkingErrorBase, NWError2. NWError3
}

enum UserInputErrors  subset: AppErrors {
case UIError1 = UIErrorBase, UIError2. UIError3
}
 ```

> On Jun 3, 2016, at 10:39 AM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> I don't have a problem with something as explicit as that. I was mostly 
> avoiding adding keywords with my proposed syntax. I have basically no tie to 
> the proposed syntax.
> 
> TJ
> 
> On Fri, Jun 3, 2016 at 12:32 PM, Christopher Kornher  > wrote:
> This could be useful in categorizing and grouping within large enums 
> ErrorType enums come to mind. Would there be any problem with making the 
> subset more explicit? e.g.
> 
> 
> 
> ``` swift
> enum Colors {
>   case red, orange, yellow, green, blue, indigo, violet
>   …
> }
> 
> extension Colors {
>   subset  LCDColors  red, green, blue
> }
> ```
> 
>> On Jun 3, 2016, at 7:22 AM, T.J. Usiyan via swift-evolution 
>> > wrote:
>> 
>> This is loosely related to but not meant to 'compete' with the ad hoc enum 
>> proposal.
>> 
>> ## Introduction
>> 
>> This proposal adds/creates syntax to allow ad hoc creation of enums whose 
>> members are strict subsets of explicitly defined enums.
>> 
>> Swift-evolution thread: [Discussion thread topic for that 
>> proposal](http://news.gmane.org/gmane.comp.lang.swift.evolution 
>> )
>> 
>> ## Motivation
>> Consider a situation where we have an enum `Colors` which represents the 
>> entire set of colors relevant to your application with many salient methods 
>> and operations. We have also declared an enum `LCDColorModel` with only 
>> three colors, `red, blue, green` .
>> 
>> ``` swift
>> enum Colors {
>>  case red, orange, yellow, green, blue, indigo, violet
>>  …
>> }
>> 
>> enum LCDColors {
>>  case red, green, blue
>> }
>> ```
>> 
>> The cases in `LCDColors` in our scenario do not require different behavior 
>> from their similarly named cases in `Colors`. We would like, simply stated, 
>> to explicitly restrict the cases allowed within a specific portion of our 
>> software. There are, currently, a few approaches 
>>  1. Duplicate functionality in `LCDColors` 
>>  - Completely manually
>>  - Protocols with 'minimal' manual duplication
>>  2. Avoid duplication by allowing conversion to `Colors`. 
>> 
>> Neither of these solutions make the subset relationship between `Colors` and 
>> `LCDColors`  clear or strict.
> 
>> ## Proposed solution
>> 
>> Add syntax to describe a restricted set of cases from an enum. 
>> 
>> ```swift
>> typealias LCDColors = Colors.(red|green|blue)
>> ```
>> 
>> `LCDColors ` has all of the type and instance methods of `Colors`. Cases 
>> must appear in the same order as their original declaration. 
>> 
>> 
>> ## Detailed design
>> 
>> While I am unsure of the entirety of the design, I propose that name 
>> mangling be used which, along with the declaration order restriction should 
>> mean that all possible subsets have a stable and predictable name which 
>> contains all of the information necessary to infer cases. 
>> 
>> ## Impact on existing code
>> 
>> This is an additive change which should have no breaking change to existing 
>> code.
>> 
>> 
>> ___
>> 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

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

[Christopher Kornher via swift-evolution]

+1
 I have started using the ‘()’ syntax without even thinking about it. I never 
knew that it behaved in the way described. Using ‘()’ syntax will be natural 
for anyone with C++ experience.


> On Jun 2, 2016, at 10:08 AM, John McCall via swift-evolution 
>  wrote:
> 
> The official way to build a literal of a specific type is to write the 
> literal in an explicitly-typed context, like so:
> let x: UInt16 = 7
> or
> let x = 7 as UInt16
> 
> Nonetheless, programmers often try the following:
> UInt16(7)
> 
> Unfortunately, this does not attempt to construct the value using the 
> appropriate literal protocol; it instead performs overload resolution using 
> the standard rules, i.e. considering only single-argument unlabelled 
> initializers of a type which conforms to IntegerLiteralConvertible.  Often 
> this leads to static ambiguities or, worse, causes the literal to be built 
> using a default type (such as Int); this may have semantically very different 
> results which are only caught at runtime.
> 
> In my opinion, using this initializer-call syntax to build an 
> explicitly-typed literal is an obvious and natural choice with several 
> advantages over the "as" syntax.  However, even if you disagree, it's clear 
> that programmers are going to continue to independently try to use it, so 
> it's really unfortunate for it to be subtly wrong.
> 
> Therefore, I propose that we adopt the following typing rule:
> 
>   Given a function call expression of the form A(B) (that is, an expr-call 
> with a single, unlabelled argument) where B is an expr-literal or 
> expr-collection, if A has type T.Type for some type T and there is a declared 
> conformance of T to an appropriate literal protocol for B, then the 
> expression is always resolves as a literal construction of type T (as if the 
> expression were written "B as A") rather than as a general initializer call.
> 
> Formally, this would be a special form of the argument conversion constraint, 
> since the type of the expression A may not be immediately known.
> 
> Note that, as specified, it is possible to suppress this typing rule by 
> wrapping the literal in parentheses.  This might seem distasteful; it would 
> be easy enough to allow the form of B to include extra parentheses.  It's 
> potentially useful to have a way to suppress this rule and get a normal 
> construction, but there are several other ways of getting that effect, such 
> as explicitly typing the literal argument (e.g. writing "A(Int(B))").
> 
> A conditional conformance counts as a declared conformance even if the 
> generic arguments are known to not satisfy the conditional conformance.  This 
> permits the applicability of the rule to be decided without having to first 
> decide the type arguments, which greatly simplifies the type-checking problem 
> (and may be necessary for soundness; I didn't explore this in depth, but it 
> certainly feels like a very nasty sort of dependence).  We could potentially 
> weaken this for cases where A is a direct type reference with bound 
> parameters, e.g. Foo([]) or the same with a typealias, but I think 
> there's some benefit from having a simpler specification, both for the 
> implementation and for the explicability of the model.
> 
> John.
> ___
> 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] Ad hoc enums / options

[Christopher Kornher via swift-evolution]

> On Jun 1, 2016, at 7:48 PM, Ricardo Parada via swift-evolution 
>  wrote:
> 
> 
> On May 31, 2016, at 3:04 PM, Erica Sadun via swift-evolution 
> > wrote:
> 
>> let _ = scaleAndCropImage(image: myImage, toSize: size, operation: .fill)
>> 
>> You would not be able to assign `.fill` to a variable and use that for the 
>> operation value.
> 
> This is my objection to this idea. It does not encourage reuse.

-1For me too. Introducing this quasi-enum would increase cognitive load with 
little, if any, net benefit. This is the sort of feature that looks great and 
works wonderfully in example apps, but does not scale well to real systems, 
where options show up in more methods through time, get passed around to 
helpers, stored, marshaled into various formats, etc.

As someone mentioned, this would probably be a good fit If Swift adopts a 
structural type system (I suppose, I have ever used a language with one to my 
knowledge, unless duck typing counts)

As syntactic sugar for a true enum declaration, it would be a “cool” feature, 
but reuse would still be problematic. 

> 
> I would not be able to assign to a variable:
> 
> let selectedOperation = .fill
> 
> In order to then do this later in the program:
> 
> scaleAndCropImage(image: myImage, toSize: size, operation: selectedOperation)
> ___
> 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] Working with enums by name

[Christopher Kornher via swift-evolution]

Oops. I have wanted this feature and I have created `name` methods for 
non-String enums numerous times (whether I had to or not, I guess). If there is 
a formal proposal for this, I could not find it. I am obviously not familiar 
with the entire proposal but this is a feature that I have wanted almost from 
the first day I started using Swift.

I would prefer a `name`method for enums and not overload `description`.

A standard way of accessing the unique names of enum values would be compatible 
with a future variant of `enum` that would allow non-unique rawValue should 
Swift ever support that feature of C/C++ enums. (hint) It would become 
requirement for these enums, I think.

Accessing the names of enum values is extremely useful for diagnostics and 
quick and dirty UI e.g. playgrounds. 

> On Jun 1, 2016, at 3:07 PM, Paul Cantrell <cantr...@pobox.com> wrote:
> 
> 
>> On Jun 1, 2016, at 2:20 PM, Christopher Kornher via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On Jun 1, 2016, at 12:53 PM, Paul Cantrell via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> This is the case I was thinking of where the module name comes into play. 
>>> Drop those enums into a framework, and you’ll get 
>>> "landed(MyFramework.CoinSide.heads)". Ugh!
>> 
>> This seems to be more of namespace “import” issue than a problem with enums 
>> specifically. Declaring enums within another entity is a useful. I take 
>> advantage of qualified naming to make short, possibly non-unique enum names.
> 
> Yes, in _code_ fully qualified names are useful.
> 
> This thread is the need for unqualified names in _strings_ — for passing to 
> external systems, logging, etc.
> 
> The problematic behavior I was pointing out is that enums get converted to a 
> name-only string when they are at the _top_ level of a data structure, but a 
> fully qualified Module.EnumType.caseName when they're _nested_ inside a 
> collection or another enum. AFAIK, there's no way to override this behavior 
> without manually coding a case statement to map enum values to strings. This 
> proposal would solve that.
> 
> Cheers, P
> 
> 

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

Re: [swift-evolution] Working with enums by name

[Christopher Kornher via swift-evolution]

> On Jun 1, 2016, at 12:53 PM, Paul Cantrell via swift-evolution 
>  wrote:
> 
> Indeed, you’re quite right: verified that I get “Mars” even when the enum is 
> in a framework.
> 
> It took a little digging to get back what I was thinking of: it’s when the 
> enum value is inside some other data structure that you get an annoyingly 
> fully qualified name:
> 
> enum CoinSide {
> case heads
> case tails
> }
> 
> enum CoinState {
> case inAir
> case landed(showing: CoinSide)
> }
> 
> print(CoinState.inAir)  // → "inAir"
> 
> // …but…
> 
> print(CoinState.landed(showing: .heads))  // → "landed(CoinSide.heads)"
> 
> print([CoinSide.heads: 1])  // → "[CoinSide.heads: 1]"
> 
> This is the case I was thinking of where the module name comes into play. 
> Drop those enums into a framework, and you’ll get 
> "landed(MyFramework.CoinSide.heads)". Ugh!

This seems to be more of namespace “import” issue than a problem with enums 
specifically. Declaring enums within another entity is a useful. I take 
advantage of qualified naming to make short, possibly non-unique enum names.

> 
> So what if you want those second two to print out as "landed(heads)" and 
> "[heads: 1]”? This does not work:
> 
> enum CoinSide: CustomStringConvertible {
> case heads
> case tails
> 
> var description: String {
> return String(self) // infinite recursion
> }
> }
> 
> There’s no automatically implemented description (or debugDescription) 
> property we can delegate to. The conversion of .heads →  "heads" is 
> apparently runtime magic that we lose access to as soon as we implement 
> CustomStringConvertible or CustomDebugStringConvertible, and therefore AFAIK 
> there's no way to do this other than switching on all the cases:
> 
> enum CoinSide: CustomStringConvertible {
> case heads
> case tails
> 
> var description: String {
> switch(self) {
> case heads: return "heads"
> case tails: return "tails"
> }
> }
> }
> 
> Is is true that there’s no better way? Is there some 
> CustomVerboseDebugStringConvertible protocol we can override to change only 
> the "MyFramework.CoinSide.heads" form?
> 
> If indeed there is no better way, it seems like a really good case for having 
> the synthesized .caseName property. Even if there is a 
> CustomVerboseDebugStringConvertible to override in the particular case above, 
> being able to customize an enum’s description but still use the enum case 
> name in that description seems like a compelling use case as well.
> 
> Cheers, P
> 
>> On Jun 1, 2016, at 10:47 AM, Leonardo Pessoa > > wrote:
>> 
>> Paul, in all my tests for this thread printing the enum value only
>> produced the enum value's name ("Mars" in your example). The proposal
>> of having a .caseName (or should it better be .caseValue to cover
>> enums with associated values? any other suggestions?) will prevent
>> that changes to this behaviour crash apps in the future as this should
>> always produce the same result even if the string representation
>> changes.
>> 
>> L
>> 
>> On 1 June 2016 at 12:15, Paul Cantrell via swift-evolution
>> > wrote:
>>> IIRC, string interpolation prepends the module name if the enum belongs to 
>>> a module: “MyLib.Mars” instead of just “Mars”. It’s also been a source of 
>>> compiler crashes, at least in the past.
>>> 
>>> Those two factors forced me into this ugliness: 
>>> https://github.com/bustoutsolutions/siesta/blob/master/Source/ResourceObserver.swift#L106-L115
>>>  
>>> 
>>> 
>>> A clean, documented, supported way of exposing the enum case name that the 
>>> runtime clearly already has available seems sensible — and should be 
>>> independent of the raw type.
>>> 
>>> Cheers, P
>>> 
 On Jun 1, 2016, at 5:10 AM, Charlie Monroe via swift-evolution 
  wrote:
 
 This is, however, kind of a hack IMHO that relies on the compiler behavior 
 that isn't well documented.
 
 For example, this:
 
 enum Planet {
  case Earth
  case Mars
 }
 
 "\(Planet.Mars)" // This is "Mars"
 
 
 Works as well. You don't need to have the represented value to be String.
 
 Note that this:
 
 - works both when you have a plain enum, or enum Planet: Int, or whatever 
 raw value kind
 - does not work (!) when declared as @objc - then the result is "Planet".
 
> On Jun 1, 2016, at 9:52 AM, Patrick Smith via swift-evolution 
>  wrote:
> 
> I had no idea you could do this!!
> 
>> On 1 Jun 2016, at 12:32 PM, 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Christopher Kornher via swift-evolution]

Apologies for going off that tangent earlier.

> On May 31, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Revisiting this conversation, it seems that most of the design space has been 
> thoroughly explored. I think all suggestions presented so far boil down to 
> these:
> 
> Q: How is an arbitrary boolean assertion introduced after `if let`?

Perhaps it is better to think in terms of starting  with the boolean expression 
and then figure out where the case conditions and let clauses should fit-in.

Starting with the simplest form: 

if  

add that it can be preceded by a single let clause:

if let  where  

where  the comma separated list of assignments following a let

finishing up adding cases:

if let  where  case 

In this final form,   '’,  'let  where’,  and 
case  are all optional. One has to exist, of course.

This standardizes the form in a sensible way, I think. So: a single ‘let’ and a 
single ‘case” are allowed, in the position shown.

An example:

'if let a=a, b=b, where (x==3 && y=x) || (x==2 && y!-=x) {…}'


> Option 1 (present scenario)--using `where`
> Advantages: expressive when it means exactly the right thing
> Drawbacks: makes obligatory the suggestion of a semantic relationship between 
> what comes before and after even when there is no such relationship
> 
> Option 2--using a symbol sometimes encountered in conditional statements 
> (e.g. `&&` or comma)
> Advantages: doesn't look out of place
> Drawbacks: needs to be disambiguated from existing uses, necessitating other 
> changes in syntax
> 
> Option 3--using a symbol never encountered in conditional statements (e.g. 
> semicolon)
> Advantages: doesn't need to be disambiguated from any existing uses
> Drawbacks: looks out of place

and it is equivalent to `&&` 

`if let a=a; x==3; y==4`

is equivalent to

`if let a=a; x==3 && y==4`


> 
> For me, options 1 and 2 have permanent and objective drawbacks. By contrast, 
> familiarity increases with time, and beauty is in the eye of the beholder.
> 
> * * *
> 
> It does occur to me that there is one more option. I don't know that I like 
> it, but it's an option no one has put forward before: recite the opening 
> keyword when beginning a new boolean expression:
> 
> `if let x = x where x < 3 { ... }` becomes
> `if let x = x if x < 3 { ... }`
> 
> `while let item = sequence.next() where item > 0 { ... }` becomes
> `while let item = sequence.next() while item > 0 { ... }`
> 
> etc.
> 
> 
> On Tue, May 31, 2016 at 2:00 PM, Erica Sadun  > wrote:
> 
> > On May 31, 2016, at 12:52 PM, Xiaodi Wu  > > wrote:
> > These lines of reasoning are what have compelled me to conclude that 
> > `where` might not be salvageable.
> 
> To which, I'd add: `where` suggests there's a subordinate and semantic 
> relationship between the primary condition and the clause. There's no way as 
> far as I know this to enforce it in the grammar and the proposal allows both 
> clauses to be stated even without the connecting word. You could make a vague 
> argument, I suppose, for renaming `where` to `when` but all in all, even 
> killing `where` we benefit with better expressive capabilities and a simpler 
> grammar.
> 
> -- E
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Christopher Kornher via swift-evolution]

> On May 31, 2016, at 1:59 PM, Brandon Knope <bkn...@me.com> wrote:
> 
> Except "b" is the main focus of the where clause and b was just in the 
> preceding if condition. 
> 
> I feel like we are trying to find ways to break the current where clause even 
> though we've enjoyed it for almost a year now. I had no idea it was 
> problematic and restrictive. I thought it made its intent very 
> clear...leading to very readable code. 
> 
> Pretty soon almost every construct but conditionals will be allowed to have 
> where clauses, and THAT seems inconsistent to me. 
> 
> ...what exactly is the current problem? Can someone show me a real world 
> example?? I've already forgotten it in all of this discussion -_-
> 
> Brandon 
> 

I did this to explore why many people are reluctant to give-up ‘where’. The use 
of ‘where' seems intuitive to mess well, and I did not understand why. It seems 
to natural group all logic concerning a constant with its definition and this 
seems to be a way to do that.

These rules add restrictions, but it does group related elements.  I am not 
convinced that this improves the language, but I though that it was worth 
exploring.  


> On May 31, 2016, at 3:47 PM, Xiaodi Wu via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>> 
>> On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Not allowed:
>>> …
>>> let a = a
>>> let b = b where b > 10 && a > 5
>>> 
>>> Why would this not be allowed by your rule? You're making use of `b` in 
>>> your where clause. As I demonstrated above, essentially any assertion can 
>>> be rewritten to work around your rule. In general:
>> 
>> It is not allowed because  ‘a’ is defined in the line above. It must be 
>> defined in the ‘if let’ associated with the where in which it is mentioned.
>> 
>> That's a much more restrictive where clause than you proposed earlier. You'd 
>> not be able to write:
>> 
>> ```
>> let b = b where b > anyOtherVariable
>> ``` 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Christopher Kornher via swift-evolution]

> On May 31, 2016, at 1:47 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> 
> 
> On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Not allowed:
>> …
>> let a = a
>> let b = b where b > 10 && a > 5
>> 
>> Why would this not be allowed by your rule? You're making use of `b` in your 
>> where clause. As I demonstrated above, essentially any assertion can be 
>> rewritten to work around your rule. In general:
> 
> It is not allowed because  ‘a’ is defined in the line above. It must be 
> defined in the ‘if let’ associated with the where in which it is mentioned.
> 
> That's a much more restrictive where clause than you proposed earlier. You'd 
> not be able to write:
> 
> ```
> let b = b where b > anyOtherVariable
> ```


The definition is not a formal one, but that was the intent.

```
let b = b where b > anyOtherVariable
```
is legal as long as `anyOtherVariable` is not defined within the entire 
condition clause


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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Christopher Kornher via swift-evolution]

> 
> Not allowed:
> …
> let a = a
> let b = b where b > 10 && a > 5
> 
> Why would this not be allowed by your rule? You're making use of `b` in your 
> where clause. As I demonstrated above, essentially any assertion can be 
> rewritten to work around your rule. In general:

It is not allowed because  ‘a’ is defined in the line above. It must be defined 
in the ‘if let’ associated with the where in which it is mentioned.


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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Christopher Kornher via swift-evolution]

> On May 31, 2016, at 1:00 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On May 31, 2016, at 12:52 PM, Xiaodi Wu  wrote:
>> These lines of reasoning are what have compelled me to conclude that `where` 
>> might not be salvageable.
> 
> To which, I'd add: `where` suggests there's a subordinate and semantic 
> relationship between the primary condition and the clause. There's no way as 
> far as I know this to enforce it in the grammar and the proposal allows both 
> clauses to be stated even without the connecting word.

OK. I am naive enough to try to informally define a rule that would make 
“where” required and cover all (?) cases in the proposal:

‘where’ is required after an if-let for any clause involving a variable or 
constant defined in that 'if let. All boolean expressions after the ‘where’ 
must reference at least one of constants defined by the ‘if let'

Allowed:

let a = a, b=b where b > 10 && a > 5 && b> a


Not allowed:
…
let a = a
let b = b where b > 10 && a > 5
b > a
...

…
let a = a
let b = b where b > 10
a > 5
b > a
…

This requires the use of commas because all inter-related ‘if let’ constants 
must be associated with a single ‘where'

This makes the use of ‘&&’ more natural, since everything to the right of 
“where” is a boolean expression

The formal grammar is left as an exercise :)

The downside:

I would not have to answer all the ‘Why won’t this compile?’ questions 
on stack overflow. Of course, I would not want to do that for the current 
syntax, either.


> You could make a vague argument, I suppose, for renaming `where` to `when` 
> but all in all, even killing `where` we benefit with better expressive 
> capabilities and a simpler grammar.
> 
> -- E
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Ad hoc enums / options

[Christopher Kornher via swift-evolution]

Here is a correction to the equivalent declaration. It would be a 
RawRepresentable String enum to be compatible with serialization mechanisms 
e.g. JSON. and other representations. Again, the name could be auto-generated 
to keep the syntax succinct.

…

would be equivalent to

class MyImage  {
enum  ScaleCropFitFill : String {
case  Fit
case  Fill
} 
...


> On May 31, 2016, at 12:25 PM, Christopher Kornher  wrote:
> 
> Apologies for using you as a relay...
> 
>> Begin forwarded message:
>> 
>> From: Charlie Monroe via swift-evolution > >
>> Subject: Re: [swift-evolution] Ad hoc enums / options
>> Date: May 31, 2016 at 11:43:43 AM MDT
>> To: Charles Constant >
>> Cc: Swift Evolution > >, Christopher Kornher > >
>> Reply-To: Charlie Monroe > >
>> 
>> I have mixed feelings about this since it may lead to redeclarations over 
>> and over of the same values instead of actually declaring an enum.
> 
> 
> I have two suggested “improvements”
> 
> 1) Make the enum String raw-representable. Name it somehow. This does not 
> affect Erica’s original syntax.
> 2) Force an explicit name.
> 
> #2  does add to the length of function declarations, so it is a tradeoff. 
> Perhaps the name could be optional, but...
> 
> #2 would improve debug representations of the value by providing a name that 
> can be found in source code
> 
> In a full-featured metadata system, it would probably be nice to have a type 
> for the enum to simply the handling of all enums. 
> 
> #2 is more future-proof. Systems get more complex over time and one use of a 
> type becomes many. 
> The enum type name (auto-generated or required, it makes no difference) would 
> be scoped to the function’s namespace e.g. (fixing the typo) :
> 
> class MyImage  {
>   func scaleAndCropImage(
>   image: UIImage,
>   toSize size: CGSize,
>   operation: ScaleCropFitFill{ .Fit | Fill} = .Fit
> 
>   ) -> UIImage {…}
> }
> 
> would be equivalent to:
> 
> class MyImage  {
>   enum  ScaleCropFitFill {
>   case  Fit
>   case  Fill
>   } 
> 
>   func scaleAndCropImage(
>   image: UIImage,
>   toSize size: CGSize,
>   operation: ScaleCropFitFill = .Fit
>   ) -> UIImage {…}
> }
> 
> There are two ways that an implementation could evolve from having one use of 
> the enum in a call to multiple uses;
> 
> 1) The function is refactored into more functions internal to the original 
> function’s namespace: module/class/struct/enum.
>   In this case, it would be appropriate to leave the enum declaration in 
> function declaration to indicate that this is the only public use of the enum.
> 2) More public functions are created that use the enum
>   In this case, it would be appropriate to declare the enum within the 
> same scope. Existing code would not be affected. Smart editors could provide 
> this refactoring.
> 
> - Chris K

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

Re: [swift-evolution] [Pitch] #warning

[Christopher Kornher via swift-evolution]

> On May 30, 2016, at 2:35 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On May 29, 2016, at 10:36 PM, Charlie Monroe  
>> wrote:
>> 
>>> As to #warning, Swift’s use of warnings are significant different than the 
>>> use in C.  In C compilers, many of the warnings produced *should* be 
>>> errors, but can’t be because that effects language conformance and could 
>>> break a large body of code. 
>> 
>> The example I've mentioned with #error, doesn't necessarily lead to an 
>> error, but can just issue a #warning("Untested OS, proceed carefully.") - it 
>> IMHO doesn't necessarily be fatal.
> 
> This doesn’t make sense to me.  If the code is untested, then it should 
> definitely be audited and check if it is enabled.  A #error is the perfect 
> approach for this case.

I have used warnings in other languages when “bringing-up” large code bases. 
Using a #warning facility is helpful at these times. Counting the messages 
provides a metric for unresolved questions. I don’t fully understand Chris’s 
objection to a warning compiler directive, so I cannot comment on that. A 
‘Mark’ - like comment format would be almost as good.

There is a problem with ‘magic’ comment formats, though. Recently I have had 
issues with mistyping “// MARK”. IIRC, “// mark” is not recognized. Compiler 
directives do not have this problem. In Objective-C “#pragma marl" is a 
compiler error. In swift, “// MARL” is silently treated as a plain comment.


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

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