Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

[L. Mihalkovic via swift-evolution]

> On Jun 8, 2016, at 9:02 PM, Thorsten Seitz  wrote:
> 
> 
>>> Am 07.06.2016 um 22:27 schrieb L Mihalkovic :
>>> 
>>> 
>>> On Jun 7, 2016, at 9:47 PM, Thorsten Seitz  wrote:
>>> 
>>> 
>>> 
>>> Am 07.06.2016 um 20:11 schrieb L Mihalkovic via swift-evolution 
>>> :
>>> 
 T1 ===
 import Lib1
 var str = func2()  // lib1
 
 T2 ===
 import Lib1
 import func Lib2.func2
 var str = func2()  // lib2
>>> 
>>> Shouldn't func2() be ambiguous here? It is imported from Lib1 and from Lib2.
>>> 
>>> -Thorsten 
>> 
>> 
>> no, that is precisely the point .. it works!!  I am able to override 
>> whatever my laziness brought into scope from Lib1 (caused by my * import) 
>> with a meticulously chosen implementation from Lib2. It is brilliant. 
>> extensions on the other hand work differently (although something could 
>> undoubtedly be done about them, I cannot entirely convince myself that it is 
>> time well spent. It would be if that could be a stepping stone form 
>> something else (which I have not been able to identify so far).
> 
> So it is dependent on the order of the imports?

Swift is a c-ish derivative-ish... intentionally.


> That’s rather fragile IMO and I would prefer having to solve clashes 
> explicitly independent of import order, e.g. by having to hide the version 
> from Lib1:
> 
> import Lib1 hiding func2  // strawman syntax
> import func Lib2.func2

Interesting...


Or 

Import func Lib2.func2   as  func2FromLib2

> -Thorsten
> 
> 
>> 
>> 
 
 T3 ===
 import Lib1
 import func Lib2.func2
 var str = “str”.allCaps()  // ERROR : ambiguous name
 
 
 Lib1 ===
 public func func2() -> String {
   return "lib1"
 }
 // only during T3
 public extension String {
   public func allCaps() -> String {
 return “lib1_"
   }
 }
 
 Lib2 ===
 public func func2() -> String {
   return "lib2"
 }
 // only during T3
 public extension String {
   public func allCaps() -> String {
 return "lib2_"
   }
 }
 
 
 T3 shows how differently extensions are treated from all other 
 exportable/importable artifacts:  extensions are NOT sensitive to the 
 scope of imports. they are fully loaded as soon as the loader detects that 
 the module is referenced (they come from their own table inside the module 
 binary).
 
 
 
 
>> On Jun 7, 2016, at 6:45 PM, Paul Cantrell  wrote:
>> 
>> 
>>> On Jun 7, 2016, at 11:36 AM, Paul Cantrell via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Jun 7, 2016, at 10:47 AM, L. Mihalkovic via swift-evolution 
>>>  wrote:
>>> 
 On Jun 7, 2016, at 4:53 PM, Tony Allevato  wrote:
 
 I like the "from" keyword the best, but I'll take my own stab at a 
 modification:
 
 import ModuleA
 import ModuleB
 
 "hello world".(capitalized from ModuleA)()
 "hello world".(capitalized from ModuleB)()
 "hello world".(someProperty from ModuleA)
 "hello world".(someProperty from ModuleB)
>>> 
>>> Hmmm... looks like an oxymoron in its own right... I was under the 
>>> impression so far that the point of extensions was that they are not 
>>> tied to a source. This brings us back full circle to the very 
>>> definition of extensions... However you slice it, swift is lacking some 
>>> scoping bellow modules, and/or arround some of the language features.
>> 
>> IIRC, a member of the core team (Joe Groff, maybe?) indicated several 
>> months ago on the list that methods are internally namespaced to their 
>> module. Alas, I can’t find that message. It was a long time ago.
> 
> Ah, here it is: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000928.html
> 
> Joe Groff wrote:
> 
> “It's helpful to think of method names as being namespaced in Swift, by 
> both their enclosing module and type. If two modules independently extend 
> a protocol with a method of the same name, you still semantically have 
> two distinct methods that dispatch independently. The extension would 
> have to be factored into a common module both modules see for them to 
> interact.”
> 
> IOW, yes, Swift internally does something very much like "hello 
> world”.ModuleA::capitalized().
> 
>> You can see this in the fact that two different files can see two 
>> different extension methods:
>> 
>> A.swift
>> 
>> import ModuleA
>> …
>> "hello world".capitalized()
>> 
>> B.swift
>> 
>> import ModuleB
>> …

Re: [swift-evolution] [Proposal] Add support for compile-time function execution

[L. Mihalkovic via swift-evolution]

Chris has rules macros out-of-scope for 3.0. Who knows, maybe they'll be 
allowable in 4.0

> On Jun 9, 2016, at 1:41 AM, Alexander Momchilov via swift-evolution 
>  wrote:
> 
> Preface: I know this is likely a large undertaking to implement, but I think 
> it's worth it.
> 
> In addition to the typical compiler optimization of constant math 
> expressions, some languages (such as D and C++) have support for running 
> arbitrary functions at compile time (with some constraints).
> 
> I see many advantages of this:
> On iOS/OS X: it could precompute the UI and app initialization logic 
> (wherever possible) to speed app load times
> It can significantly speed up the initialization of applications with large 
> static properties. E.g. large constant Dictionaries could be precomputed.
> You could keep complex math expressions (including custom functions) in their 
> unevaluated form, without the pressure to precompute them elsewhere and 
> hardcode in the result.
> Dynamic programming: expensive look-up tables could be precomputed. These 
> wouldn't necessarily be large in size, but if their elements are especially 
> expensive to compute, there would be a huge advantage to precomputing them.
> 
> What do you guys think? Can you think of any other useful applications? Would 
> it be worth the implementation effort?
> 
> - Regards,
> Alexander Momchilov
> ___
> 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] extend trailing closure rule

[L. Mihalkovic via swift-evolution]

> On Jun 8, 2016, at 10:46 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> On Jun 8, 2016, at 12:06, Matt Neuburg via swift-evolution 
>>  wrote:
>> 
>> Stop me if you've heard this one; I've only just joined the list, in order 
>> to raise it.
>> 
>> Here's a common thing to say:
>> 
>>   UIView.animate(withDuration:0.4, animations: {
>>   self.v.backgroundColor = UIColor.red()
>>   })
>> 
>> That's ugly. I'd rather write:
>> 
>>   UIView.animate(withDuration:0.4) {
>>   self.v.backgroundColor = UIColor.red()
>>   }
>> 
>> What stops me is that `animations:` is not eligible for trailing closure 
>> syntax, because it isn't the last parameter — `completion:` is. But 
>> `completion:` has a default value, namely `nil` — that's why I'm allowed to 
>> omit it. So why can't the compiler work its way backwards through the 
>> parameters, and say to itself: "Well, I see a trailing closure, and I don't 
>> see any `animations:` label or any `completion:` label, so this trailing 
>> closure must be the `animations:` argument and the `completions:` argument 
>> must be `nil`."
>> 
>> The idea is that this would work for _any_ function call where the function 
>> takes, as its last parameters, a series of function arguments that have 
>> default values. There can be only one trailing closure, so it should be 
>> assumed to occupy the first available slot, as it were.
>> 
>> Would this be viable? Would it make a decent proposal? m.
> 
> I'm one of those in favor of going the other way: if a function takes 
> multiple closure arguments, you shouldn't be allowed to use a trailing 
> closure at all, because it may not be obvious to readers of your code which 
> one you are using. (This is especially true if the closures have the same 
> signature.)

+1


> 
> Jordan
> 
> ___
> 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

[Charlie Monroe via swift-evolution]

> On Jun 9, 2016, at 5:51 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Jun 8, 2016, at 9:36 PM, Brent Royal-Gordon > > wrote:
>> 
>>> Upon accepting SE-0099, the core team is removing `where` clauses from 
>>> condition clauses, writing "the 'where' keyword can be retired from its 
>>> purpose as a boolean condition introducer." 
>>> 
>>> Inspiried by Xiaodi Wu, I now propose removing `where` clauses from `for 
>>> in` loops, where they are better expressed (and read) as guard conditions. 
>> 
>> Do you propose to remove `for case` as well? That can equally be handled by 
>> a `guard case` in the loop body.
>> 
>> Alternate proposal: Move `where` clauses to be adjacent to the 
>> pattern—rather than the sequence expression—in a `for` loop, just as they 
>> are in these other syntaxes.
>> 
>>  for n where n.isOdd in 1...1_000 { … }
>> 
>> This makes them more consistent with the syntax in `switch` cases and 
>> `catch` statements, while also IMHO clarifying the role of the `where` 
>> clause as a filter on the elements seen by the loop.
> 
> I saw your post on that *after* I finished sending this. Moving `where` next 
> to the pattern, like you'd find in `catch` and switch `case`, the code would 
> look like this:
> 
> for i where i % 2 == 0 in sequence {
> // do stuff
> }
> 
> I agree that's really clever and an improvement but after coming up with all 
> the points about wrong expectations about termination vs filtering, the 
> better use of guard, and fetishes about vertical compactness, I think (call 
> it +0.6) I'm going to stick to my guns on this one - and for `for case` too. 
> I've been wuxxed.
> 
> * New users might expect the sequence to terminate as soon as i % 2 is 1, 
> rather than the correct interpretation which is "this is a filtering 
> operation"
> * The code can be expressed less ambiguously as 
> 
> for i in sequence.filter({ return i % 2 == 0 }) {
> // do stuff
> }

It's important to keep in mind that .filter without using .lazy copies the 
array. So you need to keep using sequence.lazy.filter({ return i %2 == 0 }), 
unless you're OK with giving up some performance, which a) adds boilerplate, b) 
not many people will remember to do.

I've taken the time to run a test, going through milion numbers (several times) 
using:

for i in arr { if i % 2 == 0 { continue } }
for i in arr where i % 2 == 0 { }
for i in arr.filter({ $0 % 2 == 0 }) { }
for i in arr.lazy.filter({ $0 % 2 == 0 }) { }

Results:

- plain for loop with if-continue: 27.19 seconds (+1.76%)
- with where: 26.72 seconds (+0.00%)
- .filter: 44.73 seconds (+67.40%)
- .lazy.filter: 31.66 seconds (+18.48%)

Yes, 100 milion numbers is an extreme, but it demonstrates that any of the 
suggested expressions will be slower, mainly if the caller doesn't use .lazy 
(67% !!!). The only comparable solution is adding additional lines of code into 
the body of the for loop by adding an if statement.


> * The while version can be expressed as
> 
> for i in sequence.prefix(while: { return $0 % 2 == 0 } ) {
> // do stuff
> }
> 
> * The code can also use `guard` statements as needed with `break` and 
> `continue`
> 
> (And yes, I should have pointed out filter and prefix as well as guard in my 
> first email)
> 
> -- 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-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[L. Mihalkovic via swift-evolution]

> On Jun 9, 2016, at 12:49 AM, Austin Zheng via swift-evolution 
>  wrote:
> 
> 
> 
>> On Wed, Jun 8, 2016 at 3:22 PM, Dave Abrahams  wrote:
>> 
>> on Wed Jun 08 2016, Austin Zheng  wrote:
>> 
>> > FWIW my opinion is that existentials either shouldn't be allowed to stand
>> > in for generic type parameters, or Dave's option #1 if they are.
>> 
>> Don't you mean #2?  Otherwise I'm confused.  #1 is the one that
>> prohibits more usages.
> 
> I'm just being cautious until a better solution comes along.
>  
>> 
>> > The implied promise of a generic type parameter T right now is that T
>> > always stands for the same concrete type (modulo things like passing
>> > in a subclass where a class would do), and likewise for all of T's
>> > associated types (T.Foo is always the same type everywhere in the
>> > context where T is valid). This is what makes using anything with
>> > 'self' requirements in a generic context sound. Allowing existentials
>> > to satisfy T would violate that constraint.
>> 
>> Not if you consider Any to be a
>> concrete type.  Concrete w.r.t. to a generic parameter means something
>> different from Concrete w.r.t. subtyping.
> 
> You can consider Any to be a concrete type, 
> but then you have the unprecedented situation where the associated types 
> associated with a concrete type aren't necessarily the same for all instances 
> (is this true for any type that can satisfy a generic type parameter today?).
> 
> (For the sake of this argument, Array isn't a concrete type, but Array or 
> Array is. You can't use 'Array' anywhere in Swift today, so I think my 
> assertion is fair.)
> 
> My understanding is that fixing the generic type parameter T by specializing 
> a function/type also fixes all the associated types associated with T. This 
> 'contract' would have to be weakened to allow existential types to satisfy 
> generic type parameters in any non-trivial way.
>  
>> 
>> > Relaxing these semantics would make it too easy to write code that
>> > traps at runtime "without the user having to reach" (to paraphrase
>> > Jordan from the "Swift philosophy" thread). Anyone who really really
>> > wants to write code that is 'compile-time unsound' in this way should
>> > have to explicitly type erase using concrete wrappers.
>> 
>> I'd really like to see the use-cases, to make sure that these restricted
>> existentials will be useful enough to be worth implementing.
> 
> This is enormously important.
> 
> First of all, (of course you know) there is a semantic difference between:
> 
> protocol Pet : class { }; class Cat : Pet { }; class Dog : Pet { }
> 
> class AnimalShelter { var pet: T }
> 
> and 
> 
> class AnimalShelter { var pet: Pet }
> 
> This is something you can express for simple existentials today (the code 
> above should run, with minor modifications), but not for existentials 
> containing associated types or self requirements.
> 
> I think a big part of what people want to do is to declare variables, pass 
> args to functions, and get return values from functions that abstract over 
> something like Collection. They want to do this without having to make their 
> code generic, and without forcing their code to be homogenous at runtime 
> (e.g. an instance of the dynamic AnimalShelter can be populated with a cat 
> and later a dog, but the generic one can only ever contain either; extend 
> this to Collections of Ints or whatnot).
> 
> The big problem is that existentials can't guarantee that they satisfy the 
> contract generic functions and types are expecting, as we've been discussing.
> 
> To be honest, I think requiring existentials to be opened should be a 
> prerequisite to using them generically. This would define away the impedance 
> mismatch at the expense of making certain things marginally harder to do. (An 
> alternate way of thinking about it is that it would make the potential for a 
> runtime error explicit, and localize it):
> 
> func doSomething(x: C, y: C) { ... }
> 
> let a : Any
> let b : Any
> 
> // Prohibit this...
> // doSomething(a, b)
> 
> // Allow this:
> if let a = a openas? T, b = b as? T {
>   // We've recovered the 'strong guarantee' that doSomething expects for T
>   doSomething(a, b)
> } else {
>   // Here's our trap
> }

Right... exactly what I wrote yesterday, from Doug having written it months ago.

You are still missing the dynamicType checking to make invoking comparable{} 
methods work.

and that could further be simplified with something like

If letAs a:T , y:T {
   // compatible types, but still possible for dynamic types to be different
}

LetAs is a strawman for 
Let a = a openas? T

> 
> The biggest problem is that this sort of solution would prohibit existentials 
> from being used in generic contexts where the existentials only have to be 
> "similar enough", not identical, for things to work out. Given how fuzzy 
> "similar enough" has proven to be, maybe that's not a terrible 

Re: [swift-evolution] Proposal: Filter split extension on Sequence to return tuple of sequences that meet criteria and that do not

[Thorsten Seitz via swift-evolution]

+1 from me for adding this method to the standard library.
I would prefer the name `partition(by:)` for it, though, under which I know it 
from other languages and which is quite fitting, I think.

-Thorsten 

> Am 08.06.2016 um 22:59 schrieb gadiraju praneeth via swift-evolution 
> :
> 
> I added an extension to do this, something like this:
> extension Array {
> func filterSplit(includeElement: (Element) -> Bool) -> ([Element], 
> [Element]) {
> var elementsSatisfyingCondition = [Element]()
> var elementsNotSatisfyingCondition = [Element]()
> 
> self.forEach { element in
> if includeElement(element) { 
> elementsSatisfyingCondition.append(element) }
> else { elementsNotSatisfyingCondition.append(element) }
> }
> 
> return (elementsSatisfyingCondition, elementsNotSatisfyingCondition)
> }
> }
> 
> that way you can right away do: values.filterSplit {  }
> 
> 
>> On Wed, Jun 8, 2016 at 3:40 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> on Wed Jun 08 2016, Dave Abrahams  wrote:
>> 
>> > on Wed Jun 08 2016, gadiraju praneeth  wrote:
>> >
>> >> Many times, I came across a scenario where I had to filter an array with a
>> >> condition and filter the same array with opposite of that condition. For
>> >> example:
>> >>
>> >> let values = [2, 4, 3, 5, 6, 9]
>> >>
>> >> let divisibleByTwo = values.filter { $0 % 2 == 0 }
>> >> let notDivisibleByTwo = values.filter { $0 % 2 != 0 }
>> >>
>> >> Is there a way currently where we can filter the array into two arrays
>> >> based on a condition?
>> >
>> > Well, you need a stable partition for this if you care about ordering
>> > (see
>> > https://github.com/apple/swift/blob/master/test/Prototypes/Algorithms.swift#L299)
>> > but then you can do
>> >
>> > var parts = values
>> > let mid = values.stablePartition { $0 % 2 == 0 }
>> > let divisibleByTwo = parts.prefix(upTo: mid)
>> > let notDivisibleByTwo = parts.suffix(from: mid)
>> >
>> > Nate Cook has an enhancement to the result of stablyPartitioned in that
>> > prototype that would let you write:
>> >
>> >   let parts = values.stablyPartitioned { $0 % 2 == 0 }
>> >   let divisibleByTwo = parts.prefix(upTo: parts.partitionPoint)
>> >   let notDivisibleByTwo = parts.suffix(from: parts.partitionPoint)
>> 
>> Hmm, come to think of it, Nate, maybe there should also be a more
>> convenient way to get the two partitions from the result.
>> 
>> --
>> Dave
>> 
>> ___
>> 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

[Brandon Knope via swift-evolution]

I am deeply saddened that a little part of character is lost in swift with the 
removal of where (imo). But I can be happy that ; is not being used I guess. 

My question: what is/was the rationale for adding where to swift 2? We seem to 
just be removing it everywhere now (or at least the proposals will be incoming)

Brandon 

Sent from my iPad

> On Jun 8, 2016, at 9:47 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> The review of SE-0099 "Restructuring Condition Clauses" ran from January 
> 13...18, 2016. The proposal has been accepted with revision for Swift 3. 
> There was near unanimous agreement that the Swift 2 grammar was inconsistent 
> and ambiguous and should be changed; most of the disagreement centered on 
> how. Many alternatives were discussed, including the following:
> 
> - The proposal as written suggests using ';' or newline as a separator. To 
> many people, this looked heavy, and it's also inconsistent with the rest of 
> the language, which never otherwise used semicolon as an intra-statement 
> separator (except in the defunct for;; loop).
> - Introducing a keyword separator, such as using 'where' everywhere or 
> introducing a new 'and' keyword, is also bulky and either reads poorly or 
> requires stealing new keywords.
> - Some commenters suggested using '&&' for consistency with simple boolean 
> conditions. This isn't workable due to precedence issues.
> - The ambiguities arise from the fact that there are comma-separated lists 
> within comma-separated lists—within the list of conditions, each 'case' or 
> 'let' condition can have multiple declarations. If we eliminated this 
> feature, so that every 'case' or 'let' condition had to start with 'case' or 
> 'let', the ambiguity is resolved, and comma can remain the condition 
> separator. This does break consistency with non-conditional 'let' 
> declarations and case clauses in 'switch' but is otherwise workable.
> 
> Of these alternatives, the core team found the last one to be the best 
> choice. 'case' and 'let' conditions should each specify a single declaration, 
> comma should remain the condition separator, and the 'where' keyword can be 
> retired from its purpose as a boolean condition introducer. Some code becomes 
> more verbose, but in common formatting patterns, it aligns more nicely, as in:
> 
>   guard
> let x = foo(),
> let y = bar(),
> let z = bas(),
> x == y || y == z else {
>   }
> 
> and though it breaks commonality between 'let' conditions and 'let' 
> declarations, it's more important to preserve higher-level consistency 
> throughout the language in how components of expressions and statements are 
> separated. Thanks everyone for the discussion, and thanks Erica and Chris for 
> the proposal! Since, aside from the approved syntax, the fundamental thrust 
> of the proposal remains the same, Chris has volunteered to revise it to be in 
> line with the approved decision.
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhanced existential types proposal discussion

[Austin Zheng via swift-evolution]

I think the generic typealiases Doug mentioned are a pretty good approximation 
of a type parameter on a protocol. After all, you should be able to do this:

typealias AnyCollection = Any

Speaking of which, I went ahead and rewrote the proposal based on Doug's 
feedback. I look forward to discussing it in depth later this year/early next 
year. (Suggestions for a better example than the ridiculous pet hotel example 
at the beginning especially welcome...)

https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md
 


Austin

> On Jun 8, 2016, at 11:57 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
>>> 
>>> FWIW, we also occasionally get "Swift should have parameterized
>>> protocols" in the context of multiple conformances by the same
>>> concrete type (as in things like ConvertibleTo protocol).
>> 
>> I know. From the bugs I've seen it's at least 10x as many requests for
>> "any collection of some element type" as for any actually reason why
>> one would need parameterize a protocols.
> 
> That does, however, speak for the idea that a concise and obvious syntax
> should be supported for that use-case.
> 
> Personally, it doesn't seem ridiculous to me that some associated types
> might usefully be written as type parameters on a protocol.  As
> Collection shows, not all associated types are equally important.
> Approximately nobody wants the existential “Collection where Index ==
> Int.”
> 
> -- 
> Dave
> 
> ___
> 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] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

[Chris Lattner via swift-evolution]

On Jun 8, 2016, at 7:27 PM, Brent Royal-Gordon via swift-evolution 
 wrote:
> However, if-let does not permit the analogous construct:
> 
>   guard let (x, y, z) = (foo(), bar(), bas()) else {
> 
> Now that we're moving away from allowing compound if-lets, I think it might 
> be a good idea to revisit that decision. Would this be better handled as a 
> separate proposal?

Yes, this should be a follow up pitch/proposal.  Thanks Brent,

-Chris
___
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

[Xiaodi Wu via swift-evolution]

On Wed, Jun 8, 2016 at 11:34 PM, Xiaodi Wu  wrote:

> On Wed, Jun 8, 2016 at 11:17 PM, Sean Heber via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Jun 8, 2016, at 10:51 PM, Erica Sadun via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Jun 8, 2016, at 9:36 PM, Brent Royal-Gordon 
>> wrote:
>>
>> Upon accepting SE-0099, the core team is removing `where` clauses from
>> condition clauses, writing "the 'where' keyword can be retired from its
>> purpose as a boolean condition introducer."
>>
>> Inspiried by Xiaodi Wu, I now propose removing `where` clauses from `for
>> in` loops, where they are better expressed (and read) as guard conditions.
>>
>>
>> Do you propose to remove `for case` as well? That can equally be handled
>> by a `guard case` in the loop body.
>>
>> Alternate proposal: Move `where` clauses to be adjacent to the
>> pattern—rather than the sequence expression—in a `for` loop, just as they
>> are in these other syntaxes.
>>
>> for n where n.isOdd in 1...1_000 { … }
>>
>> This makes them more consistent with the syntax in `switch` cases and
>> `catch` statements, while also IMHO clarifying the role of the `where`
>> clause as a filter on the elements seen by the loop.
>>
>>
>> I saw your post on that *after* I finished sending this. Moving `where`
>> next to the pattern, like you'd find in `catch` and switch `case`, the code
>> would look like this:
>>
>> for i where i % 2 == 0 in sequence {
>> // do stuff
>> }
>>
>>
>> This is the best version yet - the placement of 'where' makes total sense
>> and I really like it there.
>>
>>
>> I agree that's really clever and an improvement but after coming up with
>> all the points about wrong expectations about termination vs filtering, the
>> better use of guard, and fetishes about vertical compactness, I think (call
>> it +0.6) I'm going to stick to my guns on this one - and for `for case`
>> too. I've been wuxxed.
>>
>>
> Maybe it's the late hour and staring at this too much. For the moment I
> think I could live with either not having `where` like Erica proposes or
> having it moved like Brent proposes. Perhaps later I'll form a considered
> preference.
>
> Brent's idea is so new, yet I have to admit it does feel somehow--this is
> a squishy evaluation--satisfying? One thing about it that I like over
> previous proposals--that's if we're going to go down this route rather than
> taking out `while` altogether--is that the word `in` seems to instinctively
> encourage concision. It just feels weird to stuff too much between `for i`
> and `in`, so I think people will tend to use it in a more reasonable way
> (with nothing to prove this intuition at all, of course).
>
> Then again, it should come as no surprise that I agree with Erica that
> removing `while` altogether has the benefit of definitively eliminating any
> kind of misinterpretation as to termination vs. filtering. That's a win.
>

Yikes: s/while/where. That's my queue to quit for the day.


>
>
>> * New users might expect the sequence to terminate as soon as i % 2 is 1,
>> rather than the correct interpretation which is "this is a filtering
>> operation"
>> * The code can be expressed less ambiguously as
>>
>> for i in sequence.filter({ return i % 2 == 0 }) {
>> // do stuff
>> }
>>
>>
>> This seems to trade what was a very declarative syntax about the intent
>> of some code (especially with 'where' in the middle of the statement) for
>> one that injects its own specialized vocabulary into the context (knowing
>> what filter does, a function call, a closure with a return keyword and a
>> pair of extra braces and parenthesis!) which means, to me anyway,
>> significant cognitive overhead. It will also be a lot slower without
>> optimization enabled due to the intermediate array. (I've found
>> *significant* speed ups switching .forEach() with for loops in debug
>> builds, for example.)
>>
>>
>> * The while version can be expressed as
>>
>> for i in sequence.prefix(while: { return $0 % 2 == 0 } ) {
>> // do stuff
>> }
>>
>>
>> And now we've gone from, again, what is likely a very simple and
>> declarative style using a for/while kind of statement and turned it in to
>> something that has *even more* cognitive overhead to figure out what it
>> does because now I have to reason about what "prefix" means here (normally
>> I only think of prefix in the context of strings) and if there's a special
>> variation of it using the "while" argument that I need to also be aware
>> of...
>>
>> Maybe it's just me, but.. I don't get it. I want to be able to quickly
>> understand a piece of code's intent, not wade through fancy constructions
>> for their own sake.
>>
>> l8r
>> Sean - who might be too tired to be emailing responsibly
>>
>>
>> ___
>> 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

[Xiaodi Wu via swift-evolution]

On Wed, Jun 8, 2016 at 11:17 PM, Sean Heber via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jun 8, 2016, at 10:51 PM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jun 8, 2016, at 9:36 PM, Brent Royal-Gordon 
> wrote:
>
> Upon accepting SE-0099, the core team is removing `where` clauses from
> condition clauses, writing "the 'where' keyword can be retired from its
> purpose as a boolean condition introducer."
>
> Inspiried by Xiaodi Wu, I now propose removing `where` clauses from `for
> in` loops, where they are better expressed (and read) as guard conditions.
>
>
> Do you propose to remove `for case` as well? That can equally be handled
> by a `guard case` in the loop body.
>
> Alternate proposal: Move `where` clauses to be adjacent to the
> pattern—rather than the sequence expression—in a `for` loop, just as they
> are in these other syntaxes.
>
> for n where n.isOdd in 1...1_000 { … }
>
> This makes them more consistent with the syntax in `switch` cases and
> `catch` statements, while also IMHO clarifying the role of the `where`
> clause as a filter on the elements seen by the loop.
>
>
> I saw your post on that *after* I finished sending this. Moving `where`
> next to the pattern, like you'd find in `catch` and switch `case`, the code
> would look like this:
>
> for i where i % 2 == 0 in sequence {
> // do stuff
> }
>
>
> This is the best version yet - the placement of 'where' makes total sense
> and I really like it there.
>
>
> I agree that's really clever and an improvement but after coming up with
> all the points about wrong expectations about termination vs filtering, the
> better use of guard, and fetishes about vertical compactness, I think (call
> it +0.6) I'm going to stick to my guns on this one - and for `for case`
> too. I've been wuxxed.
>
>
Maybe it's the late hour and staring at this too much. For the moment I
think I could live with either not having `where` like Erica proposes or
having it moved like Brent proposes. Perhaps later I'll form a considered
preference.

Brent's idea is so new, yet I have to admit it does feel somehow--this is a
squishy evaluation--satisfying? One thing about it that I like over
previous proposals--that's if we're going to go down this route rather than
taking out `while` altogether--is that the word `in` seems to instinctively
encourage concision. It just feels weird to stuff too much between `for i`
and `in`, so I think people will tend to use it in a more reasonable way
(with nothing to prove this intuition at all, of course).

Then again, it should come as no surprise that I agree with Erica that
removing `while` altogether has the benefit of definitively eliminating any
kind of misinterpretation as to termination vs. filtering. That's a win.


> * New users might expect the sequence to terminate as soon as i % 2 is 1,
> rather than the correct interpretation which is "this is a filtering
> operation"
> * The code can be expressed less ambiguously as
>
> for i in sequence.filter({ return i % 2 == 0 }) {
> // do stuff
> }
>
>
> This seems to trade what was a very declarative syntax about the intent of
> some code (especially with 'where' in the middle of the statement) for one
> that injects its own specialized vocabulary into the context (knowing what
> filter does, a function call, a closure with a return keyword and a pair of
> extra braces and parenthesis!) which means, to me anyway, significant
> cognitive overhead. It will also be a lot slower without optimization
> enabled due to the intermediate array. (I've found *significant* speed ups
> switching .forEach() with for loops in debug builds, for example.)
>
>
> * The while version can be expressed as
>
> for i in sequence.prefix(while: { return $0 % 2 == 0 } ) {
> // do stuff
> }
>
>
> And now we've gone from, again, what is likely a very simple and
> declarative style using a for/while kind of statement and turned it in to
> something that has *even more* cognitive overhead to figure out what it
> does because now I have to reason about what "prefix" means here (normally
> I only think of prefix in the context of strings) and if there's a special
> variation of it using the "while" argument that I need to also be aware
> of...
>
> Maybe it's just me, but.. I don't get it. I want to be able to quickly
> understand a piece of code's intent, not wade through fancy constructions
> for their own sake.
>
> l8r
> Sean - who might be too tired to be emailing responsibly
>
>
> ___
> 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 a while clause to for loops

[Sean Heber via swift-evolution]

They would differ in, what at least to me, seems pretty logical ways:

>> while !stopped for unit in workToDo where unit.passesTest(condition) { 
>> unit.process() }

Would be:

while !stopped {
  for unit in workToDo where unit.passesTest(condition) {
unit.process()
  }
}


>> for unit in workToDo while !stopped where unit.passesTest(condition) { 
>> unit.process() }


Would be:

for unit in workToDo {
  guard !stopped else { break }
  If unit.passesTest(condition) { unit.process() }
}

This would likely read even better if "where" was woven into the for:

for unit where unit.passesTest(condition) in workToDo while !stopped { 
unit.process() }

Or possibly reformatted to something like:

for unit
  where unit.passesTest(condition)
  in workToDo
  while !stopped
{ unit.process() }

l8r
Sean

Sent from my iPad

> On Jun 8, 2016, at 5:42 PM, Tim Vermeulen  wrote:
> 
> I’m not sure I follow, how would the two be different?
> 
>> There might be value in entertaining the idea of unifying constructs such 
>> that they all allow arbitrary combinations of for/while/where/etc.
>> 
>> Such as:
>> 
>> while !stopped for unit in workToDo where unit.passesTest(condition) { 
>> unit.process() }
>> 
>> Which would mean something different than:
>> 
>> for unit in workToDo while !stopped where unit.passesTest(condition) { 
>> unit.process() }
>> 
>> And yes, they are very similar visually but differ subtly in meaning, but 
>> the same can be said about different sentences in english that might all 
>> share the same words and differ only by their order. It’s not exactly a 
>> foreign concept! I don’t know of any languages that are quite so expressive 
>> as that might be. Are there advantages to something more outlandish like 
>> this? I don’t know. I’m not proposing it directly, just thinking out loud, I 
>> guess.
>> 
>> l8r
>> Sean
>> 
>> 
>>> On Jun 8, 2016, at 4:44 PM, Haravikk via 
>>> swift-evolutionwrote:
>>> 
>>> 
 On 8 Jun 2016, at 17:11, Xiaodi Wuwrote:
> On Wed, Jun 8, 2016 at 3:38 AM, 
> Haravikkwrote:
> Yes this could be handled by an if/guard statement with continue, and 
> while as proposed here could be done with the same plus a break, but 
> these things come up so often that it just makes a lot of sense to get it 
> all neatly onto one line.
 
 As I pointed out above with Tim's example, putting it all on one line is 
 absolutely not 'neat'--it reads like spaghetti. That is one major beef I 
 have with this proposal: that it *encourages* writing on one line too many 
 things that, whether you use `where` or not, are much more clearly written 
 on multiple lines. If writing everything on one line is for you the major 
 advantage of this proposal, we could agree on everything else and I would 
 be very much opposed to this proposal on that basis alone.
>>> 
>>> I’m not proposing that every single loop have all of its conditions crushed 
>>> onto one line, just like I wasn’t when discussing where on the condition 
>>> clause thread. The usefulness of where and the proposed while is in the 
>>> common, simple cases, for example:
>>> 
>>> for eachValue in theValues while eachValue<100 where eachValue % 2 == 0 { … 
>>> }
>>> 
>>> The alternatives would be:
>>> 
>>> for eachValue in theValues {
>>> guard eachValue<100 else { break }
>>> guard eachValue % 2 == 0 else { continue }
>>> …
>>> }
>>> for eachValue in theValues.prefix(while: { $0<100 }).filter({ $0 % 2 == 0 
>>> }) { … } // Could also be on multiple lines
>>> 
>>> The former wastes vertical space for what it does IMO; it’s fine if the 
>>> conditions were more complicated, but since they’re not where/while is 
>>> ideal. The second isn’t terrible, but it’s a pretty noisy way to handle 
>>> common loop conditions.
>>> 
>>> The use of where/while isn’t about eliminating either of these 
>>> alternatives, they’re absolutely useful in cases where their drawbacks 
>>> become advantages. For example the inline guards are great when the 
>>> conditions are more complex, and necessary if you want to do more than the 
>>> simple cases allow. The second form is best when you need more than the two 
>>> methods, alternate methods, or you have predicates you can pass in 
>>> directly, although personally when I do this I tend to do the chinning on 
>>> its own lines outside of the loop, leaving me with a loop of: for eachValue 
>>> in theFilteredValues { … } or whatever.
>>> 
 Closures are--I'm sure you'd agree--a far more advanced concept than 
 loops. Concepts like closing over a variable are very, very hard. Many 
 useful things can be written without using closures. Not so many things 
 could do without loops. It very much matters that a learner might feel 
 that he or she cannot understand everything about a loop with the handwavy 
 explanation that it'll "come later”.
>>> 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[L. Mihalkovic via swift-evolution]

> On Jun 8, 2016, at 9:43 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> It's not possible, even with Swift's current implementation of existentials. 
> A protocol type P isn't considered to conform to itself, thus the following 
> is rejected:

The rules are not that simple, I seem to recall reading in sourcecode that 
there are criteria that decide if that is true or not. And by default the 
variable conform_to_self is even TRUE


> 
> let a : MyProtocol = // ...
> func myFunc(x: T) {
>   // 
> }
> myFunc(a) // "Cannot invoke 'myFunc' with an argument list of type MyProtocol"
> 
> Changing how this works is probably worth a proposal by itself.
> 
> Austin
> 
> 
>> On Wed, Jun 8, 2016 at 12:34 PM, Thorsten Seitz via swift-evolution 
>>  wrote:
>> 
>> > Am 08.06.2016 um 20:33 schrieb Dave Abrahams via swift-evolution 
>> > :
>> >
>> >
>> > on Tue Jun 07 2016, Matthew Johnson  wrote:
>> >
>> >>> On Jun 7, 2016, at 9:15 PM, Dave Abrahams  wrote:
>> >>>
>> >>>
>> >>> on Tue Jun 07 2016, Matthew Johnson > >>> > wrote:
>> >>>
>> >>
>> > On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution 
>> >  wrote:
>> >
>> >
>> > on Tue Jun 07 2016, Matthew Johnson  wrote:
>> >
>> 
>> >>> , but haven't realized
>> >>> that if you step around the type relationships encoded in Self
>> >>> requirements and associated types you end up with types that appear 
>> >>> to
>> >>> interoperate but in fact trap at runtime unless used in exactly the
>> >>> right way.
>> >>
>> >> Trap at runtime?  How so?  Generalized existentials should still be
>> >> type-safe.
>> >
>> > There are two choices when you erase static type relationships:
>> >
>> > 1. Acheive type-safety by trapping at runtime
>> >
>> > FloatingPoint(3.0 as Float) + FloatingPoint(3.0 as Double) // trap
>> >
>> > 2. Don't expose protocol requirements that involve these relationships,
>> > which would prevent the code above from compiling and prevent
>> > FloatingPoint from conforming to itself.
>> >
>> >> Or are you talking about the hypothetical types / behaviors people
>> >> think they want when they don’t fully understand what is happening...
>> >
>> > I don't know what you mean here.  I think generalized existentials will
>> > be nice to have, but I think most people will want them to do something
>> > they can't possibly do.
>> 
>>  Exactly.  What I meant is that people think they want that expression
>>  to compile because they don’t understand that the only thing it can do
>>  is trap.  I said “hypothetical” because producing a compile time error
>>  rather than a runtime trap is the only sane thing to do.  Your comment
>>  surprised me because I can’t imagine we would move forward in Swift
>>  with the approach of trapping.
>> >>>
>> >>> I would very much like to be able to create instances of “Collection
>> >>> where Element == Int” so we can throw away the wrappers in the stdlib.
>> >>> That will require some type mismatches to be caught at runtime via
>> >>> trapping.
>> >>
>> >> For invalid index because the existential accepts a type erased index?
>> >
>> > Exactly.
>> >
>> >> How do you decide where to draw the line here?  It feels like a very
>> >> slippery slope for a language where safety is a stated priority to
>> >> start adopting a strategy of runtime trapping for something as
>> >> fundamental as how you expose members on an existential.
>> >
>> > If you don't do this, the alternative is that “Collection where Element
>> > == Int” does not conform to Collection.  That's weird and not very
>> > useful.  You could expose all the methods that were on protocol
>> > extensions of Collection on this existential, unless they used
>> > associated types other than the element type.  But you couldn't pass the
>> > existential to a generic function like
>> >
>> >   func scrambled(_ c: C) -> [C.Element]
>> 
>> I don’t understand. Why couldn’t an existential be passed to that function?
>> 
>> -Thorsten
>> 
>> 
>> 
>> >
>> >> IMO you should *have* to introduce unsafe behavior like that manually.
>> >
>> >  Collection where Element == Int & Index == *
>> >
>> > ?
>> >
>> >> Collection indices are already something that isn’t fully statically
>> >> safe so I understand why you might want to allow this.
>> >
>> > By the same measure, so are Ints :-)
>> >
>> > The fact that a type's methods have preconditions does *not* make it
>> > “statically unsafe.”
>> >
>> >> But I don’t think having the language's existentials do this
>> >> automatically is the right approach.  Maybe there is another approach
>> >> that could be used in targeted use cases where the less safe behavior
>> >> makes sense and is 

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[Sean Heber via swift-evolution]

> On Jun 8, 2016, at 10:51 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>>> On Jun 8, 2016, at 9:36 PM, Brent Royal-Gordon  
>>> wrote:
>>> 
>>> Upon accepting SE-0099, the core team is removing `where` clauses from 
>>> condition clauses, writing "the 'where' keyword can be retired from its 
>>> purpose as a boolean condition introducer." 
>>> 
>>> Inspiried by Xiaodi Wu, I now propose removing `where` clauses from `for 
>>> in` loops, where they are better expressed (and read) as guard conditions.
>> 
>> Do you propose to remove `for case` as well? That can equally be handled by 
>> a `guard case` in the loop body.
>> 
>> Alternate proposal: Move `where` clauses to be adjacent to the 
>> pattern—rather than the sequence expression—in a `for` loop, just as they 
>> are in these other syntaxes.
>> 
>>  for n where n.isOdd in 1...1_000 { … }
>> 
>> This makes them more consistent with the syntax in `switch` cases and 
>> `catch` statements, while also IMHO clarifying the role of the `where` 
>> clause as a filter on the elements seen by the loop.
> 
> I saw your post on that *after* I finished sending this. Moving `where` next 
> to the pattern, like you'd find in `catch` and switch `case`, the code would 
> look like this:
> 
> for i where i % 2 == 0 in sequence {
> // do stuff
> }

This is the best version yet - the placement of 'where' makes total sense and I 
really like it there.


> I agree that's really clever and an improvement but after coming up with all 
> the points about wrong expectations about termination vs filtering, the 
> better use of guard, and fetishes about vertical compactness, I think (call 
> it +0.6) I'm going to stick to my guns on this one - and for `for case` too. 
> I've been wuxxed.
> 
> * New users might expect the sequence to terminate as soon as i % 2 is 1, 
> rather than the correct interpretation which is "this is a filtering 
> operation"
> * The code can be expressed less ambiguously as 
> 
> for i in sequence.filter({ return i % 2 == 0 }) {
> // do stuff
> }

This seems to trade what was a very declarative syntax about the intent of some 
code (especially with 'where' in the middle of the statement) for one that 
injects its own specialized vocabulary into the context (knowing what filter 
does, a function call, a closure with a return keyword and a pair of extra 
braces and parenthesis!) which means, to me anyway, significant cognitive 
overhead. It will also be a lot slower without optimization enabled due to the 
intermediate array. (I've found *significant* speed ups switching .forEach() 
with for loops in debug builds, for example.)


> * The while version can be expressed as
> 
> for i in sequence.prefix(while: { return $0 % 2 == 0 } ) {
> // do stuff
> }

And now we've gone from, again, what is likely a very simple and declarative 
style using a for/while kind of statement and turned it in to something that 
has *even more* cognitive overhead to figure out what it does because now I 
have to reason about what "prefix" means here (normally I only think of prefix 
in the context of strings) and if there's a special variation of it using the 
"while" argument that I need to also be aware of...

Maybe it's just me, but.. I don't get it. I want to be able to quickly 
understand a piece of code's intent, not wade through fancy constructions for 
their own sake.

l8r
Sean - who might be too tired to be emailing responsibly 

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

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

[L. Mihalkovic via swift-evolution]

> On Jun 8, 2016, at 7:21 PM, 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..
> 

Smilar solution to what java did.


> -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] custom attribute in userland (annotation).

[Brent Royal-Gordon via swift-evolution]

> What do you think to add custom attributes in Swift?
> 
> Example of use: 
> https://gist.github.com/euskadi31/2e15d21bc718b6f02f3497ad3e0a531d
> 
> For recovery of the attributes in the runtime, we could go through reflection 
> or in the compilation phase and accessible via a property or method.

Swift's current reflection APIs are massively underpowered to support this 
feature. For instance, there is no way to list or retrieve types, methods, 
initializers, subscripts, or most of the other things you would want to attach 
attributes to. Even property access is extremely limited—you can only list the 
names and values of all properties on a specific instance. Designing this would 
have to come before the sort of custom attributes you want, because there's 
simply no way to access the attributes without them.

You may be interested in the property behaviors proposal: 

 This would introduce a broadly similar feature for properties, though it would 
work in a different way: Rather than annotating entities with information you 
could discover through a reflection API, property behaviors would install 
custom getters and setters which could call into functionality provided by the 
instance, use storage private to the behavior, and offer per-property 
customization hooks along the lines of `willSet` and `didSet`.

Unfortunately, the proposal was sent back for revision, and at this point the 
team's focus is shifting towards implementing already-approved changes and 
polishing existing features as we get closer to release. I'm just a guy, not a 
member of the core team, but I'm guessing nothing in this space will be 
seriously considered before planning for Swift 4 begins.

-- 
Brent Royal-Gordon
Architechies

___
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

[Erica Sadun via swift-evolution]

> On Jun 8, 2016, at 9:36 PM, Brent Royal-Gordon  wrote:
> 
>> Upon accepting SE-0099, the core team is removing `where` clauses from 
>> condition clauses, writing "the 'where' keyword can be retired from its 
>> purpose as a boolean condition introducer." 
>> 
>> Inspiried by Xiaodi Wu, I now propose removing `where` clauses from `for in` 
>> loops, where they are better expressed (and read) as guard conditions. 
> 
> Do you propose to remove `for case` as well? That can equally be handled by a 
> `guard case` in the loop body.
> 
> Alternate proposal: Move `where` clauses to be adjacent to the pattern—rather 
> than the sequence expression—in a `for` loop, just as they are in these other 
> syntaxes.
> 
>   for n where n.isOdd in 1...1_000 { … }
> 
> This makes them more consistent with the syntax in `switch` cases and `catch` 
> statements, while also IMHO clarifying the role of the `where` clause as a 
> filter on the elements seen by the loop.

I saw your post on that *after* I finished sending this. Moving `where` next to 
the pattern, like you'd find in `catch` and switch `case`, the code would look 
like this:

for i where i % 2 == 0 in sequence {
// do stuff
}

I agree that's really clever and an improvement but after coming up with all 
the points about wrong expectations about termination vs filtering, the better 
use of guard, and fetishes about vertical compactness, I think (call it +0.6) 
I'm going to stick to my guns on this one - and for `for case` too. I've been 
wuxxed.

* New users might expect the sequence to terminate as soon as i % 2 is 1, 
rather than the correct interpretation which is "this is a filtering operation"
* The code can be expressed less ambiguously as 

for i in sequence.filter({ return i % 2 == 0 }) {
// do stuff
}

* The while version can be expressed as

for i in sequence.prefix(while: { return $0 % 2 == 0 } ) {
// do stuff
}

* The code can also use `guard` statements as needed with `break` and `continue`

(And yes, I should have pointed out filter and prefix as well as guard in my 
first email)

-- E

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

Re: [swift-evolution] Add a while clause to for loops

[Xiaodi Wu via swift-evolution]

That's a good insight, Brent. That placement of where is actually pretty
ingenious and probably unambiguous.
On Wed, Jun 8, 2016 at 22:23 Brent Royal-Gordon 
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

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[Brent Royal-Gordon via swift-evolution]

> Upon accepting SE-0099, the core team is removing `where` clauses from 
> condition clauses, writing "the 'where' keyword can be retired from its 
> purpose as a boolean condition introducer." 
> 
> Inspiried by Xiaodi Wu, I now propose removing `where` clauses from `for in` 
> loops, where they are better expressed (and read) as guard conditions. 

Do you propose to remove `for case` as well? That can equally be handled by a 
`guard case` in the loop body.

Alternate proposal: Move `where` clauses to be adjacent to the pattern—rather 
than the sequence expression—in a `for` loop, just as they are in these other 
syntaxes.

for n where n.isOdd in 1...1_000 { … }

This makes them more consistent with the syntax in `switch` cases and `catch` 
statements, while also IMHO clarifying the role of the `where` clause as a 
filter on the elements seen by the loop.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Add a while clause to for loops

[Brent Royal-Gordon via swift-evolution]

> 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

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Javier Soto via swift-evolution]

I agree we could disallow explicitly declaring implicitly unwrapped
function parameters, but this will be needed for the clang importer since
there will still be many C and ObjC APIs not tagged for nullability.
On Wed, Jun 8, 2016 at 2:46 PM Saagar Jha via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 I agree. Unwrapping in the functional signature is confusing for the
> user; many don’t realize that it puts the burden of checking on them.
> Non-optional function parameters make this explicit by preventing passing
> in Optional types, forcing the user to check, which they should be doing
> anyway.
>
> On Wed, Jun 8, 2016 at 12:22 PM J. Charles M. N. via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> This confused me at the beginning.
>>
>> But doesn't Int! In parameter type means the function is awaiting an
>> unwrapped value so the user should ensure that it data parameter is
>> available, valid, and unwrapped?
>>
>> --
>> J. Charles
>>
>> > Le 8 juin 2016 à 13:30, Spromicky via swift-evolution <
>> swift-evolution@swift.org> a écrit :
>> >
>> > Hello, everyone!
>> >
>> > I wanna propose to you to remove force unwrapping in fuction signature
>> for swift code. That no sense in clear swift code. If we wanna use some
>> optional value as function param, that is not optional, we must unwrap it
>> before function call.
>> > People who new in swift look at how they old Obj-C code (without
>> nullability modifiers) translate in to swift:
>> >
>> > Obj-C:
>> > - (void)foo:(NSInteger)bar {
>> >//...
>> > }
>> >
>> > Swift transaliton:
>> > func foo(bar: Int!) {
>> >//...
>> > }
>> >
>> > And think that force unwrapping in signature is good practice. And
>> start write functions in clear swift code like this:
>> >
>> > func newFoo(bar: Int!) {
>> >//...
>> > }
>> >
>> > and use it like this:
>> >
>> > let bar: Int? = 1
>> > newFoo(bar)
>> >
>> > And it really work, and they does not think that this can crash in case
>> if `bar` will be `nil`.
>> > But in clear swift we wanna work with parametrs in function that
>> clearly or optional, or not.
>> >
>> > func newFoo(bar: Int) {
>> >//...
>> > }
>> >
>> > or
>> >
>> > func newFoo(bar: Int?) {
>> >//...
>> > }
>> >
>> > When we write a new function we know what we need in this case and use
>> optional params or not.
>> >
>> > So my proposal is remove force unwrapping(`!`) from function
>> signatures, cause it have no sense, and that confuse new users.
>> > ___
>> > 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
>>
> --
> -Saagar Jha
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> Of these alternatives, the core team found the last one to be the best 
> choice. 'case' and 'let' conditions should each specify a single declaration, 
> comma should remain the condition separator, and the 'where' keyword can be 
> retired from its purpose as a boolean condition introducer. Some code becomes 
> more verbose, but in common formatting patterns, it aligns more nicely, as in:
> 
>   guard
> let x = foo(),
> let y = bar(),
> let z = bas(),
> x == y || y == z else {
>   }
> 
> and though it breaks commonality between 'let' conditions and 'let' 
> declarations, it's more important to preserve higher-level consistency 
> throughout the language in how components of expressions and statements are 
> separated.

I think this is a pretty good way to split the baby, especially because it 
actually improves an issue which always led to awkward indentation problems.

Even with this change, I believe you'll be able to avoid redundant `case` 
keywords by using tuples:

guard case (.none, .none, .none) = (foo(), bar(), bas()) else {

However, if-let does not permit the analogous construct:

guard let (x, y, z) = (foo(), bar(), bas()) else {

Now that we're moving away from allowing compound if-lets, I think it might be 
a good idea to revisit that decision. Would this be better handled as a 
separate proposal?

-- 
Brent Royal-Gordon
Architechies

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

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

[Joe Groff via swift-evolution]

The review of SE-0099 "Restructuring Condition Clauses" ran from January 
13...18, 2016. The proposal has been accepted with revision for Swift 3. There 
was near unanimous agreement that the Swift 2 grammar was inconsistent and 
ambiguous and should be changed; most of the disagreement centered on how. Many 
alternatives were discussed, including the following:

- The proposal as written suggests using ';' or newline as a separator. To many 
people, this looked heavy, and it's also inconsistent with the rest of the 
language, which never otherwise used semicolon as an intra-statement separator 
(except in the defunct for;; loop).
- Introducing a keyword separator, such as using 'where' everywhere or 
introducing a new 'and' keyword, is also bulky and either reads poorly or 
requires stealing new keywords.
- Some commenters suggested using '&&' for consistency with simple boolean 
conditions. This isn't workable due to precedence issues.
- The ambiguities arise from the fact that there are comma-separated lists 
within comma-separated lists—within the list of conditions, each 'case' or 
'let' condition can have multiple declarations. If we eliminated this feature, 
so that every 'case' or 'let' condition had to start with 'case' or 'let', the 
ambiguity is resolved, and comma can remain the condition separator. This does 
break consistency with non-conditional 'let' declarations and case clauses in 
'switch' but is otherwise workable.

Of these alternatives, the core team found the last one to be the best choice. 
'case' and 'let' conditions should each specify a single declaration, comma 
should remain the condition separator, and the 'where' keyword can be retired 
from its purpose as a boolean condition introducer. Some code becomes more 
verbose, but in common formatting patterns, it aligns more nicely, as in:

guard
  let x = foo(),
  let y = bar(),
  let z = bas(),
  x == y || y == z else {
}

and though it breaks commonality between 'let' conditions and 'let' 
declarations, it's more important to preserve higher-level consistency 
throughout the language in how components of expressions and statements are 
separated. Thanks everyone for the discussion, and thanks Erica and Chris for 
the proposal! Since, aside from the approved syntax, the fundamental thrust of 
the proposal remains the same, Chris has volunteered to revise it to be in line 
with the approved decision.

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

Re: [swift-evolution] Add a while clause to for loops

[Dany St-Amant via swift-evolution]

Le 8 juin 2016 à 19:05, Tim Vermeulen via swift-evolution 
 a écrit :

>> Since Swift strives to be an opinionated language without dialects, there 
>> shouldn't be more "choice" but rather one general solution, IMO.
> 
> I agree with you on this in general, but this proposal isn’t just about 
> adding choices to the language. At least, that’s not the point. It doesn’t 
> add any new functionality per se, but there might be value in making a common 
> coding pattern more shorter and more intuitive. `guard` is a lot more 
> powerful than `where` or `while` as discussed here, but such clauses can 
> possibly make code more readable. You don’t have to agree with me that those 
> clauses are actually more readable than using `guard`, but that’s the way I 
> see it and in my opinion it’s about more than just having more options.

I do not think shortness is that much a valid criteria (sorry), but 
expressiveness of the intention matter. A 'guard' send a message of a condition 
to be protected from; 'where' carry a notion of conditional criteria; while 
'while' suggest a on going state.

Having the choice between if/guard/where/while can be seen as confusing to 
newbie (which one should I use, why does this code use one over the other), but 
for an experimented developer it can help carry the intention behind the code 
better than a comment could.

Dany 

> In fact, if this proposal is accepted, one could consider `guard 
> someCondition else { continue/break }` at the start of a for loop to be a 
> code smell because a `where`/`while` clause could have been used instead. So 
> using those clauses would then be the general solution to the problem, which 
> is in line with what you said Swift strives to be.
> 
> To me this issue feels similar to adding `guard` despite already having `if` 
> (if we disregard `guard let` for a second). Now you can write both `guard 
> someCondition else { return }` and `if !someCondition { return }`, but I 
> would consider the first one the general solution and the second one code 
> smell. This pattern is so common that adding `guard` was justified.
> 
>> On Wed, Jun 8, 2016 at 1:58 PM, Tim 
>> Vermeulenwrote:
>>> That’s why I said “potentially less elegant”, some people might prefer 
>>> `where` over `guard`. This proposal would give them the choice (in very 
>>> specific situations) to use `where` rather than `guard` if they don’t want 
>>> to sacrifice performance.
>> Since Swift strives to be an opinionated language without dialects, there 
>> shouldn't be more "choice" but rather one general solution, IMO. Since 
>> `guard` doesn't sacrifice performance and is the most general, I would 
>> oppose adding the option of `while` to offer more choice.
>> 
>>> 
 On Wed, Jun 8, 2016 at 1:35 PM, Tim Vermeulen via 
 swift-evolutionwrote:
> This is a really strong argument in my opinion. If we don’t add a `while` 
> to for loops, then in some situations we will have to rewrite a `where` 
> clause to something potentially less elegant, given that we don’t want to 
> give up performance.
 I disagree. I argue that what you call "less elegant", namely if (or 
 guard) inside the loop, is the most elegant solution.
 
> 
>> IMO `.prefix` is just not the equal alternative for as proposed `while` :
>> in case of 'while' expression `number<4_000_000` will be calculated
>> *only* for those who `number % 2 == 0`. In case of `prefix` - the
>> expression will be processed for each `number` and only after this 
>> filtered
>> by `number % 2`. Let's assume we need to check for some
>> veryExpensiveTest(number):
>> 
>> for number in fibonacci where number % 2 == 0 while
>> veryExpensiveTest(number) {}
>> 
>> let numbers = fibonacci.prefix { veryExpensiveTest($0) }
>> for number in numbers where number % 2 == 0 {}
>> 
>> So, `while` for `for` loops just can't be always replaced with `prefix`
>> 
>>> On 08.06.2016 2:02, Xiaodi Wu via swift-evolution wrote:
>>> On Tue, Jun 7, 2016 at 5:11 PM, Tim 
>>> Vermeulen>> >wrote:
>>> 
>>> I’ve been thinking about this for a bit now, and I think it would make
>>> most sense to evaluate these clauses from left to right. However, cases
>>> where the order matters are very uncommon, and I would rather have the
>>> power to choose which clause is evaluated first than to have a forced
>>> default order. Either way I don’t see this as a reason not to allow
>>> combining the two clauses because IMO it can lead to some very clean
>>> code. For instance, say we want to loop through all even fibonacci
>>> numbers below 4 million (see problem #2 from project 

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

[Jordan Rose via swift-evolution]

> On Jun 8, 2016, at 12:02, Thorsten Seitz via swift-evolution 
>  wrote:
> 
>> 
>> Am 07.06.2016 um 22:27 schrieb L Mihalkovic > >:
>> 
>>> 
>>> On Jun 7, 2016, at 9:47 PM, Thorsten Seitz >> > wrote:
>>> 
>>> 
>>> 
>>> Am 07.06.2016 um 20:11 schrieb L Mihalkovic via swift-evolution 
>>> >:
>>> 
 T1 ===
 import Lib1
 var str = func2()  // lib1
 
 T2 ===
 import Lib1
 import func Lib2.func2
 var str = func2()  // lib2
>>> 
>>> Shouldn't func2() be ambiguous here? It is imported from Lib1 and from Lib2.
>>> 
>>> -Thorsten 
>> 
>> 
>> no, that is precisely the point .. it works!!  I am able to override 
>> whatever my laziness brought into scope from Lib1 (caused by my * import) 
>> with a meticulously chosen implementation from Lib2. It is brilliant. 
>> extensions on the other hand work differently (although something could 
>> undoubtedly be done about them, I cannot entirely convince myself that it is 
>> time well spent. It would be if that could be a stepping stone form 
>> something else (which I have not been able to identify so far).
> 
> So it is dependent on the order of the imports? That’s rather fragile IMO and 
> I would prefer having to solve clashes explicitly independent of import 
> order, e.g. by having to hide the version from Lib1:
> 
> import Lib1 hiding func2  // strawman syntax
> import func Lib2.func2

It doesn’t depend on the order, but it does consider naming a specific 
top-level value to be a “better” choice than importing the whole module, on the 
grounds that you wouldn’t have written it that way otherwise.

(I’ve been lukewarm on the entire feature of selective imports for a while 
since there are often a lot of helpers in the same module (think UITableView 
and UITableViewDataSource). We do seem to be gravitating towards making helper 
things nested, though (see SE-0086 
).)

This is getting a little off-topic from the problem of disambiguating members, 
though.

Jordan

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

Re: [swift-evolution] Philosophy of Swift

[Brent Royal-Gordon via swift-evolution]

Ack, hit Send while I was still typing.

> Swift does not believe in the no-win scenario. It does not assume that strong 
> typing must be cumbersome, that memory-safe code must be slow, or that a 
> language must choose whether to be high-level or low-level. If two things are 
> desirable, it doesn't just balance them against each other; it finds a way to 
> get more of both than you would have thought possible, usually through 
> careful design and 

compile-time logic.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Philosophy of Swift

[Brent Royal-Gordon via swift-evolution]

> How would you define Swift in your own words?

I'd say this, rather grandly:

Swift does not believe in the no-win scenario. It does not assume that strong 
typing must be cumbersome, that memory-safe code must be slow, or that a 
language must choose whether to be high-level or low-level. If two things are 
desirable, it doesn't just balance them against each other; it finds a way to 
get more of both than you would have thought possible, usually through careful 
design and 

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Add a while clause to for loops

[Tim Vermeulen via swift-evolution]

It’s funny that you use this example as an argument against this proposal, 
because what led me to propose the `while` clause in the first place was a very 
similar incident (but instead of using `where` expecting it to terminate early, 
I tried to use a `while` clause, not immediately realising this can’t currently 
be done).

> I support your position on the use of where and while/when being confusing in 
> the loop statement. I (and I know others) have for example used where in a 
> loop statement mistakenly thinking it would terminate the loop early but of 
> course learned that it basically filters what causes the loop body to be 
> executed. After the fact that made sense to me but it didn't click at first.
> 
> If you separate the loop statement (what you are looping over) from the 
> filter (continue) conditions and/or termination conditions (break, guard) I 
> also feel it can be clearer to eyeball quickly. Additionally it lends itself 
> to being debugged in a line based debugger.
> 
> -Shawn
> On Wed, Jun 8, 2016 at 9:11 AM Xiaodi Wu via 
> swift-evolutionwrote:
> > On Wed, Jun 8, 2016 at 3:38 AM, 
> > Haravikkwrote:
> > > 
> > > > On 8 Jun 2016, at 01:54, Xiaodi Wu via 
> > > > swift-evolutionwrote:
> > > > 
> > > > 1) It is spelled out exactly what happens when a condition is met. I no 
> > > > longer have to remember whether the word that describes breaking from a 
> > > > loop uses a place analogy ("where") or a time analogy ("while" or 
> > > > "when”).
> > > > 
> > > > (You cannot convince me that these words are intuitive when the meaning 
> > > > of "where" changes by context in today's Swift. Now, if you want to 
> > > > propose that these be named "breakif" and "continueif" instead, then 
> > > > I'd agree with you that they're intuitive names, but then they'd also 
> > > > be really ugly.)
> > > I’m not sure I agree that this is confusing,
> > 
> > Why would breaking from a loop intuitively use a place analogy and 
> > continuing to the next iteration use a time analogy? This is totally made 
> > up; hence, it is not intuitive. I make no argument about whether or not it 
> > would be conceptually confusing. If you renamed 'break' to 'foo' and 
> > 'continue' to 'bar', it would not be intuitive, but you could likewise 
> > argue that it's not confusing, in that 'foo' is clearly not 'bar'.
> > 
> > > a little extra to learn for new programmers perhaps but I think it’s 
> > > fairly intuitive:
> > > 
> > > while let value = foo.next() where someCondition(value) { … }
> > > 
> > > 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.
> > > 
> > > Yes this could be handled by an if/guard statement with continue, and 
> > > while as proposed here could be done with the same plus a break, but 
> > > these things come up so often that it just makes a lot of sense to get it 
> > > all neatly onto one line.
> > 
> > As I pointed out above with Tim's example, putting it all on one line is 
> > absolutely not 'neat'--it reads like spaghetti. That is one major beef I 
> > have with this proposal: that it *encourages* writing on one line too many 
> > things that, whether you use `where` or not, are much more clearly written 
> > on multiple lines. If writing everything on one line is for you the major 
> > advantage of this proposal, we could agree on everything else and I would 
> > be very much opposed to this proposal on that basis alone.
> > 
> > > Chaining methods can do this, but it’s actually less readable IMO, or 
> > > requires multiple lines to keep it clear which defeats the point.
> > > 
> > > 
> > 
> > 
> > For me, encouraging the use of multiple lines is the point. Tim's example 
> > demonstrated to me very clearly that clarity is not served by 

Re: [swift-evolution] Add a while clause to for loops

[Xiaodi Wu via swift-evolution]

On Wed, Jun 8, 2016 at 6:05 PM, Tim Vermeulen  wrote:

> > Since Swift strives to be an opinionated language without dialects,
> there shouldn't be more "choice" but rather one general solution, IMO.
>
> I agree with you on this in general, but this proposal isn’t just about
> adding choices to the language. At least, that’s not the point. It doesn’t
> add any new functionality per se, but there might be value in making a
> common coding pattern more shorter and more intuitive. `guard` is a lot
> more powerful than `where` or `while` as discussed here, but such clauses
> can possibly make code more readable. You don’t have to agree with me that
> those clauses are actually more readable than using `guard`, but that’s the
> way I see it and in my opinion it’s about more than just having more
> options.
>
> In fact, if this proposal is accepted, one could consider `guard
> someCondition else { continue/break }` at the start of a for loop to be a
> code smell because a `where`/`while` clause could have been used instead.
> So using those clauses would then be the general solution to the problem,
> which is in line with what you said Swift strives to be.
>
> To me this issue feels similar to adding `guard` despite already having
> `if` (if we disregard `guard let` for a second). Now you can write both
> `guard someCondition else { return }` and `if !someCondition { return }`,
> but I would consider the first one the general solution and the second one
> code smell. This pattern is so common that adding `guard` was justified.
>

Well, we shouldn't ignore `guard let`, because there's a major difference
between `guard let` and `if let`: the scope in which the unwrapping takes
place. When `guard` was introduced, it solved a real problem encountered in
everyday use: the `if let` pyramid of doom. If you'll recall, before the
introduction of `guard`, unwrapping several optionals in a row resulted in
code that was deeply indented and very unsightly to read. By contrast, I'm
arguing that the code being written currently is actually quite pretty
without `while` clauses in `for` loops, so I don't think the same parallels
apply.

There's another major feature of `guard`: it's not just a drop-in
replacement for `if !` because it enforces exiting the scope. Using `guard`
means you get an error when you forget to write something that exists the
scope, and I've been saved by that feature more than a few times. By
contrast, `where` or `while` does not enforce any comparable limits on what
comes after it (one conceivable limit, which apparently can't be enforced
by the grammar, is a semantic relationship between what's being looped over
and the boolean assertion that follows), nor does it even guarantee that
the loop will terminate! (I can write, for example, `for i in
sequence(first: 0, next: { $0 }) where 2 < 4 { ... }` and there's nothing
you could do to warn me!


>
> > On Wed, Jun 8, 2016 at 1:58 PM, Tim Vermeulen tvermeu...@me.com)>wrote:
> > > That’s why I said “potentially less elegant”, some people might prefer
> `where` over `guard`. This proposal would give them the choice (in very
> specific situations) to use `where` rather than `guard` if they don’t want
> to sacrifice performance.
> > Since Swift strives to be an opinionated language without dialects,
> there shouldn't be more "choice" but rather one general solution, IMO.
> Since `guard` doesn't sacrifice performance and is the most general, I
> would oppose adding the option of `while` to offer more choice.
> >
> > >
> > > >On Wed, Jun 8, 2016 at 1:35 PM, Tim Vermeulen via swift-evolution<
> swift-evolution@swift.org(mailto:swift-evolution@swift.org)(mailto:
> swift-evolution@swift.org)>wrote:
> > > >>This is a really strong argument in my opinion. If we don’t add a
> `while` to for loops, then in some situations we will have to rewrite a
> `where` clause to something potentially less elegant, given that we don’t
> want to give up performance.
> > > >I disagree. I argue that what you call "less elegant", namely if (or
> guard) inside the loop, is the most elegant solution.
> > > >
> > > >>
> > > >>>IMO `.prefix` is just not the equal alternative for as proposed
> `while` :
> > > >>>in case of 'while' expression `number<4_000_000` will be calculated
> > > >>>*only* for those who `number % 2 == 0`. In case of `prefix` - the
> > > >>>expression will be processed for each `number` and only after this
> filtered
> > > >>>by `number % 2`. Let's assume we need to check for some
> > > >>>veryExpensiveTest(number):
> > > >>>
> > > >>>for number in fibonacci where number % 2 == 0 while
> > > >>>veryExpensiveTest(number) {}
> > > >>>
> > > >>>let numbers = fibonacci.prefix { veryExpensiveTest($0) }
> > > >>>for number in numbers where number % 2 == 0 {}
> > > >>>
> > > >>>So, `while` for `for` loops just can't be always replaced with
> `prefix`
> > > >>>
> > > >>>On 08.06.2016 2:02, Xiaodi Wu via swift-evolution wrote:
> > > 

Re: [swift-evolution] Philosophy of Swift

[Paul Cantrell via swift-evolution]

On Jun 8, 2016, at 6:13 PM, Dave Abrahams via swift-evolution 
 wrote:
> 
> on Wed Jun 08 2016, Paul Cantrell  wrote:
> 
>> The interplay of the first two and the last two is what makes the
>> language unique. For example, structs have a simple, high-level
>> programmer model — “pass by value semantics” — but the compiler jumps
>> through all those COW hoops to make them perform _most_ of the time as
>> if they were C structs statically allocated and then passed by
>> pointer.
> 
> I have no argument with most of what you wrote, but this part is just
> inaccurate.  Plain structs are never CoW'd, and the compiler doesn't
> introduce CoW.  The standard library implements CoW “manually” for
> specific types like Array and String. 

So then only language/runtime magic is isUniquelyReferenced(), and all the 
other “hoops” are in the standard lib?

I guess I just lump compiler and standard library together in my mind too 
carelessly!

P

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

Re: [swift-evolution] Philosophy of Swift

[Dave Abrahams via swift-evolution]

on Wed Jun 08 2016, Paul Cantrell  wrote:

> The interplay of the first two and the last two is what makes the
> language unique. For example, structs have a simple, high-level
> programmer model — “pass by value semantics” — but the compiler jumps
> through all those COW hoops to make them perform _most_ of the time as
> if they were C structs statically allocated and then passed by
> pointer.

I have no argument with most of what you wrote, but this part is just
inaccurate.  Plain structs are never CoW'd, and the compiler doesn't
introduce CoW.  The standard library implements CoW “manually” for
specific types like Array and String. 

-- 
Dave

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

Re: [swift-evolution] Add a while clause to for loops

[Tim Vermeulen via swift-evolution]

> Since Swift strives to be an opinionated language without dialects, there 
> shouldn't be more "choice" but rather one general solution, IMO.

I agree with you on this in general, but this proposal isn’t just about adding 
choices to the language. At least, that’s not the point. It doesn’t add any new 
functionality per se, but there might be value in making a common coding 
pattern more shorter and more intuitive. `guard` is a lot more powerful than 
`where` or `while` as discussed here, but such clauses can possibly make code 
more readable. You don’t have to agree with me that those clauses are actually 
more readable than using `guard`, but that’s the way I see it and in my opinion 
it’s about more than just having more options.

In fact, if this proposal is accepted, one could consider `guard someCondition 
else { continue/break }` at the start of a for loop to be a code smell because 
a `where`/`while` clause could have been used instead. So using those clauses 
would then be the general solution to the problem, which is in line with what 
you said Swift strives to be.

To me this issue feels similar to adding `guard` despite already having `if` 
(if we disregard `guard let` for a second). Now you can write both `guard 
someCondition else { return }` and `if !someCondition { return }`, but I would 
consider the first one the general solution and the second one code smell. This 
pattern is so common that adding `guard` was justified.

> On Wed, Jun 8, 2016 at 1:58 PM, Tim 
> Vermeulenwrote:
> > That’s why I said “potentially less elegant”, some people might prefer 
> > `where` over `guard`. This proposal would give them the choice (in very 
> > specific situations) to use `where` rather than `guard` if they don’t want 
> > to sacrifice performance.
> Since Swift strives to be an opinionated language without dialects, there 
> shouldn't be more "choice" but rather one general solution, IMO. Since 
> `guard` doesn't sacrifice performance and is the most general, I would oppose 
> adding the option of `while` to offer more choice.
> 
> > 
> > >On Wed, Jun 8, 2016 at 1:35 PM, Tim Vermeulen via 
> > >swift-evolutionwrote:
> > >>This is a really strong argument in my opinion. If we don’t add a `while` 
> > >>to for loops, then in some situations we will have to rewrite a `where` 
> > >>clause to something potentially less elegant, given that we don’t want to 
> > >>give up performance.
> > >I disagree. I argue that what you call "less elegant", namely if (or 
> > >guard) inside the loop, is the most elegant solution.
> > >
> > >>
> > >>>IMO `.prefix` is just not the equal alternative for as proposed `while` :
> > >>>in case of 'while' expression `number<4_000_000` will be calculated
> > >>>*only* for those who `number % 2 == 0`. In case of `prefix` - the
> > >>>expression will be processed for each `number` and only after this 
> > >>>filtered
> > >>>by `number % 2`. Let's assume we need to check for some
> > >>>veryExpensiveTest(number):
> > >>>
> > >>>for number in fibonacci where number % 2 == 0 while
> > >>>veryExpensiveTest(number) {}
> > >>>
> > >>>let numbers = fibonacci.prefix { veryExpensiveTest($0) }
> > >>>for number in numbers where number % 2 == 0 {}
> > >>>
> > >>>So, `while` for `for` loops just can't be always replaced with `prefix`
> > >>>
> > >>>On 08.06.2016 2:02, Xiaodi Wu via swift-evolution wrote:
> > On Tue, Jun 7, 2016 at 5:11 PM, Tim 
> > Vermeulen > >wrote:
> > 
> > I’ve been thinking about this for a bit now, and I think it would make
> > most sense to evaluate these clauses from left to right. However, cases
> > where the order matters are very uncommon, and I would rather have the
> > power to choose which clause is evaluated first than to have a forced
> > default order. Either way I don’t see this as a reason not to allow
> > combining the two clauses because IMO it can lead to some very clean
> > code. For instance, say we want to loop through all even fibonacci
> > numbers below 4 million (see problem #2 from project euler), we could
> > do this:
> > 
> > `for number in fibonacci where number % 2 == 0 while number<4_000_000
> > { }`
> > 
> > 
> > This statement looks like spaghetti to me. I would not at all support
> > extending the language to permit it. Do you really think it's more 
> > readable
> > than going step-by-step?
> > 
> > ```
> > let numbers = fibonacci.prefix { $0<4_000_000 }
> > for number in numbers where number % 2 == 0 {
> > // ...
> > }
> > ```
> > 
> > or just:
> > 
> > ```
> > let numbers = fibonacci.prefix { $0<4_000_000 }
> > let evens = numbers.filter { $0 % 2 == 0 }
> > 

[swift-evolution] [Proposal] XCTFail should be @noreturn

[Alexander Momchilov via swift-evolution]

Because XCTFail() isn't annotated @noreturn, it isn't sufficient in a guard 
statement

guard var b = a as? B else {
XCTFail("Result wasn't castable to B")
return //this is redundant
}

This could be broken down into a XCTAssertTrue(a is B) statement, followed by a 
forced cast, but that seems redundant.

I realize that continueAfterFailure exists to make the test cases continue even 
after failures. This complicates the solution beyond just adding the @noreturn 
annotation.

The only solution I can think of happens to be the simplest: add a new 
variation of XCTFail() that ignores continueAfterFailure, such as 
XCTAlwaysFail()

A true solution would be for the @noreturn attribute to be conditional… the 
compiler would somehow need to be aware of the continueAfterFailure property's 
value. I don't know how that could be done.

Thoughts?


- Regards,
Alexander Momchilov

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

Re: [swift-evolution] Remove nil and NilLiteralConvertible

[Brandon Knope via swift-evolution]

Here I have a contrived example (I am bad at trying to explain my point -_-):

When I see nil, I think of reference types. I.e. Objective-C:

NSMutableString *mutableString = [[NSMutableString alloc] 
initWithString:@"123"];
__weak NSMutableString *reference = mutableString;

reference = mutableString;

[reference appendString:@"456"];
mutableString = nil;

//memory is now deallocated because strong references are eliminated
// BUT reference is now nil! This is expected with reference types

In Objective-C we have to use nil to manage when objects are deallocated. We 
also have to use __weak to avoid retain cycles etc...

This behavior is consistent with other languages with reference semantics.

However, in Swift, optionals are value types as we all know (though they can 
wrap reference types):

var number1: Int? = nil
var number2: Int? = number1

number1 == number2

number1 = 3
number2 == number1 // FALSE. This behavior is obviously different from 
Objective-C and we expect that knowing that it’s a value type


On first look, it looks like reference semantics because you see nil and 
remember it from other languages. OR you learn this behavior in Swift and 
expect it to work the same in other languages. Either way the behavior isn’t 
exactly consistent between all languages. Even nil in Objective-C is different 
than most languages because you are allowed to send messages to it.

As far as I know, setting:
number1 = nil

does not deallocate number1. It is still an optional with enough space to wrap 
an Int that happens to just be set to .none currently.

It looks like you are deallocating something if that is the behavior you expect 
from other languages upon seeing nil.

nil can have similar behaviors in both languages, but they can also have very 
dissimilar behaviors too.

My main point comes down to: nil makes it look like a pointer and thus makes 
you see it as a reference type at first glance until you completely retrain 
yourself. This is not how nil works with values in Swift and I think some might 
find that surprising down the road when:
A) They learn Swift first and move to another language and see a different 
behavior than they are use to
B) They come from another language and associate seeing nil with the type being 
a reference and being surprised

or C…you just have to remember the differences.

I probably made my point even worse but I can only try!
Brandon



> On Jun 8, 2016, at 5:37 PM, Sean Heber  wrote:
> 
> When isn’t it?
> 
> l8r
> Sean
> 
> 
>> On Jun 8, 2016, at 4:22 PM, Brandon Knope  wrote:
>> 
>> Yes it is the same keyword, but is it the same behavior from other languages?
>> 
>> Brandon
>> 
>>> On Jun 8, 2016, at 5:20 PM, Saagar Jha  wrote:
>>> 
>>> I think we also need to consider newbies coming from other languages. “nil” 
>>> being a holdover makes it easier to understand what it means, having a 
>>> “.none”/“none” duality makes it both seem inconsistent as well as dredge up 
>>> language implementation details-now you have to explain that Optionals are 
>>> actually enums internally. Using nil doesn’t lead to this kind of scenario, 
>>> and they already (mostly) know what it means from other languages.
>>> 
>>> On Wed, Jun 8, 2016 at 2:13 PM Sean Heber via swift-evolution 
>>>  wrote:
>>> If there’s both “.none” and “none”, then I think that’d be more confusing 
>>> *because of* the naming consistency, IMO. I’d look at that as a newbie and 
>>> wonder why in the world this word sometimes has a dot and sometimes doesn’t.
>>> 
>>> If enum cases could be referred to without the leading “.” then perhaps I 
>>> could get behind this because “none” wouldn’t even need to be a keyword at 
>>> all in that case, but there are probably difficult ambiguities down that 
>>> road.
>>> 
>>> l8r
>>> Sean
>>> 
>>> 
 On Jun 8, 2016, at 4:04 PM, Brandon Knope  wrote:
 
 1. People will find .none ugly which is why I think it could be replaced 
 by a none keyword. It is awkward
 2. none is more descriptive than nil in this case. The case is named none 
 (consistency!) and nil is a holdover from other languages
 
 I understand how nil works in the context of other languages. But looking 
 at Optional:
 public enum Optional : NilLiteralConvertible {
 
/// The absence of a value.
///
/// In code, the absence of a value is typically written using the `nil`
/// literal rather than the explicit `.none` enumeration case.
case none
 
/// The presence of a value, stored as `Wrapped`.
case some(Wrapped)
 }
 
 
 These are not pointers and they sure look like one when you assign nil to 
 an optional
 
 B
 
 Why would nil be chosen to represent the none case in the absence of other 
 languages?
 
 
> On Jun 8, 2016, at 4:55 PM, Sean Heber 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Austin Zheng via swift-evolution]

On Wed, Jun 8, 2016 at 3:22 PM, Dave Abrahams  wrote:

>
> on Wed Jun 08 2016, Austin Zheng  wrote:
>
> > FWIW my opinion is that existentials either shouldn't be allowed to stand
> > in for generic type parameters, or Dave's option #1 if they are.
>
> Don't you mean #2?  Otherwise I'm confused.  #1 is the one that
> prohibits more usages.
>

I'm just being cautious until a better solution comes along.


>
> > The implied promise of a generic type parameter T right now is that T
> > always stands for the same concrete type (modulo things like passing
> > in a subclass where a class would do), and likewise for all of T's
> > associated types (T.Foo is always the same type everywhere in the
> > context where T is valid). This is what makes using anything with
> > 'self' requirements in a generic context sound. Allowing existentials
> > to satisfy T would violate that constraint.
>
> Not if you consider Any to be a
> concrete type.  Concrete w.r.t. to a generic parameter means something
> different from Concrete w.r.t. subtyping.
>

You can consider Any to be a concrete
type, but then you have the unprecedented situation where the associated
types associated with a concrete type aren't necessarily the same for all
instances (is this true for any type that can satisfy a generic type
parameter today?).

(For the sake of this argument, Array isn't a concrete type, but Array
or Array is. You can't use 'Array' anywhere in Swift today, so I think
my assertion is fair.)

My understanding is that fixing the generic type parameter T by
specializing a function/type also fixes all the associated types associated
with T. This 'contract' would have to be weakened to allow existential
types to satisfy generic type parameters in any non-trivial way.


>
> > Relaxing these semantics would make it too easy to write code that
> > traps at runtime "without the user having to reach" (to paraphrase
> > Jordan from the "Swift philosophy" thread). Anyone who really really
> > wants to write code that is 'compile-time unsound' in this way should
> > have to explicitly type erase using concrete wrappers.
>
> I'd really like to see the use-cases, to make sure that these restricted
> existentials will be useful enough to be worth implementing.
>

This is enormously important.

First of all, (of course you know) there is a semantic difference between:

protocol Pet : class { }; class Cat : Pet { }; class Dog : Pet { }

class AnimalShelter { var pet: T }

and

class AnimalShelter { var pet: Pet }

This is something you can express for simple existentials today (the code
above should run, with minor modifications), but not for existentials
containing associated types or self requirements.

I think a big part of what people want to do is to declare variables, pass
args to functions, and get return values from functions that abstract over
something like Collection. They want to do this without having to make
their code generic, and without forcing their code to be homogenous at
runtime (e.g. an instance of the dynamic AnimalShelter can be populated
with a cat and later a dog, but the generic one can only ever contain
either; extend this to Collections of Ints or whatnot).

The big problem is that existentials can't guarantee that they satisfy the
contract generic functions and types are expecting, as we've been
discussing.

To be honest, I think requiring existentials to be opened should be a
prerequisite to using them generically. This would define away the
impedance mismatch at the expense of making certain things marginally
harder to do. (An alternate way of thinking about it is that it would make
the potential for a runtime error explicit, and localize it):

func doSomething(x: C, y: C) { ... }

let a : Any
let b : Any

// Prohibit this...
// doSomething(a, b)

// Allow this:
if let a = a openas? T, b = b as? T {
  // We've recovered the 'strong guarantee' that doSomething expects for T
  doSomething(a, b)
} else {
  // Here's our trap
}

The biggest problem is that this sort of solution would prohibit
existentials from being used in generic contexts where the existentials
only have to be "similar enough", not identical, for things to work out.
Given how fuzzy "similar enough" has proven to be, maybe that's not a
terrible tradeoff.


>
> >
> >
> > Best,
> > Austin
> >
> > On Wed, Jun 8, 2016 at 2:37 PM, Austin Zheng 
> wrote:
> >
> >> We might be talking past each other. I think Matthew is talking about
> >> using an existential outside the context of generic functions. For
> example,
> >> something like this should be trap-proof (as long as 'x' is immutable,
> >> which it is in this example):
> >>
> >> func copySequenceIntoArray(x: Any >> Int>) -> [Int] {
> >> var buffer : [Int] = []
> >> // Stupid implementation to make a point
> >> var iterator : x.Iterator = x.makeIterator()
> >> while true {
> >> let nextItem : Int? = iterator.next()
> >> if let nextItem = nextItem {
> >> 

Re: [swift-evolution] Add a while clause to for loops

[Tim Vermeulen via swift-evolution]

I’m not sure I follow, how would the two be different?

> There might be value in entertaining the idea of unifying constructs such 
> that they all allow arbitrary combinations of for/while/where/etc.
> 
> Such as:
> 
> while !stopped for unit in workToDo where unit.passesTest(condition) { 
> unit.process() }
> 
> Which would mean something different than:
> 
> for unit in workToDo while !stopped where unit.passesTest(condition) { 
> unit.process() }
> 
> And yes, they are very similar visually but differ subtly in meaning, but the 
> same can be said about different sentences in english that might all share 
> the same words and differ only by their order. It’s not exactly a foreign 
> concept! I don’t know of any languages that are quite so expressive as that 
> might be. Are there advantages to something more outlandish like this? I 
> don’t know. I’m not proposing it directly, just thinking out loud, I guess.
> 
> l8r
> Sean
> 
> 
> > On Jun 8, 2016, at 4:44 PM, Haravikk via 
> > swift-evolutionwrote:
> > 
> > 
> > > On 8 Jun 2016, at 17:11, Xiaodi Wuwrote:
> > > > On Wed, Jun 8, 2016 at 3:38 AM, 
> > > > Haravikkwrote:
> > > > Yes this could be handled by an if/guard statement with continue, and 
> > > > while as proposed here could be done with the same plus a break, but 
> > > > these things come up so often that it just makes a lot of sense to get 
> > > > it all neatly onto one line.
> > > 
> > > As I pointed out above with Tim's example, putting it all on one line is 
> > > absolutely not 'neat'--it reads like spaghetti. That is one major beef I 
> > > have with this proposal: that it *encourages* writing on one line too 
> > > many things that, whether you use `where` or not, are much more clearly 
> > > written on multiple lines. If writing everything on one line is for you 
> > > the major advantage of this proposal, we could agree on everything else 
> > > and I would be very much opposed to this proposal on that basis alone.
> > 
> > I’m not proposing that every single loop have all of its conditions crushed 
> > onto one line, just like I wasn’t when discussing where on the condition 
> > clause thread. The usefulness of where and the proposed while is in the 
> > common, simple cases, for example:
> > 
> > for eachValue in theValues while eachValue<100 where eachValue % 2 == 0 { … 
> > }
> > 
> > The alternatives would be:
> > 
> > for eachValue in theValues {
> > guard eachValue<100 else { break }
> > guard eachValue % 2 == 0 else { continue }
> > …
> > }
> > for eachValue in theValues.prefix(while: { $0<100 }).filter({ $0 % 2 == 0 
> > }) { … } // Could also be on multiple lines
> > 
> > The former wastes vertical space for what it does IMO; it’s fine if the 
> > conditions were more complicated, but since they’re not where/while is 
> > ideal. The second isn’t terrible, but it’s a pretty noisy way to handle 
> > common loop conditions.
> > 
> > The use of where/while isn’t about eliminating either of these 
> > alternatives, they’re absolutely useful in cases where their drawbacks 
> > become advantages. For example the inline guards are great when the 
> > conditions are more complex, and necessary if you want to do more than the 
> > simple cases allow. The second form is best when you need more than the two 
> > methods, alternate methods, or you have predicates you can pass in 
> > directly, although personally when I do this I tend to do the chinning on 
> > its own lines outside of the loop, leaving me with a loop of: for eachValue 
> > in theFilteredValues { … } or whatever.
> > 
> > > Closures are--I'm sure you'd agree--a far more advanced concept than 
> > > loops. Concepts like closing over a variable are very, very hard. Many 
> > > useful things can be written without using closures. Not so many things 
> > > could do without loops. It very much matters that a learner might feel 
> > > that he or she cannot understand everything about a loop with the 
> > > handwavy explanation that it'll "come later”.
> > 
> > Not my point at all; my point was about the shorthand for closures not 
> > closure as a whole, you can’t learn the closure shorthands without first 
> > learning what a closure is. In exactly the same way where/while are just be 
> > shorthands for inline if/guard, you don’t need to learn about these clauses 
> > to make a functioning loop if you know how to do it with your if/guard 
> > statements. In fact it’s better to learn it in this order as once you know 
> > what each clause is a shorthand form of (if/guard continue or break) then 
> > you know exactly what it does already.
> > 
> > 
> > Ignoring for a moment that you’re opposed to the where clause in general, 
> > what would your thoughts be on only permitting one of where/while in a for? 
> > i.e- you would be able to do only one of:
> > 
> > for eachValue in theValues where eachValue % 2 == 0 { … }
> > for eachValue in theValues 

Re: [swift-evolution] extend trailing closure rule

[Erica Sadun via swift-evolution]

> On Jun 8, 2016, at 4:11 PM, Matt Neuburg via swift-evolution 
>  wrote:
> 
> Well, I guess I didn't pick a strong enough case. Try this one:
> 
>UIView.animate(withDuration:0.4, delay: 0, options: [.autoreverse]) {
>self.view.backgroundColor = UIColor.red()
>}
> 
> That doesn't compile. I'm suggesting that it would be cool if it did. m.

Mid-call closure can mean one of several things:

1. Bad design
2. Multiple closures
3. Design before Swift / ObjC focused

To which:

1. Well, not sure that should be "fixed"
2. I think multiple closures should all be treated the same without trailing
3's a different kind of thing. I vaguely endorse having Cocoa request how it 
should be imported beyond the SE-0005 rules. 

We were kicking around some ideas on "how should defaults embetter" that this 
kind of relates to: 
https://gist.github.com/erica/3987ec54b8f4a580ae5fc18f4e9e7ca5 
  In this 
example, I can see a rule of "if there's only one closure named animation, 
completion, etc, promote it to the last argument". Kind of.

-- E, dithery



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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Austin Zheng via swift-evolution]

(inline)

On Wed, Jun 8, 2016 at 3:18 PM, Dave Abrahams  wrote:

>
> on Wed Jun 08 2016, Austin Zheng  wrote:
>
> > We might be talking past each other. I think Matthew is talking about
> using
> > an existential outside the context of generic functions. For example,
> > something like this should be trap-proof (as long as 'x' is immutable,
> > which it is in this example):
>
> [Ugh, Austin, your mail program is stripping the tabs out of the
> plaintext part so the indendation is lost.  Grabbing from browser...]
>

Sorry! I'm using gmail in the browser. I'll stay away from tabs...


>
> > func copySequenceIntoArray(x: Any Int>) -> [Int] {
> >   var buffer : [Int] = []
> > // Stupid implementation to make a point
> >   var iterator : x.Iterator = x.makeIterator()
> >   while true {
> >   let nextItem : Int? = iterator.next()
> >   if let nextItem = nextItem {
> >   buffer.append(nextItem)
> >   } else {
> >   return buffer
> >   }
> >   }
> > }
>
> Presumably this would “work” as well?
>
>   typealias IntSequence = Any
>   func f(x: IntSequence, y: IntSequence) {
> var i = x.makeIterator()
> i = y.makeIterator() // <== NO TRAP HERE, EVER.
>   }
>

This presumably wouldn't compile. The sort-of-dependent-type "x.Iterator"
(return value of x.makeIterator(); inferred as type of 'i'), and
"y.Iterator" (return type of y.makeIterator()) would not be considered
equivalent.

(As Doug mentioned in a recent email, it would only be feasible to expose
such types on immutable values. The intention is not to allow the
largely-meaningless code that follows:

func f(x: IntSequence, y: IntSequence) {
  var z : IntSequence = x
  var something : z.Iterator = x.makeIterator()
  z = y
  something = y.makeIterator()
  // ...
}
)


>
> > Even this would never trap as well:
> >
> > func copySequenceIntoArray(x: Any T>) -> [T] {
> >   var buffer : [T] = []
> >   for item in x {
> >   buffer.append(item)
> >   }
> >   return buffer
> > }
>
> Sure, this one is simple because the associated type is never even
> exposed.
>
> > Where we run into difficulty is something like this (forgive my abuse
> > of the collections API; I don't remember all the new indexing APIs off
> > the top of my head):
> >
> > func doSomething(x: T, y: T) {
> >   // Get indexes out of x and use them to index into y
> >   var idx = x.startIndex
> >   while (idx != x.endIndex || idx != y.endIndex) {
> >   print(x[idx])
> >   print(y[idx])
> >   idx = x.nextIndex(idx)
> >   }
> > }
> > let someSeq : Any = // ...
> > let anotherSeq : Any = // ...
> > // Trouble!
> > // someSeq and anotherSeq are the same existential type
> > // But the concrete index types within each of the existential variables
> may be different
> > doSomething(someSeq, anotherSeq)
> >
> > may be different
> > doSomething(someSeq, anotherSeq)
> >
> > It's this situation (using an existential type to fulfill a generic
> > type parameter constrained to the same requirements that comprise that
> > existential) that requires either of the two options that Dave
> > presented, due to our lack of compile-time type information about the
> > fulfilling type's associated types.
>
> Exactly.  But much simpler cases will also either have to trap at
> runtime or be prohibited outright:
>

Of course. I don't know what the right solution to this is yet.


>
>   func subscript_(c: C, i: C.Index) -> C.Collection.Element
> {
> return c[i]
>   }
>
>   typealias IntCollection = Any
>   let c1: IntCollection = ...
>   let c2: IntCollection = c1[3..<10]
>   let c3: IntCollection = ...
>   let c4: IntCollection = c1.reversed()
>
>   // Note: the underlying index types are the same, and are supposed to
>   // interoperate.  What do you do (work/trap/nocompile)?
>   _ = subscript_(c1, c2.startIndex)
>
>   // The underlying index types happen to be the same, and are not
>   // supposed to interoperate.  What do you do (silently
> “work”/trap/nocompile)?
>   _ = subscript_(c1, c3.startIndex)
>
>   // The underlying index types are different.  What do you do
> (trap/nocompile)?
>   _ = subscript_(c1, c4.startIndex)
>
> --
> Dave
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Dave Abrahams via swift-evolution]

on Wed Jun 08 2016, Austin Zheng  wrote:

> FWIW my opinion is that existentials either shouldn't be allowed to stand
> in for generic type parameters, or Dave's option #1 if they are.

Don't you mean #2?  Otherwise I'm confused.  #1 is the one that
prohibits more usages.

> The implied promise of a generic type parameter T right now is that T
> always stands for the same concrete type (modulo things like passing
> in a subclass where a class would do), and likewise for all of T's
> associated types (T.Foo is always the same type everywhere in the
> context where T is valid). This is what makes using anything with
> 'self' requirements in a generic context sound. Allowing existentials
> to satisfy T would violate that constraint.

Not if you consider Any to be a
concrete type.  Concrete w.r.t. to a generic parameter means something
different from Concrete w.r.t. subtyping.

> Relaxing these semantics would make it too easy to write code that
> traps at runtime "without the user having to reach" (to paraphrase
> Jordan from the "Swift philosophy" thread). Anyone who really really
> wants to write code that is 'compile-time unsound' in this way should
> have to explicitly type erase using concrete wrappers.

I'd really like to see the use-cases, to make sure that these restricted
existentials will be useful enough to be worth implementing.

>
>
> Best,
> Austin
>
> On Wed, Jun 8, 2016 at 2:37 PM, Austin Zheng  wrote:
>
>> We might be talking past each other. I think Matthew is talking about
>> using an existential outside the context of generic functions. For example,
>> something like this should be trap-proof (as long as 'x' is immutable,
>> which it is in this example):
>>
>> func copySequenceIntoArray(x: Any> Int>) -> [Int] {
>> var buffer : [Int] = []
>> // Stupid implementation to make a point
>> var iterator : x.Iterator = x.makeIterator()
>> while true {
>> let nextItem : Int? = iterator.next()
>> if let nextItem = nextItem {
>> buffer.append(nextItem)
>> } else {
>> return buffer
>> }
>> }
>> }
>>
>> Even this would never trap as well:
>>
>> func copySequenceIntoArray(x: Any> T>) -> [T] {
>> var buffer : [T] = []
>> for item in x {
>> buffer.append(item)
>> }
>> return buffer
>> }
>>
>> Where we run into difficulty is something like this (forgive my abuse of
>> the collections API; I don't remember all the new indexing APIs off the top
>> of my head):
>>
>> func doSomething(x: T, y: T) {
>> // Get indexes out of x and use them to index into y
>> var idx = x.startIndex
>> while (idx != x.endIndex || idx != y.endIndex) {
>> print(x[idx])
>> print(y[idx])
>> idx = x.nextIndex(idx)
>> }
>> }
>> let someSeq : Any = // ...
>> let anotherSeq : Any = // ...
>> // Trouble!
>> // someSeq and anotherSeq are the same existential type
>> // But the concrete index types within each of the existential variables
>> may be different
>> doSomething(someSeq, anotherSeq)
>>
>> It's this situation (using an existential type to fulfill a generic type
>> parameter constrained to the same requirements that comprise that
>> existential) that requires either of the two options that Dave presented,
>> due to our lack of compile-time type information about the fulfilling
>> type's associated types.
>>
>> Best,
>> Austin
>>
>> On Wed, Jun 8, 2016 at 2:33 PM, Matthew Johnson via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>>
>>>
>>> Sent from my iPad
>>>
>>> > On Jun 8, 2016, at 3:16 PM, Dave Abrahams via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> >
>>> >
>>> >> on Wed Jun 08 2016, Thorsten Seitz  wrote:
>>> >>
>>> >> Ah, thanks, I forgot!  I still consider this a bug, though (will have
>>> >> to read up again what the reasons are for that behavior).
>>> >
>>> > Yes, but in the case of the issue we're discussing, the choices are:
>>> >
>>> > 1. Omit from the existential's API any protocol requirements that depend
>>> >   on Self or associated types, in which case it *can't* conform to
>>> >   itself because it doesn't fulfill the requirements.
>>>
>>> They don't need to be omitted.  They are exposed in different ways
>>> depending on how the existential is constrained.  Austin's proposal was
>>> originally written to omit some members but it was modified based on
>>> feedback from Doug Gregor IIRC (Austin, is that right?).  Now it contains
>>> examples showing how these members are made available in a safe way.   Some
>>> members may still not be usable because you can't form an argument but IIRC
>>> the suggestion was that they be exposed anyway for consistency.
>>>
>>> >
>>> > 2. Erase type relationships and trap at runtime when they don't line up.
>>> >
>>> > Matthew has been arguing against #2, but you can't “fix the bug” without
>>> > it.
>>> >
>>> >>
>>> >> -Thorsten
>>> >>
>>> >>> Am 08.06.2016 um 21:43 schrieb Austin Zheng :
>>> >>>
>>> >>> It's not possible, even with Swift's current implementation of
>>> 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Dave Abrahams via swift-evolution]

on Wed Jun 08 2016, Austin Zheng  wrote:

> We might be talking past each other. I think Matthew is talking about using
> an existential outside the context of generic functions. For example,
> something like this should be trap-proof (as long as 'x' is immutable,
> which it is in this example):

[Ugh, Austin, your mail program is stripping the tabs out of the
plaintext part so the indendation is lost.  Grabbing from browser...]

> func copySequenceIntoArray(x: Any) 
> -> [Int] {
>   var buffer : [Int] = []
> // Stupid implementation to make a point
>   var iterator : x.Iterator = x.makeIterator()
>   while true {
>   let nextItem : Int? = iterator.next()
>   if let nextItem = nextItem {
>   buffer.append(nextItem)
>   } else {
>   return buffer
>   }
>   }
> }

Presumably this would “work” as well?

  typealias IntSequence = Any
  func f(x: IntSequence, y: IntSequence) {
var i = x.makeIterator()
i = y.makeIterator() // <== NO TRAP HERE, EVER.
  }

> Even this would never trap as well:
> 
> func copySequenceIntoArray(x: Any) 
> -> [T] {
>   var buffer : [T] = []
>   for item in x {
>   buffer.append(item)
>   }
>   return buffer
> }

Sure, this one is simple because the associated type is never even
exposed.

> Where we run into difficulty is something like this (forgive my abuse
> of the collections API; I don't remember all the new indexing APIs off
> the top of my head):
> 
> func doSomething(x: T, y: T) {
>   // Get indexes out of x and use them to index into y
>   var idx = x.startIndex
>   while (idx != x.endIndex || idx != y.endIndex) {
>   print(x[idx])
>   print(y[idx])
>   idx = x.nextIndex(idx)
>   }
> }
> let someSeq : Any = // ...
> let anotherSeq : Any = // ...
> // Trouble!
> // someSeq and anotherSeq are the same existential type
> // But the concrete index types within each of the existential variables may 
> be different
> doSomething(someSeq, anotherSeq)
> 
> may be different
> doSomething(someSeq, anotherSeq)
>
> It's this situation (using an existential type to fulfill a generic
> type parameter constrained to the same requirements that comprise that
> existential) that requires either of the two options that Dave
> presented, due to our lack of compile-time type information about the
> fulfilling type's associated types.

Exactly.  But much simpler cases will also either have to trap at
runtime or be prohibited outright:

  func subscript_(c: C, i: C.Index) -> C.Collection.Element {
return c[i]
  }

  typealias IntCollection = Any
  let c1: IntCollection = ...
  let c2: IntCollection = c1[3..<10]
  let c3: IntCollection = ...
  let c4: IntCollection = c1.reversed()

  // Note: the underlying index types are the same, and are supposed to
  // interoperate.  What do you do (work/trap/nocompile)?
  _ = subscript_(c1, c2.startIndex)

  // The underlying index types happen to be the same, and are not
  // supposed to interoperate.  What do you do (silently “work”/trap/nocompile)?
  _ = subscript_(c1, c3.startIndex)

  // The underlying index types are different.  What do you do (trap/nocompile)?
  _ = subscript_(c1, c4.startIndex)

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Matthew Johnson via swift-evolution]

> On Jun 8, 2016, at 4:47 PM, Austin Zheng  wrote:
> 
> FWIW my opinion is that existentials either shouldn't be allowed to stand in 
> for generic type parameters, or Dave's option #1 if they are.
> 
> The implied promise of a generic type parameter T right now is that T always 
> stands for the same concrete type (modulo things like passing in a subclass 
> where a class would do), and likewise for all of T's associated types (T.Foo 
> is always the same type everywhere in the context where T is valid). This is 
> what makes using anything with 'self' requirements in a generic context 
> sound. Allowing existentials to satisfy T would violate that constraint. 
> 
> Relaxing these semantics would make it too easy to write code that traps at 
> runtime "without the user having to reach" (to paraphrase Jordan from the 
> "Swift philosophy" thread). Anyone who really really wants to write code that 
> is 'compile-time unsound' in this way should have to explicitly type erase 
> using concrete wrappers.

Yes, exactly.

> 
> Best,
> Austin
> 
> 
> On Wed, Jun 8, 2016 at 2:37 PM, Austin Zheng  > wrote:
> We might be talking past each other. I think Matthew is talking about using 
> an existential outside the context of generic functions. For example, 
> something like this should be trap-proof (as long as 'x' is immutable, which 
> it is in this example):
> 
> func copySequenceIntoArray(x: Any) 
> -> [Int] {
>   var buffer : [Int] = []
> // Stupid implementation to make a point
>   var iterator : x.Iterator = x.makeIterator()
>   while true {
>   let nextItem : Int? = iterator.next()
>   if let nextItem = nextItem {
>   buffer.append(nextItem)
>   } else {
>   return buffer
>   }
>   }
> }
> 
> Even this would never trap as well:
> 
> func copySequenceIntoArray(x: Any) 
> -> [T] {
>   var buffer : [T] = []
>   for item in x {
>   buffer.append(item)
>   }
>   return buffer
> }
> 
> Where we run into difficulty is something like this (forgive my abuse of the 
> collections API; I don't remember all the new indexing APIs off the top of my 
> head):
> 
> func doSomething(x: T, y: T) {
>   // Get indexes out of x and use them to index into y
>   var idx = x.startIndex
>   while (idx != x.endIndex || idx != y.endIndex) {
>   print(x[idx])
>   print(y[idx])
>   idx = x.nextIndex(idx)
>   }
> }
> let someSeq : Any = // ...
> let anotherSeq : Any = // ...
> // Trouble!
> // someSeq and anotherSeq are the same existential type
> // But the concrete index types within each of the existential variables may 
> be different
> doSomething(someSeq, anotherSeq)
> 
> It's this situation (using an existential type to fulfill a generic type 
> parameter constrained to the same requirements that comprise that 
> existential) that requires either of the two options that Dave presented, due 
> to our lack of compile-time type information about the fulfilling type's 
> associated types.
> 
> Best,
> Austin
> 
> On Wed, Jun 8, 2016 at 2:33 PM, Matthew Johnson via swift-evolution 
> > wrote:
> 
> 
> Sent from my iPad
> 
> > On Jun 8, 2016, at 3:16 PM, Dave Abrahams via swift-evolution 
> > > wrote:
> >
> >
> >> on Wed Jun 08 2016, Thorsten Seitz  >> > wrote:
> >>
> >> Ah, thanks, I forgot!  I still consider this a bug, though (will have
> >> to read up again what the reasons are for that behavior).
> >
> > Yes, but in the case of the issue we're discussing, the choices are:
> >
> > 1. Omit from the existential's API any protocol requirements that depend
> >   on Self or associated types, in which case it *can't* conform to
> >   itself because it doesn't fulfill the requirements.
> 
> They don't need to be omitted.  They are exposed in different ways depending 
> on how the existential is constrained.  Austin's proposal was originally 
> written to omit some members but it was modified based on feedback from Doug 
> Gregor IIRC (Austin, is that right?).  Now it contains examples showing how 
> these members are made available in a safe way.   Some members may still not 
> be usable because you can't form an argument but IIRC the suggestion was that 
> they be exposed anyway for consistency.
> 
> >
> > 2. Erase type relationships and trap at runtime when they don't line up.
> >
> > Matthew has been arguing against #2, but you can't “fix the bug” without
> > it.
> >
> >>
> >> -Thorsten
> >>
> >>> Am 08.06.2016 um 21:43 schrieb Austin Zheng  >>> >:
> >>>
> >>> It's not possible, even with Swift's current implementation of
> >>> 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Matthew Johnson via swift-evolution]

> On Jun 8, 2016, at 1:33 PM, Dave Abrahams  wrote:
> 
> 
> on Tue Jun 07 2016, Matthew Johnson  wrote:
> 
>>> On Jun 7, 2016, at 9:15 PM, Dave Abrahams  wrote:
>>> 
>>> 
>>> on Tue Jun 07 2016, Matthew Johnson >> > wrote:
>>> 
>> 
> On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Tue Jun 07 2016, Matthew Johnson  wrote:
> 
 
>>> , but haven't realized
>>> that if you step around the type relationships encoded in Self
>>> requirements and associated types you end up with types that appear to
>>> interoperate but in fact trap at runtime unless used in exactly the
>>> right way.
>> 
>> Trap at runtime?  How so?  Generalized existentials should still be
>> type-safe.  
> 
> There are two choices when you erase static type relationships:
> 
> 1. Acheive type-safety by trapping at runtime
> 
> FloatingPoint(3.0 as Float) + FloatingPoint(3.0 as Double) // trap
> 
> 2. Don't expose protocol requirements that involve these relationships,
> which would prevent the code above from compiling and prevent
> FloatingPoint from conforming to itself.
> 
>> Or are you talking about the hypothetical types / behaviors people
>> think they want when they don’t fully understand what is happening...
> 
> I don't know what you mean here.  I think generalized existentials will
> be nice to have, but I think most people will want them to do something
> they can't possibly do.
 
 Exactly.  What I meant is that people think they want that expression
 to compile because they don’t understand that the only thing it can do
 is trap.  I said “hypothetical” because producing a compile time error
 rather than a runtime trap is the only sane thing to do.  Your comment
 surprised me because I can’t imagine we would move forward in Swift
 with the approach of trapping.
>>> 
>>> I would very much like to be able to create instances of “Collection
>>> where Element == Int” so we can throw away the wrappers in the stdlib.
>>> That will require some type mismatches to be caught at runtime via
>>> trapping.
>> 
>> For invalid index because the existential accepts a type erased index?
> 
> Exactly.
> 
>> How do you decide where to draw the line here?  It feels like a very
>> slippery slope for a language where safety is a stated priority to
>> start adopting a strategy of runtime trapping for something as
>> fundamental as how you expose members on an existential.
> 
> If you don't do this, the alternative is that “Collection where Element
> == Int” does not conform to Collection.  

This isn’t directly related to having self or associated type requirements.  It 
is true of all existentials.  If that changes for simple existentials and 
generalized existentials expose all members (as in the latest draft of the 
proposal) maybe it will be possible for all existentials to conform to their 
protocol.  

> That's weird and not very
> useful.  You could expose all the methods that were on protocol
> extensions of Collection on this existential, unless they used
> associated types other than the element type.  But you couldn't pass the
> existential to a generic function like
> 
>   func scrambled(_ c: C) -> [C.Element]
> 
>> IMO you should *have* to introduce unsafe behavior like that manually.
> 
>  Collection where Element == Int & Index == *
> 
> ?

I didn’t mean directly through the type of the existential.

One obvious mechanism for introducing unsafe behavior is to write manual type 
erasure wrappers like we do today.  

Another possibility would be to allow extending the existential type (not the 
protocol).  This would allow you to write overloads on the Collection 
existential that takes some kind of type erased index if that is what you want 
and either trap if you receive an invalid index or better (IMO) return an 
`Element?`.  I’m not sure how extensions on existentials might be implemented, 
but this is an example of the kind of operation you might want available on it 
that you wouldn’t want available on all Collection types.

> 
>> Collection indices are already something that isn’t fully statically
>> safe so I understand why you might want to allow this.  
> 
> By the same measure, so are Ints :-)
> 
> The fact that a type's methods have preconditions does *not* make it
> “statically unsafe.”

That depends on what you mean by safe.  Sure, those methods aren’t going 
corrupt memory, but they *are* going to explicitly and intentionally crash for 
some inputs.  That doesn’t qualify as “fully safe” IMO.

> 
>> But I don’t think having the language's existentials do this
>> automatically is the right approach.  Maybe there is another approach
>> that could be used in targeted use cases where the less safe behavior
>> 

Re: [swift-evolution] extend trailing closure rule

[Matt Neuburg via swift-evolution]

Well, I guess I didn't pick a strong enough case. Try this one:

UIView.animate(withDuration:0.4, delay: 0, options: [.autoreverse]) {
self.view.backgroundColor = UIColor.red()
}

That doesn't compile. I'm suggesting that it would be cool if it did. m.

> On Jun 8, 2016, at 12:29 PM, Rimantas Liubertas  wrote:
> 
>> 
>> That's ugly. I'd rather write:
>> 
>> UIView.animate(withDuration:0.4) {
>> self.v.backgroundColor = UIColor.red()
>> }
>> 
>> What stops me is that `animations:` is not eligible for trailing closure 
>> syntax, because it isn't the last parameter — `completion:` is.
> 
> Actually you can. UIView has three signatures ‘animateWithduration’:
> 
> class func animateWithDuration(_ duration: NSTimeInterval,
> animations animations: () -> Void)
> 
> class func animateWithDuration(_ duration: NSTimeInterval,
> animations animations: () -> Void,
> completion completion: ((Bool) -> Void)?)
> 
> class func animateWithDuration(_ duration: NSTimeInterval,
>  delay delay: NSTimeInterval,
>options options: UIViewAnimationOptions,
> animations animations: () -> Void,
> completion completion: ((Bool) -> Void)?)
> 
> so your version is valid.
> 
> 
> Best regards,
> Rimantas

--
matt neuburg, phd = http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 9! http://shop.oreilly.com/product/0636920044352.do
iOS 9 Fundamentals! http://shop.oreilly.com/product/0636920044345.do
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html

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

Re: [swift-evolution] Proposal: Filter split extension on Sequence to return tuple of sequences that meet criteria and that do not

[gadiraju praneeth via swift-evolution]

I implemented something similar with two filters initially, but because of
2N vs N I changed it

On Wednesday, June 8, 2016, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Wed Jun 08 2016, Nate Cook  wrote:
>
> >> On Jun 8, 2016, at 3:40 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org > wrote:
> >>
> >>
> >> on Wed Jun 08 2016, Dave Abrahams  > wrote:
> >>
> >
> >>> on Wed Jun 08 2016, gadiraju praneeth  > wrote:
> >>>
>  Many times, I came across a scenario where I had to filter an array
> with a
>  condition and filter the same array with opposite of that condition.
> For
>  example:
> 
>  let values = [2, 4, 3, 5, 6, 9]
> 
>  let divisibleByTwo = values.filter { $0 % 2 == 0 }
>  let notDivisibleByTwo = values.filter { $0 % 2 != 0 }
> 
>  Is there a way currently where we can filter the array into two arrays
>  based on a condition?
> >>>
> >>> Well, you need a stable partition for this if you care about ordering
> >>> (see
> >>>
> https://github.com/apple/swift/blob/master/test/Prototypes/Algorithms.swift#L299
> )
> >>> but then you can do
> >>>
> >>> var parts = values
> >>> let mid = values.stablePartition { $0 % 2 == 0 }
> >>> let divisibleByTwo = parts.prefix(upTo: mid)
> >>> let notDivisibleByTwo = parts.suffix(from: mid)
> >>>
> >>> Nate Cook has an enhancement to the result of stablyPartitioned in that
> >>> prototype that would let you write:
> >>>
> >>>  let parts = values.stablyPartitioned { $0 % 2 == 0 }
> >>>  let divisibleByTwo = parts.prefix(upTo: parts.partitionPoint)
> >>>  let notDivisibleByTwo = parts.suffix(from: parts.partitionPoint)
> >
> > Mine was for the result of the 'rotated' methods, but should work for
> > the partitioning ones, too. It's not as clear to me what the benefit
> > of the "lazy" partitioning in that Algorithm.swift is
>
> Just to pass “laziness” on from the result, so further computations can
> also be lazy.
>
> > —wouldn't it be better to wrap a collection around two lazy filter
> > sequences?
>
> Perhaps something like a
> LazyFlatMap would be better, but
> I have the concern that this would evaluate the predicate 2N times for
> each traversal.
>
> > Here is a quick proof of concept of 'divided' and 'partitioned'
> > methods:
> > http://swiftlang.ng.bluemix.net/#/repl/57588cbda79b317716f02e04
> >
> >> Hmm, come to think of it, Nate, maybe there should also be a more
> >> convenient way to get the two partitions from the result.
> >
> > Definitely!
> >
> > Nate
> >
> >> --
> >> Dave
> >>
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org 
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> --
> Dave
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Add a while clause to for loops

[Sean Heber via swift-evolution]

There might be value in entertaining the idea of unifying constructs such that 
they all allow arbitrary combinations of for/while/where/etc.

Such as:

while !stopped for unit in workToDo where unit.passesTest(condition) { 
unit.process() }

Which would mean something different than:

for unit in workToDo while !stopped where unit.passesTest(condition) { 
unit.process() }

And yes, they are very similar visually but differ subtly in meaning, but the 
same can be said about different sentences in english that might all share the 
same words and differ only by their order. It’s not exactly a foreign concept! 
I don’t know of any languages that are quite so expressive as that might be. 
Are there advantages to something more outlandish like this? I don’t know. I’m 
not proposing it directly, just thinking out loud, I guess.

l8r
Sean


> On Jun 8, 2016, at 4:44 PM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 8 Jun 2016, at 17:11, Xiaodi Wu  wrote:
>>> On Wed, Jun 8, 2016 at 3:38 AM, Haravikk  
>>> wrote:
>>> Yes this could be handled by an if/guard statement with continue, and while 
>>> as proposed here could be done with the same plus a break, but these things 
>>> come up so often that it just makes a lot of sense to get it all neatly 
>>> onto one line.
>> 
>> As I pointed out above with Tim's example, putting it all on one line is 
>> absolutely not 'neat'--it reads like spaghetti. That is one major beef I 
>> have with this proposal: that it *encourages* writing on one line too many 
>> things that, whether you use `where` or not, are much more clearly written 
>> on multiple lines. If writing everything on one line is for you the major 
>> advantage of this proposal, we could agree on everything else and I would be 
>> very much opposed to this proposal on that basis alone.
> 
> I’m not proposing that every single loop have all of its conditions crushed 
> onto one line, just like I wasn’t when discussing where on the condition 
> clause thread. The usefulness of where and the proposed while is in the 
> common, simple cases, for example:
> 
>   for eachValue in theValues while eachValue < 100 where eachValue % 2 == 
> 0 { … }
> 
> The alternatives would be:
> 
>   for eachValue in theValues {
>   guard eachValue < 100 else { break }
>   guard eachValue % 2 == 0 else { continue }
>   …
>   }
>   for eachValue in theValues.prefix(while: { $0 < 100 }).filter({ $0 % 2 
> == 0 }) { … } // Could also be on multiple lines
> 
> The former wastes vertical space for what it does IMO; it’s fine if the 
> conditions were more complicated, but since they’re not where/while is ideal. 
> The second isn’t terrible, but it’s a pretty noisy way to handle common loop 
> conditions.
> 
> The use of where/while isn’t about eliminating either of these alternatives, 
> they’re absolutely useful in cases where their drawbacks become advantages. 
> For example the inline guards are great when the conditions are more complex, 
> and necessary if you want to do more than the simple cases allow. The second 
> form is best when you need more than the two methods, alternate methods, or 
> you have predicates you can pass in directly, although personally when I do 
> this I tend to do the chinning on its own lines outside of the loop, leaving 
> me with a loop of: for eachValue in theFilteredValues { … } or whatever.
> 
>> Closures are--I'm sure you'd agree--a far more advanced concept than loops. 
>> Concepts like closing over a variable are very, very hard. Many useful 
>> things can be written without using closures. Not so many things could do 
>> without loops. It very much matters that a learner might feel that he or she 
>> cannot understand everything about a loop with the handwavy explanation that 
>> it'll "come later”.
> 
> Not my point at all; my point was about the shorthand for closures not 
> closure as a whole, you can’t learn the closure shorthands without first 
> learning what a closure is. In exactly the same way where/while are just be 
> shorthands for inline if/guard, you don’t need to learn about these clauses 
> to make a functioning loop if you know how to do it with your if/guard 
> statements. In fact it’s better to learn it in this order as once you know 
> what each clause is a shorthand form of (if/guard continue or break) then you 
> know exactly what it does already.
> 
> 
> Ignoring for a moment that you’re opposed to the where clause in general, 
> what would your thoughts be on only permitting one of where/while in a for? 
> i.e- you would be able to do only one of:
> 
>   for eachValue in theValues where eachValue % 2 == 0 { … }
>   for eachValue in theValues while eachValue < 100 { … }
> 
> But not have both a where and a while on the same line. This eliminates the 
> question mark around the order they are applied in, while still giving us the 
> 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Dave Abrahams via swift-evolution]

on Wed Jun 08 2016, Jordan Rose  wrote:

>> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Wed Jun 08 2016, Thorsten Seitz > > wrote:
>> 
>
>>> Ah, thanks, I forgot!  I still consider this a bug, though (will have
>>> to read up again what the reasons are for that behavior).
>> 
>> Yes, but in the case of the issue we're discussing, the choices are:
>> 
>> 1. Omit from the existential's API any protocol requirements that depend
>>   on Self or associated types, in which case it *can't* conform to
>>   itself because it doesn't fulfill the requirements.
>> 
>> 2. Erase type relationships and trap at runtime when they don't line up.
>> 
>> Matthew has been arguing against #2, but you can't “fix the bug” without
>> it.
>
> #1 has been my preference for a while as well, at least as a starting
> point. 

But as I've been suggesting, #1 may not worth generalizing existentials
for, especially considering that Doug says by a factor of 10x people who
want parameterized protocols are asking for things like Collection.

> It's possible we could also "open" the existential when it's only used
> by one parameter, i.e. the first would be legal and the second
> wouldn't:
>
> func foo(x: X) { … }
> func test(x: Any) {
>   foo(x) // okay, passes the dynamic type
> }
>
> func bar(a: X, b: X) { … }
> func test(x: Any, y: Any) {
>   bar(x, y) // illegal because x.dynamicType may be different from 
> y.dynamicType
> }
>
> (The check is not as simple as "the generic parameter is only
> mentioned once", because of constraints and such. But you get the
> idea.)

Interesting from a “completing the type system” perspective but perhaps
not very useful.  What are the use cases for this?  What you can do
with Hashable is intimately dependent on the type relationship.

We should really stop using protocols refining Equatable as an exemplar,
because that's a special case that has a special answer when the types
don't match up**. It's not representative of the general case, though.

** and any generalized Existential system we implement ought to support
   that answer!

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

Re: [swift-evolution] Remove nil and NilLiteralConvertible

[Pyry Jahkola via swift-evolution]

I don't see a reason to rename or remove the `nil` literal.

But I can come up with a concrete reason to deprecate NilLiteralConvertible: 
The language has made Optional a very specific thing with `if let` syntax, 
implicit wrapping, and optional chaining to name a few. But the second most 
common way (I guess) to create an Optional—by using the `nil` literal—isn't 
actually guaranteed to create an Optional.

let condition: Bool
let x = condition ? 1 : nil
// error: result values in '? :' expression have mismatching types 'Int' 
and '_'

An expression like the above doesn't compile because the compiler can't tell 
what type `nil` should initialise. (Currently, at least Optional and 
ImplicitlyUnwrappedOptional seem possible, but with NilLiteralConvertible, 
something like a conforming MyJSON could be as well!) This, I think, can be 
confusing to new users. And life would be simpler if `nil` always stood for 
`Optional.none`, which would then infer the associated Wrapped type 
respectfully.

So no, I don't support this idea but I think we should sunset 
NilLiteralConvertible.

— Pyry

PS. Besides, the above statement will compile with any of the following edits:

let x = condition ? 1 : Optional.none
let x = condition ? 1 : nil as Optional
let x = condition ? 1 : Optional()
let x = condition ? 1 as Optional : nil
let x = condition ? 1 as Int? : nil
let x = condition ? Optional(1) : nil
let x: Int? = condition ? 1 : nil

> On 08 Jun 2016, at 23:41, Антон Жилин via swift-evolution 
>  wrote:
> 
> (No joking)
> Points:
> 
> 1. When nil was added to the language, we could not infer enumeration type:
> if x != Optional.none { ... }
> 
> Now it looks like this:
> if x != .none { ... }
> 
> If at this point we had a proposal to add nil as a replacement for .none, 
> would we accept it?
> 
> 2. nil is very generic, it only approximately allows to express the 
> intentions.
> In case of Optional, .none is clearer. In case of JSON processing, .null is 
> clearer. In case of a semantically nullable struct, NilLiteralConvertible 
> usually goes to default constructor.
> 
> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
> 
> 4. There should be a single consistent terminology: no value in Swift equals 
> none.
> 
> - Anton
> ___
> 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-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Austin Zheng via swift-evolution]

FWIW my opinion is that existentials either shouldn't be allowed to stand
in for generic type parameters, or Dave's option #1 if they are.

The implied promise of a generic type parameter T right now is that T
always stands for the same concrete type (modulo things like passing in a
subclass where a class would do), and likewise for all of T's associated
types (T.Foo is always the same type everywhere in the context where T is
valid). This is what makes using anything with 'self' requirements in a
generic context sound. Allowing existentials to satisfy T would violate
that constraint.

Relaxing these semantics would make it too easy to write code that traps at
runtime "without the user having to reach" (to paraphrase Jordan from the
"Swift philosophy" thread). Anyone who really really wants to write code
that is 'compile-time unsound' in this way should have to explicitly type
erase using concrete wrappers.

Best,
Austin


On Wed, Jun 8, 2016 at 2:37 PM, Austin Zheng  wrote:

> We might be talking past each other. I think Matthew is talking about
> using an existential outside the context of generic functions. For example,
> something like this should be trap-proof (as long as 'x' is immutable,
> which it is in this example):
>
> func copySequenceIntoArray(x: Any Int>) -> [Int] {
> var buffer : [Int] = []
> // Stupid implementation to make a point
> var iterator : x.Iterator = x.makeIterator()
> while true {
> let nextItem : Int? = iterator.next()
> if let nextItem = nextItem {
> buffer.append(nextItem)
> } else {
> return buffer
> }
> }
> }
>
> Even this would never trap as well:
>
> func copySequenceIntoArray(x: Any T>) -> [T] {
> var buffer : [T] = []
> for item in x {
> buffer.append(item)
> }
> return buffer
> }
>
> Where we run into difficulty is something like this (forgive my abuse of
> the collections API; I don't remember all the new indexing APIs off the top
> of my head):
>
> func doSomething(x: T, y: T) {
> // Get indexes out of x and use them to index into y
> var idx = x.startIndex
> while (idx != x.endIndex || idx != y.endIndex) {
> print(x[idx])
> print(y[idx])
> idx = x.nextIndex(idx)
> }
> }
> let someSeq : Any = // ...
> let anotherSeq : Any = // ...
> // Trouble!
> // someSeq and anotherSeq are the same existential type
> // But the concrete index types within each of the existential variables
> may be different
> doSomething(someSeq, anotherSeq)
>
> It's this situation (using an existential type to fulfill a generic type
> parameter constrained to the same requirements that comprise that
> existential) that requires either of the two options that Dave presented,
> due to our lack of compile-time type information about the fulfilling
> type's associated types.
>
> Best,
> Austin
>
> On Wed, Jun 8, 2016 at 2:33 PM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> Sent from my iPad
>>
>> > On Jun 8, 2016, at 3:16 PM, Dave Abrahams via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >
>> >> on Wed Jun 08 2016, Thorsten Seitz  wrote:
>> >>
>> >> Ah, thanks, I forgot!  I still consider this a bug, though (will have
>> >> to read up again what the reasons are for that behavior).
>> >
>> > Yes, but in the case of the issue we're discussing, the choices are:
>> >
>> > 1. Omit from the existential's API any protocol requirements that depend
>> >   on Self or associated types, in which case it *can't* conform to
>> >   itself because it doesn't fulfill the requirements.
>>
>> They don't need to be omitted.  They are exposed in different ways
>> depending on how the existential is constrained.  Austin's proposal was
>> originally written to omit some members but it was modified based on
>> feedback from Doug Gregor IIRC (Austin, is that right?).  Now it contains
>> examples showing how these members are made available in a safe way.   Some
>> members may still not be usable because you can't form an argument but IIRC
>> the suggestion was that they be exposed anyway for consistency.
>>
>> >
>> > 2. Erase type relationships and trap at runtime when they don't line up.
>> >
>> > Matthew has been arguing against #2, but you can't “fix the bug” without
>> > it.
>> >
>> >>
>> >> -Thorsten
>> >>
>> >>> Am 08.06.2016 um 21:43 schrieb Austin Zheng :
>> >>>
>> >>> It's not possible, even with Swift's current implementation of
>> >>> existentials. A protocol type P isn't considered to conform to
>> >>> itself, thus the following is rejected:
>> >>>
>> >>> let a : MyProtocol = // ...
>> >>> func myFunc(x: T) {
>> >>>  // 
>> >>> }
>> >>> myFunc(a) // "Cannot invoke 'myFunc' with an argument list of type
>> MyProtocol"
>> >>>
>> >>> Changing how this works is probably worth a proposal by itself.
>> >>>
>> >>> Austin
>> >>>
>> >>>
>> >>> On Wed, Jun 8, 2016 at 12:34 PM, Thorsten Seitz via swift-evolution
>> >>> > >>> 

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha via swift-evolution]

+1 I agree. Unwrapping in the functional signature is confusing for the
user; many don’t realize that it puts the burden of checking on them.
Non-optional function parameters make this explicit by preventing passing
in Optional types, forcing the user to check, which they should be doing
anyway.

On Wed, Jun 8, 2016 at 12:22 PM J. Charles M. N. via swift-evolution <
swift-evolution@swift.org> wrote:

>
> This confused me at the beginning.
>
> But doesn't Int! In parameter type means the function is awaiting an
> unwrapped value so the user should ensure that it data parameter is
> available, valid, and unwrapped?
>
> --
> J. Charles
>
> > Le 8 juin 2016 à 13:30, Spromicky via swift-evolution <
> swift-evolution@swift.org> a écrit :
> >
> > Hello, everyone!
> >
> > I wanna propose to you to remove force unwrapping in fuction signature
> for swift code. That no sense in clear swift code. If we wanna use some
> optional value as function param, that is not optional, we must unwrap it
> before function call.
> > People who new in swift look at how they old Obj-C code (without
> nullability modifiers) translate in to swift:
> >
> > Obj-C:
> > - (void)foo:(NSInteger)bar {
> >//...
> > }
> >
> > Swift transaliton:
> > func foo(bar: Int!) {
> >//...
> > }
> >
> > And think that force unwrapping in signature is good practice. And start
> write functions in clear swift code like this:
> >
> > func newFoo(bar: Int!) {
> >//...
> > }
> >
> > and use it like this:
> >
> > let bar: Int? = 1
> > newFoo(bar)
> >
> > And it really work, and they does not think that this can crash in case
> if `bar` will be `nil`.
> > But in clear swift we wanna work with parametrs in function that clearly
> or optional, or not.
> >
> > func newFoo(bar: Int) {
> >//...
> > }
> >
> > or
> >
> > func newFoo(bar: Int?) {
> >//...
> > }
> >
> > When we write a new function we know what we need in this case and use
> optional params or not.
> >
> > So my proposal is remove force unwrapping(`!`) from function signatures,
> cause it have no sense, and that confuse new users.
> > ___
> > 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
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Filter split extension on Sequence to return tuple of sequences that meet criteria and that do not

[Dave Abrahams via swift-evolution]

on Wed Jun 08 2016, Nate Cook  wrote:

>> On Jun 8, 2016, at 3:40 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Wed Jun 08 2016, Dave Abrahams  wrote:
>> 
>
>>> on Wed Jun 08 2016, gadiraju praneeth  wrote:
>>> 
 Many times, I came across a scenario where I had to filter an array with a
 condition and filter the same array with opposite of that condition. For
 example:
 
 let values = [2, 4, 3, 5, 6, 9]
 
 let divisibleByTwo = values.filter { $0 % 2 == 0 }
 let notDivisibleByTwo = values.filter { $0 % 2 != 0 }
 
 Is there a way currently where we can filter the array into two arrays
 based on a condition?
>>> 
>>> Well, you need a stable partition for this if you care about ordering
>>> (see
>>> https://github.com/apple/swift/blob/master/test/Prototypes/Algorithms.swift#L299)
>>> but then you can do 
>>> 
>>> var parts = values
>>> let mid = values.stablePartition { $0 % 2 == 0 }
>>> let divisibleByTwo = parts.prefix(upTo: mid)
>>> let notDivisibleByTwo = parts.suffix(from: mid)
>>> 
>>> Nate Cook has an enhancement to the result of stablyPartitioned in that
>>> prototype that would let you write:
>>> 
>>>  let parts = values.stablyPartitioned { $0 % 2 == 0 }
>>>  let divisibleByTwo = parts.prefix(upTo: parts.partitionPoint)
>>>  let notDivisibleByTwo = parts.suffix(from: parts.partitionPoint)
>
> Mine was for the result of the 'rotated' methods, but should work for
> the partitioning ones, too. It's not as clear to me what the benefit
> of the "lazy" partitioning in that Algorithm.swift is

Just to pass “laziness” on from the result, so further computations can
also be lazy.

> —wouldn't it be better to wrap a collection around two lazy filter
> sequences?

Perhaps something like a
LazyFlatMap would be better, but
I have the concern that this would evaluate the predicate 2N times for
each traversal.

> Here is a quick proof of concept of 'divided' and 'partitioned'
> methods:
> http://swiftlang.ng.bluemix.net/#/repl/57588cbda79b317716f02e04
>
>> Hmm, come to think of it, Nate, maybe there should also be a more
>> convenient way to get the two partitions from the result.
>
> Definitely!
>
> Nate
>
>> -- 
>> Dave
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Sketch: Teach init a 'defer'-like ability to deinit

[Erica Sadun via swift-evolution]

I really like this idea. Spatially moving cleanup next to unsafe operations is 
good practice.

In normal code, I want my cleanup to follow as closely as possible to my unsafe 
act:

let buffer: UnsafeMutablePointer = 
UnsafeMutablePointer(allocatingCapacity: chunkSize)
defer { buffer.deallocateCapacity(chunkSize) }

(Sorry for the horrible example, but it's the best I could grep up with on a 
moment's notice)

I like your idea but what I want to see is not the deinit child closure in init 
you propose but a new keyword that means defer-on-deinit-cleanup

self.ptr = UnsafeMutablePointer(allocatingCapacity: count)
deferringDeInit { self.ptr.deallocateCapacity(count) }

Or something.

-- E
p.s. Normally I put them on the same line with a semicolon but dang these 
things can be long

> On Jun 8, 2016, at 10:54 AM, Graham Perks via swift-evolution 
>  wrote:
> 
> Teach init a 'defer'-like ability to deinit
> 
> 'defer' is a great way to ensure some clean up code is run; it's declaritive 
> locality to the resource acquisition is a boon to clarity.
> 
> Swift offers no support for resources acquired during 'init'.
> 
> For an example, from 
> https://www.mikeash.com/pyblog/friday-qa-2015-04-17-lets-build-swiftarray.html
>  
> 
> 
> init(count: Int = 0, ptr: UnsafeMutablePointer = nil) {
> self.count = count
> self.space = count
> 
> self.ptr = UnsafeMutablePointer.alloc(count)
> self.ptr.initializeFrom(ptr, count: count)
> }
> 
> deinit {
> ptr.destroy(...)
> ptr.dealloc(...)
> }
> 
> Another 'resource' might be adding an NSNotificationCenter observer, and 
> wanting to unobserve in deinit (no need in OS X 10.11, iOS 9, but for earlier 
> releases this is a valid example).
> 
> Changing the above code to use a 'defer' style deinit block might look like:
> 
> init(count: Int = 0, ptr: UnsafeMutablePointer = nil) {
> self.count = count
> self.space = count
> 
> self.ptr = UnsafeMutablePointer.alloc(count)
> self.ptr.initializeFrom(ptr, count: count)
> 
> deinit {
> ptr.destroy(...)
> ptr.dealloc(...)
> }
> 
> // NSNotificationCenter example too
> NSNotificationCenter.defaultCenter().addObserver(...)
> deinit { 
> NSNotificationCenter.defaultCenter().removeObserver(...)
> }
> }
> 
> The need to provide a separate implemention of deinit is gone. Reasoning for 
> 'defer' applies here. There is good locality between what was initialized and 
> what needs cleaning up.
> 
> Considerations:
> 1. Should deinit blocks be invoked before or after code in an explicit deinit 
> method?
> 2. Should deinit blocks be allowed in other methods; e.g. viewDidLoad()?
> 3. How should deinit blocks be prevented from strongly capturing self (thus 
> preventing themselves from ever running!)?


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

Re: [swift-evolution] [Draft] Allow multiple conformances to the same protocol

[Austin Zheng via swift-evolution]

FWIW they're marked as 'unlikely' here:
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-protocols

It would probably be useful to have counterarguments against the points
raised in that document if you want to prepare a proposal.

Austin

On Wed, Jun 8, 2016 at 2:32 PM, Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

> Associated types aren't generic parameters; the whole point is that
> they're requirements, just like the other declarations in a protocol.
>
> You might be trying to invent generic protocols instead, which (IIRC)
> aren't inherently a bad thing. But I think this needs a lot more fleshing
> out before it can really be discussed—it's hard to know how you can and
> can't use these things, and how they might be implemented.
>
> Best,
> Jordan
>
>
> > On Jun 8, 2016, at 12:07, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > ==Motivation==
> >
> > protocol From {
> > associatedtype FromType
> > init(_ value: FromType)
> > }
> >
> > The problem is, one type cannot implement multiple From "conversions".
> >
> > ==Proposed solution==
> >
> > Allow specifying all associated types using generic syntax.
> >
> > extension Int : From { }
> > extension Int : From { }
> >
> > This is only allowed in conformance declarations.
> >
> > ==Future directions==
> >
> > We can replace all *Convertible protocols with From and Into, which will
> be defined similarly to Rust.
> >
> > - Anton
> > ___
> > 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] Remove nil and NilLiteralConvertible

[Sean Heber via swift-evolution]

When isn’t it?

l8r
Sean


> On Jun 8, 2016, at 4:22 PM, Brandon Knope  wrote:
> 
> Yes it is the same keyword, but is it the same behavior from other languages?
> 
> Brandon
> 
>> On Jun 8, 2016, at 5:20 PM, Saagar Jha  wrote:
>> 
>> I think we also need to consider newbies coming from other languages. “nil” 
>> being a holdover makes it easier to understand what it means, having a 
>> “.none”/“none” duality makes it both seem inconsistent as well as dredge up 
>> language implementation details-now you have to explain that Optionals are 
>> actually enums internally. Using nil doesn’t lead to this kind of scenario, 
>> and they already (mostly) know what it means from other languages.
>> 
>> On Wed, Jun 8, 2016 at 2:13 PM Sean Heber via swift-evolution 
>>  wrote:
>> If there’s both “.none” and “none”, then I think that’d be more confusing 
>> *because of* the naming consistency, IMO. I’d look at that as a newbie and 
>> wonder why in the world this word sometimes has a dot and sometimes doesn’t.
>> 
>> If enum cases could be referred to without the leading “.” then perhaps I 
>> could get behind this because “none” wouldn’t even need to be a keyword at 
>> all in that case, but there are probably difficult ambiguities down that 
>> road.
>> 
>> l8r
>> Sean
>> 
>> 
>> > On Jun 8, 2016, at 4:04 PM, Brandon Knope  wrote:
>> >
>> > 1. People will find .none ugly which is why I think it could be replaced 
>> > by a none keyword. It is awkward
>> > 2. none is more descriptive than nil in this case. The case is named none 
>> > (consistency!) and nil is a holdover from other languages
>> >
>> > I understand how nil works in the context of other languages. But looking 
>> > at Optional:
>> > public enum Optional : NilLiteralConvertible {
>> >
>> > /// The absence of a value.
>> > ///
>> > /// In code, the absence of a value is typically written using the 
>> > `nil`
>> > /// literal rather than the explicit `.none` enumeration case.
>> > case none
>> >
>> > /// The presence of a value, stored as `Wrapped`.
>> > case some(Wrapped)
>> > }
>> >
>> >
>> > These are not pointers and they sure look like one when you assign nil to 
>> > an optional
>> >
>> > B
>> >
>> > Why would nil be chosen to represent the none case in the absence of other 
>> > languages?
>> >
>> >
>> >> On Jun 8, 2016, at 4:55 PM, Sean Heber  wrote:
>> >>
>> >> If you add a new keyword called “none” without the period, but keep 
>> >> allowing “.none” to work because Optional is really an enum… then I don’t 
>> >> really see what has been gained here at all - you’re basically back to 
>> >> nil/.none => 2 ways to say the same thing!
>> >>
>> >> l8r
>> >> Sean
>> >>
>> >>
>> >>> On Jun 8, 2016, at 3:52 PM, Brandon Knope via swift-evolution 
>> >>>  wrote:
>> >>>
>> >>> .none or a more appropriate keyword like “none” (imo)
>> >>>
>> >>> Brandon
>> >>>
>>  On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution 
>>   wrote:
>> 
>>  It's been pointed out before that Optional being an enum type is 
>>  treated like an implementation detail. Currently, it is possible to 
>>  teach the concept of Optional without introducing enum types or 
>>  generics. How would you do so after elimination of nil?
>> 
>> 
>>  On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин  
>>  wrote:
>>  (No joking)
>>  Points:
>> 
>>  1. When nil was added to the language, we could not infer enumeration 
>>  type:
>>  if x != Optional.none { ... }
>> 
>>  Now it looks like this:
>>  if x != .none { ... }
>> 
>>  If at this point we had a proposal to add nil as a replacement for 
>>  .none, would we accept it?
>> 
>>  2. nil is very generic, it only approximately allows to express the 
>>  intentions.
>>  In case of Optional, .none is clearer. In case of JSON processing, 
>>  .null is clearer. In case of a semantically nullable struct, 
>>  NilLiteralConvertible usually goes to default constructor.
>> 
>>  3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
>> 
>>  4. There should be a single consistent terminology: no value in Swift 
>>  equals none.
>> 
>>  - Anton
>> 
>>  ___
>>  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] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Austin Zheng via swift-evolution]

We might be talking past each other. I think Matthew is talking about using
an existential outside the context of generic functions. For example,
something like this should be trap-proof (as long as 'x' is immutable,
which it is in this example):

func copySequenceIntoArray(x: Any)
-> [Int] {
var buffer : [Int] = []
// Stupid implementation to make a point
var iterator : x.Iterator = x.makeIterator()
while true {
let nextItem : Int? = iterator.next()
if let nextItem = nextItem {
buffer.append(nextItem)
} else {
return buffer
}
}
}

Even this would never trap as well:

func copySequenceIntoArray(x: Any) -> [T] {
var buffer : [T] = []
for item in x {
buffer.append(item)
}
return buffer
}

Where we run into difficulty is something like this (forgive my abuse of
the collections API; I don't remember all the new indexing APIs off the top
of my head):

func doSomething(x: T, y: T) {
// Get indexes out of x and use them to index into y
var idx = x.startIndex
while (idx != x.endIndex || idx != y.endIndex) {
print(x[idx])
print(y[idx])
idx = x.nextIndex(idx)
}
}
let someSeq : Any = // ...
let anotherSeq : Any = // ...
// Trouble!
// someSeq and anotherSeq are the same existential type
// But the concrete index types within each of the existential variables
may be different
doSomething(someSeq, anotherSeq)

It's this situation (using an existential type to fulfill a generic type
parameter constrained to the same requirements that comprise that
existential) that requires either of the two options that Dave presented,
due to our lack of compile-time type information about the fulfilling
type's associated types.

Best,
Austin

On Wed, Jun 8, 2016 at 2:33 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Sent from my iPad
>
> > On Jun 8, 2016, at 3:16 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >> on Wed Jun 08 2016, Thorsten Seitz  wrote:
> >>
> >> Ah, thanks, I forgot!  I still consider this a bug, though (will have
> >> to read up again what the reasons are for that behavior).
> >
> > Yes, but in the case of the issue we're discussing, the choices are:
> >
> > 1. Omit from the existential's API any protocol requirements that depend
> >   on Self or associated types, in which case it *can't* conform to
> >   itself because it doesn't fulfill the requirements.
>
> They don't need to be omitted.  They are exposed in different ways
> depending on how the existential is constrained.  Austin's proposal was
> originally written to omit some members but it was modified based on
> feedback from Doug Gregor IIRC (Austin, is that right?).  Now it contains
> examples showing how these members are made available in a safe way.   Some
> members may still not be usable because you can't form an argument but IIRC
> the suggestion was that they be exposed anyway for consistency.
>
> >
> > 2. Erase type relationships and trap at runtime when they don't line up.
> >
> > Matthew has been arguing against #2, but you can't “fix the bug” without
> > it.
> >
> >>
> >> -Thorsten
> >>
> >>> Am 08.06.2016 um 21:43 schrieb Austin Zheng :
> >>>
> >>> It's not possible, even with Swift's current implementation of
> >>> existentials. A protocol type P isn't considered to conform to
> >>> itself, thus the following is rejected:
> >>>
> >>> let a : MyProtocol = // ...
> >>> func myFunc(x: T) {
> >>>  // 
> >>> }
> >>> myFunc(a) // "Cannot invoke 'myFunc' with an argument list of type
> MyProtocol"
> >>>
> >>> Changing how this works is probably worth a proposal by itself.
> >>>
> >>> Austin
> >>>
> >>>
> >>> On Wed, Jun 8, 2016 at 12:34 PM, Thorsten Seitz via swift-evolution
> >>>  >>> >
> >>> wrote:
> >>>
>  Am 08.06.2016 um 20:33 schrieb Dave Abrahams via swift-evolution
>    >:
> 
> 
>  on Tue Jun 07 2016, Matthew Johnson  wrote:
> 
> >> On Jun 7, 2016, at 9:15 PM, Dave Abrahams
> >>  >> >
> >> wrote:
> >>
> >>
> >> on Tue Jun 07 2016, Matthew Johnson  >>  >> >> wrote:
> >
>  On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution
>    >
>  wrote:
> 
> 
>  on Tue Jun 07 2016, Matthew Johnson
>    >
>  wrote:
> >>>
> >> , but haven't realized
> >> that if you step around the type relationships encoded in Self
> >> requirements and associated types you end up with types that
> appear to
> >> interoperate but in fact trap at runtime unless used in exactly
> the
> 

Re: [swift-evolution] removing logical operators

[Adam Nemecek via swift-evolution]

https://lists.swift.org/pipermail/swift-evolution/2015-December/32.html

On Wed, Jun 8, 2016 at 2:30 PM, Saagar Jha via swift-evolution <
swift-evolution@swift.org> wrote:

> I think keeping operators as actual operators is preferable. Having *some* but
> not all operators be keywords makes them “special” and unique, which they
> aren’t.
>
> On Wed, Jun 8, 2016 at 2:26 PM Saagar Jha  wrote:
>
>> Well, IIRC Swift doesn’t allow operators that aren’t (math) symbols,
>> right? That might be the first barrier to clear.
>>
>> On Wed, Jun 8, 2016 at 2:24 PM Pranjal Satija via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Hi there,
>>>
>>> I had an idea recently about the use of logical operators in Swift,
>>> specifically && and ||. I felt that it would be more clear to replace these
>>> with the words “and” and “or”. And since most keywords can be used as
>>> argument labels in functions now, this should be more feasible than ever. I
>>> understand that it isn’t a huge difference, but I feel like it might help
>>> make code easier to read, and it would also reduce some confusion for
>>> beginners. Could you let me know what you think?
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>> --
>> -Saagar Jha
>>
> --
> -Saagar Jha
>
> ___
> 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] removing logical operators

[Jordan Rose via swift-evolution]

Please see the list of "commonly proposed changes", which discusses this. 
https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md 


Jordan

> On Jun 8, 2016, at 14:30, Saagar Jha via swift-evolution 
>  wrote:
> 
> I think keeping operators as actual operators is preferable. Having some but 
> not all operators be keywords makes them “special” and unique, which they 
> aren’t.
> 
> On Wed, Jun 8, 2016 at 2:26 PM Saagar Jha  > wrote:
> Well, IIRC Swift doesn’t allow operators that aren’t (math) symbols, right? 
> That might be the first barrier to clear.
> 
> On Wed, Jun 8, 2016 at 2:24 PM Pranjal Satija via swift-evolution 
> > wrote:
> Hi there,
> 
> I had an idea recently about the use of logical operators in Swift, 
> specifically && and ||. I felt that it would be more clear to replace these 
> with the words “and” and “or”. And since most keywords can be used as 
> argument labels in functions now, this should be more feasible than ever. I 
> understand that it isn’t a huge difference, but I feel like it might help 
> make code easier to read, and it would also reduce some confusion for 
> beginners. Could you let me know what you think?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> -- 
> -Saagar Jha
> -- 
> -Saagar Jha
> ___
> 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-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 8, 2016, at 3:16 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
>> on Wed Jun 08 2016, Thorsten Seitz  wrote:
>> 
>> Ah, thanks, I forgot!  I still consider this a bug, though (will have
>> to read up again what the reasons are for that behavior).
> 
> Yes, but in the case of the issue we're discussing, the choices are:
> 
> 1. Omit from the existential's API any protocol requirements that depend
>   on Self or associated types, in which case it *can't* conform to
>   itself because it doesn't fulfill the requirements.

They don't need to be omitted.  They are exposed in different ways depending on 
how the existential is constrained.  Austin's proposal was originally written 
to omit some members but it was modified based on feedback from Doug Gregor 
IIRC (Austin, is that right?).  Now it contains examples showing how these 
members are made available in a safe way.   Some members may still not be 
usable because you can't form an argument but IIRC the suggestion was that they 
be exposed anyway for consistency.

> 
> 2. Erase type relationships and trap at runtime when they don't line up.
> 
> Matthew has been arguing against #2, but you can't “fix the bug” without
> it.
> 
>> 
>> -Thorsten
>> 
>>> Am 08.06.2016 um 21:43 schrieb Austin Zheng :
>>> 
>>> It's not possible, even with Swift's current implementation of
>>> existentials. A protocol type P isn't considered to conform to
>>> itself, thus the following is rejected:
>>> 
>>> let a : MyProtocol = // ...
>>> func myFunc(x: T) {
>>>  // 
>>> }
>>> myFunc(a) // "Cannot invoke 'myFunc' with an argument list of type 
>>> MyProtocol"
>>> 
>>> Changing how this works is probably worth a proposal by itself.
>>> 
>>> Austin
>>> 
>>> 
>>> On Wed, Jun 8, 2016 at 12:34 PM, Thorsten Seitz via swift-evolution
>>> >> >
>>> wrote:
>>> 
 Am 08.06.2016 um 20:33 schrieb Dave Abrahams via swift-evolution
 >:
 
 
 on Tue Jun 07 2016, Matthew Johnson  wrote:
 
>> On Jun 7, 2016, at 9:15 PM, Dave Abrahams
>> > >
>> wrote:
>> 
>> 
>> on Tue Jun 07 2016, Matthew Johnson > > >> wrote:
> 
 On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution
 >
 wrote:
 
 
 on Tue Jun 07 2016, Matthew Johnson
 >
 wrote:
>>> 
>> , but haven't realized
>> that if you step around the type relationships encoded in Self
>> requirements and associated types you end up with types that appear 
>> to
>> interoperate but in fact trap at runtime unless used in exactly the
>> right way.
> 
> Trap at runtime?  How so?  Generalized existentials should still be
> type-safe.
 
 There are two choices when you erase static type relationships:
 
 1. Acheive type-safety by trapping at runtime
 
 FloatingPoint(3.0 as Float) + FloatingPoint(3.0 as Double) // trap
 
 2. Don't expose protocol requirements that involve these relationships,
 which would prevent the code above from compiling and prevent
 FloatingPoint from conforming to itself.
 
> Or are you talking about the hypothetical types / behaviors people
> think they want when they don’t fully understand what is happening...
 
 I don't know what you mean here.  I think generalized existentials will
 be nice to have, but I think most people will want them to do something
 they can't possibly do.
>>> 
>>> Exactly.  What I meant is that people think they want that expression
>>> to compile because they don’t understand that the only thing it can do
>>> is trap.  I said “hypothetical” because producing a compile time error
>>> rather than a runtime trap is the only sane thing to do.  Your comment
>>> surprised me because I can’t imagine we would move forward in Swift
>>> with the approach of trapping.
>> 
>> I would very much like to be able to create instances of “Collection
>> where Element == Int” so we can throw away the wrappers in the stdlib.
>> That will require some type mismatches to be caught at runtime via
>> trapping.
> 
> For invalid index because the existential accepts a type erased index?
 
 Exactly.
 
> How do you decide where to draw the line here?  It feels like a very
> slippery slope for a language where safety is a stated 

Re: [swift-evolution] [Draft] Allow multiple conformances to the same protocol

[Jordan Rose via swift-evolution]

Associated types aren't generic parameters; the whole point is that they're 
requirements, just like the other declarations in a protocol.

You might be trying to invent generic protocols instead, which (IIRC) aren't 
inherently a bad thing. But I think this needs a lot more fleshing out before 
it can really be discussed—it's hard to know how you can and can't use these 
things, and how they might be implemented.

Best,
Jordan


> On Jun 8, 2016, at 12:07, Антон Жилин via swift-evolution 
>  wrote:
> 
> ==Motivation==
> 
> protocol From {
> associatedtype FromType
> init(_ value: FromType)
> }
> 
> The problem is, one type cannot implement multiple From "conversions".
> 
> ==Proposed solution==
> 
> Allow specifying all associated types using generic syntax.
> 
> extension Int : From { }
> extension Int : From { }
> 
> This is only allowed in conformance declarations.
> 
> ==Future directions==
> 
> We can replace all *Convertible protocols with From and Into, which will be 
> defined similarly to Rust.
> 
> - Anton
> ___
> 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: Filter split extension on Sequence to return tuple of sequences that meet criteria and that do not

[Dave Abrahams via swift-evolution]

on Wed Jun 08 2016, gadiraju praneeth  wrote:

> I added an extension to do this, something like this:
>
> extension Array {
>
> func filterSplit(includeElement: (Element) -> Bool) -> ([Element],
> [Element]) {
>
> var elementsSatisfyingCondition = [Element]()
>
> var elementsNotSatisfyingCondition = [Element]()
>
> self.forEach { element in
>
> if includeElement(element)
> { elementsSatisfyingCondition.append(element) }
>
> else { elementsNotSatisfyingCondition.append(element) }
>
> }
>
> return (elementsSatisfyingCondition, elementsNotSatisfyingCondition)
>
> }
>
> }
>
> that way you can right away do: values.filterSplit {
>  }

Yes, it's convenient.  Its efficiency is suboptimal, though, unless you
really need the results to be Arrays (rather than, say ArraySlices).

>
>
> On Wed, Jun 8, 2016 at 3:40 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> on Wed Jun 08 2016, Dave Abrahams  wrote:
>>
>> > on Wed Jun 08 2016, gadiraju praneeth  wrote:
>> >
>> >> Many times, I came across a scenario where I had to filter an array
>> with a
>> >> condition and filter the same array with opposite of that condition. For
>> >> example:
>> >>
>> >> let values = [2, 4, 3, 5, 6, 9]
>> >>
>> >> let divisibleByTwo = values.filter { $0 % 2 == 0 }
>> >> let notDivisibleByTwo = values.filter { $0 % 2 != 0 }
>> >>
>> >> Is there a way currently where we can filter the array into two arrays
>> >> based on a condition?
>> >
>> > Well, you need a stable partition for this if you care about ordering
>> > (see
>> >
>> https://github.com/apple/swift/blob/master/test/Prototypes/Algorithms.swift#L299
>> )
>> > but then you can do
>> >
>> > var parts = values
>> > let mid = values.stablePartition { $0 % 2 == 0 }
>> > let divisibleByTwo = parts.prefix(upTo: mid)
>> > let notDivisibleByTwo = parts.suffix(from: mid)
>> >
>> > Nate Cook has an enhancement to the result of stablyPartitioned in that
>> > prototype that would let you write:
>> >
>> >   let parts = values.stablyPartitioned { $0 % 2 == 0 }
>> >   let divisibleByTwo = parts.prefix(upTo: parts.partitionPoint)
>> >   let notDivisibleByTwo = parts.suffix(from: parts.partitionPoint)
>>
>> Hmm, come to think of it, Nate, maybe there should also be a more
>> convenient way to get the two partitions from the result.
>>
>> --
>> Dave
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>

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

Re: [swift-evolution] removing logical operators

[Saagar Jha via swift-evolution]

I think keeping operators as actual operators is preferable. Having *some* but
not all operators be keywords makes them “special” and unique, which they
aren’t.

On Wed, Jun 8, 2016 at 2:26 PM Saagar Jha  wrote:

> Well, IIRC Swift doesn’t allow operators that aren’t (math) symbols,
> right? That might be the first barrier to clear.
>
> On Wed, Jun 8, 2016 at 2:24 PM Pranjal Satija via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hi there,
>>
>> I had an idea recently about the use of logical operators in Swift,
>> specifically && and ||. I felt that it would be more clear to replace these
>> with the words “and” and “or”. And since most keywords can be used as
>> argument labels in functions now, this should be more feasible than ever. I
>> understand that it isn’t a huge difference, but I feel like it might help
>> make code easier to read, and it would also reduce some confusion for
>> beginners. Could you let me know what you think?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> --
> -Saagar Jha
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Remove nil and NilLiteralConvertible

[Brandon Knope via swift-evolution]

> On Jun 8, 2016, at 5:03 PM, Roth Michaels via swift-evolution 
>  wrote:
> 
> 
> 
> 
> So are you proposing to disallow the following:
> 
> let myStrings = ["s1": "hello, world", "s2": "something else"]
> myStrings["s2"] = nil
> 
> Replacing it with the following:
> 
> let myStrings = ["s1": "hello, world", "s2": "something else"]
> myStrings.removeValueForKey("s2")
> 
> Thus subscript(_) could only be used for adding or updating, but not
> removing, key/value pairs.  I'm not sure how I feel about that yet.
> 
> Would you allow this?
> 
> let myStrings = ["s1": "hello, world", "s2": "something else"]
> myStrings["s2"] = .none
> 
> If so, that would make this example strange:
> 
> enum Stuff {
>  case Bone, Dome, Chrome
> }
> 
> let myStuff: [String:Stuff] = ["s1": .Bone, "s2": .Dome]
> myStuff["s2"] = .none
> myStuff["s1"] = .Chrome
> 
> In this last example, to me it seems less clear that a dictionary index is
> dropped than if nil was used.

Why do you think that is? Why does nil express something different to you than 
Optional.none?

My guess is that you are thinking about it as an object being set to nil and 
thus being deleted when there is no strong reference to it.

Under the hood it may work this way, but I don’t think Optional is trying to 
present it this way

Brandon

> 
> On Wed, Jun 08 2016 at 04:41:15 PM, Антон Жилин via swift-evolution 
>  wrote:
>> (No joking)
>> Points:
>> 
>> 1. When nil was added to the language, we could not infer enumeration
>> type:
>> if x != Optional.none { ... }
>> 
>> Now it looks like this:
>> if x != .none { ... }
>> 
>> If at this point we had a proposal to add nil as a replacement for .
>> none, would we accept it?
>> 
>> 2. nil is very generic, it only approximately allows to express the
>> intentions.
>> In case of Optional, .none is clearer. In case of JSON processing, .null
>> is clearer. In case of a semantically nullable struct,
>> NilLiteralConvertible usually goes to default constructor.
>> 
>> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
>> 
>> 4. There should be a single consistent terminology: no value in Swift
>> equals none.
>> 
>> - Anton
>> 
>> ___
>> 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] removing logical operators

[Saagar Jha via swift-evolution]

Well, IIRC Swift doesn’t allow operators that aren’t (math) symbols, right?
That might be the first barrier to clear.

On Wed, Jun 8, 2016 at 2:24 PM Pranjal Satija via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi there,
>
> I had an idea recently about the use of logical operators in Swift,
> specifically && and ||. I felt that it would be more clear to replace these
> with the words “and” and “or”. And since most keywords can be used as
> argument labels in functions now, this should be more feasible than ever. I
> understand that it isn’t a huge difference, but I feel like it might help
> make code easier to read, and it would also reduce some confusion for
> beginners. Could you let me know what you think?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Filter split extension on Sequence to return tuple of sequences that meet criteria and that do not

[Nate Cook via swift-evolution]

> On Jun 8, 2016, at 3:40 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Jun 08 2016, Dave Abrahams  wrote:
> 
>> on Wed Jun 08 2016, gadiraju praneeth  wrote:
>> 
>>> Many times, I came across a scenario where I had to filter an array with a
>>> condition and filter the same array with opposite of that condition. For
>>> example:
>>> 
>>> let values = [2, 4, 3, 5, 6, 9]
>>> 
>>> let divisibleByTwo = values.filter { $0 % 2 == 0 }
>>> let notDivisibleByTwo = values.filter { $0 % 2 != 0 }
>>> 
>>> Is there a way currently where we can filter the array into two arrays
>>> based on a condition?
>> 
>> Well, you need a stable partition for this if you care about ordering
>> (see
>> https://github.com/apple/swift/blob/master/test/Prototypes/Algorithms.swift#L299)
>> but then you can do 
>> 
>> var parts = values
>> let mid = values.stablePartition { $0 % 2 == 0 }
>> let divisibleByTwo = parts.prefix(upTo: mid)
>> let notDivisibleByTwo = parts.suffix(from: mid)
>> 
>> Nate Cook has an enhancement to the result of stablyPartitioned in that
>> prototype that would let you write:
>> 
>>  let parts = values.stablyPartitioned { $0 % 2 == 0 }
>>  let divisibleByTwo = parts.prefix(upTo: parts.partitionPoint)
>>  let notDivisibleByTwo = parts.suffix(from: parts.partitionPoint)

Mine was for the result of the 'rotated' methods, but should work for the 
partitioning ones, too. It's not as clear to me what the benefit of the "lazy" 
partitioning in that Algorithm.swift is—wouldn't it be better to wrap a 
collection around two lazy filter sequences?

Here is a quick proof of concept of 'divided' and 'partitioned' methods: 
http://swiftlang.ng.bluemix.net/#/repl/57588cbda79b317716f02e04 

> Hmm, come to think of it, Nate, maybe there should also be a more
> convenient way to get the two partitions from the result.

Definitely!

Nate

> -- 
> Dave
> 
> ___
> 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] removing logical operators

[Pranjal Satija via swift-evolution]

Hi there,

I had an idea recently about the use of logical operators in Swift, 
specifically && and ||. I felt that it would be more clear to replace these 
with the words “and” and “or”. And since most keywords can be used as argument 
labels in functions now, this should be more feasible than ever. I understand 
that it isn’t a huge difference, but I feel like it might help make code easier 
to read, and it would also reduce some confusion for beginners. Could you let 
me know what you think?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Remove nil and NilLiteralConvertible

[Brandon Knope via swift-evolution]

I was thinking about this too…but I’m not sure how feasible it would be.

However, I don’t find this any more confusing than having two ways to refer to 
it currently: nil and .none

none == sugar
.none == the underlying implementation of optional as Xiaodi put it (I am 
starting to see this view)

Brandon


> On Jun 8, 2016, at 5:13 PM, Sean Heber  wrote:
> 
> If there’s both “.none” and “none”, then I think that’d be more confusing 
> *because of* the naming consistency, IMO. I’d look at that as a newbie and 
> wonder why in the world this word sometimes has a dot and sometimes doesn’t.
> 
> If enum cases could be referred to without the leading “.” then perhaps I 
> could get behind this because “none” wouldn’t even need to be a keyword at 
> all in that case, but there are probably difficult ambiguities down that road.
> 
> l8r
> Sean
> 
> 
>> On Jun 8, 2016, at 4:04 PM, Brandon Knope  wrote:
>> 
>> 1. People will find .none ugly which is why I think it could be replaced by 
>> a none keyword. It is awkward
>> 2. none is more descriptive than nil in this case. The case is named none 
>> (consistency!) and nil is a holdover from other languages
>> 
>> I understand how nil works in the context of other languages. But looking at 
>> Optional:
>> public enum Optional : NilLiteralConvertible {
>> 
>>/// The absence of a value.
>>///
>>/// In code, the absence of a value is typically written using the `nil`
>>/// literal rather than the explicit `.none` enumeration case.
>>case none
>> 
>>/// The presence of a value, stored as `Wrapped`.
>>case some(Wrapped)
>> }
>> 
>> 
>> These are not pointers and they sure look like one when you assign nil to an 
>> optional
>> 
>> B
>> 
>> Why would nil be chosen to represent the none case in the absence of other 
>> languages?
>> 
>> 
>>> On Jun 8, 2016, at 4:55 PM, Sean Heber  wrote:
>>> 
>>> If you add a new keyword called “none” without the period, but keep 
>>> allowing “.none” to work because Optional is really an enum… then I don’t 
>>> really see what has been gained here at all - you’re basically back to 
>>> nil/.none => 2 ways to say the same thing!
>>> 
>>> l8r
>>> Sean
>>> 
>>> 
 On Jun 8, 2016, at 3:52 PM, Brandon Knope via swift-evolution 
  wrote:
 
 .none or a more appropriate keyword like “none” (imo)
 
 Brandon
 
> On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> It's been pointed out before that Optional being an enum type is treated 
> like an implementation detail. Currently, it is possible to teach the 
> concept of Optional without introducing enum types or generics. How would 
> you do so after elimination of nil?
> 
> 
> On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин  
> wrote:
> (No joking)
> Points:
> 
> 1. When nil was added to the language, we could not infer enumeration 
> type:
> if x != Optional.none { ... }
> 
> Now it looks like this:
> if x != .none { ... }
> 
> If at this point we had a proposal to add nil as a replacement for .none, 
> would we accept it?
> 
> 2. nil is very generic, it only approximately allows to express the 
> intentions.
> In case of Optional, .none is clearer. In case of JSON processing, .null 
> is clearer. In case of a semantically nullable struct, 
> NilLiteralConvertible usually goes to default constructor.
> 
> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
> 
> 4. There should be a single consistent terminology: no value in Swift 
> equals none.
> 
> - Anton
> 
> ___
> 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] Remove nil and NilLiteralConvertible

[Sean Heber via swift-evolution]

If there’s both “.none” and “none”, then I think that’d be more confusing 
*because of* the naming consistency, IMO. I’d look at that as a newbie and 
wonder why in the world this word sometimes has a dot and sometimes doesn’t.

If enum cases could be referred to without the leading “.” then perhaps I could 
get behind this because “none” wouldn’t even need to be a keyword at all in 
that case, but there are probably difficult ambiguities down that road.

l8r
Sean


> On Jun 8, 2016, at 4:04 PM, Brandon Knope  wrote:
> 
> 1. People will find .none ugly which is why I think it could be replaced by a 
> none keyword. It is awkward
> 2. none is more descriptive than nil in this case. The case is named none 
> (consistency!) and nil is a holdover from other languages
> 
> I understand how nil works in the context of other languages. But looking at 
> Optional:
> public enum Optional : NilLiteralConvertible {
> 
> /// The absence of a value.
> ///
> /// In code, the absence of a value is typically written using the `nil`
> /// literal rather than the explicit `.none` enumeration case.
> case none
> 
> /// The presence of a value, stored as `Wrapped`.
> case some(Wrapped)
> }
> 
> 
> These are not pointers and they sure look like one when you assign nil to an 
> optional
> 
> B
> 
> Why would nil be chosen to represent the none case in the absence of other 
> languages?
> 
> 
>> On Jun 8, 2016, at 4:55 PM, Sean Heber  wrote:
>> 
>> If you add a new keyword called “none” without the period, but keep allowing 
>> “.none” to work because Optional is really an enum… then I don’t really see 
>> what has been gained here at all - you’re basically back to nil/.none => 2 
>> ways to say the same thing!
>> 
>> l8r
>> Sean
>> 
>> 
>>> On Jun 8, 2016, at 3:52 PM, Brandon Knope via swift-evolution 
>>>  wrote:
>>> 
>>> .none or a more appropriate keyword like “none” (imo)
>>> 
>>> Brandon
>>> 
 On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution 
  wrote:
 
 It's been pointed out before that Optional being an enum type is treated 
 like an implementation detail. Currently, it is possible to teach the 
 concept of Optional without introducing enum types or generics. How would 
 you do so after elimination of nil?
 
 
 On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин  
 wrote:
 (No joking)
 Points:
 
 1. When nil was added to the language, we could not infer enumeration type:
 if x != Optional.none { ... }
 
 Now it looks like this:
 if x != .none { ... }
 
 If at this point we had a proposal to add nil as a replacement for .none, 
 would we accept it?
 
 2. nil is very generic, it only approximately allows to express the 
 intentions.
 In case of Optional, .none is clearer. In case of JSON processing, .null 
 is clearer. In case of a semantically nullable struct, 
 NilLiteralConvertible usually goes to default constructor.
 
 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
 
 4. There should be a single consistent terminology: no value in Swift 
 equals none.
 
 - Anton
 
 ___
 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] Remove nil and NilLiteralConvertible

[Brandon Knope via swift-evolution]

Isn’t the only thing keeping nil relevant is the NilLiteralConvertible protocol?

Brandon

> On Jun 8, 2016, at 5:08 PM, John McCall via swift-evolution 
>  wrote:
> 
>> On Jun 8, 2016, at 1:41 PM, Антон Жилин via swift-evolution 
>>  wrote:
>> (No joking)
>> Points:
>> 
>> 1. When nil was added to the language, we could not infer enumeration type:
>> if x != Optional.none { ... }
>> 
>> Now it looks like this:
>> if x != .none { ... }
>> 
>> If at this point we had a proposal to add nil as a replacement for .none, 
>> would we accept it?
>> 
>> 2. nil is very generic, it only approximately allows to express the 
>> intentions.
>> In case of Optional, .none is clearer. In case of JSON processing, .null is 
>> clearer. In case of a semantically nullable struct, NilLiteralConvertible 
>> usually goes to default constructor.
>> 
>> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
>> 
>> 4. There should be a single consistent terminology: no value in Swift equals 
>> none.
> 
> I know we're making a lot of source-compatibility breaks in Swift 3 and so 
> these lines seem blurry, but I think the spelling of "nil" is quite solidly 
> in the "that ship has sailed" category, along with "struct" and "func" and 
> "var".
> 
> 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] Remove nil and NilLiteralConvertible

[Brandon Knope via swift-evolution]

In my other thread where this came up, my support is:
1. Removing NilLiteralConvertible conformance from Optional (apparently other 
people use this protocol?)
2. Introducing a new keyword that is sugar for .none

Would I like to remove nil and NilLiteralConvertible? Perhaps, but it seems 
that some people use them for other things and I would hate to take it away 
from them. 

My concerns come down to this:
- It looks like a pointer
- People learning Swift as their first language will go to other languages and 
expect “nil” to be safe. Swift seems to be mostly alone here: nil is safe 
whereas in most languages it is not safe to dereference a nil pointer
- It is not consistent with the Optional enum naming
- It is not as descriptive or expressive


Brandon

> On Jun 8, 2016, at 4:59 PM, Brandon Knope via swift-evolution 
>  wrote:
> 
> Is it really an implementation detail? It is very leaky if it is one because 
> it is highly exposed to everyone.
> 
> Regardless of whether or not it is an implementation detail, nil does not 
> adequately describe the “none” case it is trying to represent in my opinion
> 
> B
> 
> 
>> On Jun 8, 2016, at 4:56 PM, Xiaodi Wu > > wrote:
>> 
>> On Wed, Jun 8, 2016 at 3:52 PM, Brandon Knope > > wrote:
>> .none or a more appropriate keyword like “none” (imo)
>> 
>> 
>> My point is that `.none` exposes the underlying enum. The premise here is 
>> that the enum is an implementation detail. You'll notice that, currently, 
>> significant sugar and magic is devoted to allowing you to work with 
>> optionals without ever writing `.some` or `none`. For example, `if let x = 
>> ...` and friends allow you to avoid writing `if case .some(let x) = ...`, 
>> while you can write `return x` instead of `return .some(x)`. This was, IIUC, 
>> a deliberate choice to allow progressive disclosure of the language to 
>> learners. Renaming `nil` to `none` is a different proposal from Anton is 
>> proposing here.
>>  
>> Brandon
>> 
>>> On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
>>> It's been pointed out before that Optional being an enum type is treated 
>>> like an implementation detail. Currently, it is possible to teach the 
>>> concept of Optional without introducing enum types or generics. How would 
>>> you do so after elimination of nil?
>>> 
>>> 
>>> On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин >> > wrote:
>>> (No joking)
>>> Points:
>>> 
>>> 1. When nil was added to the language, we could not infer enumeration type:
>>> if x != Optional.none { ... }
>>> 
>>> Now it looks like this:
>>> if x != .none { ... }
>>> 
>>> If at this point we had a proposal to add nil as a replacement for .none, 
>>> would we accept it?
>>> 
>>> 2. nil is very generic, it only approximately allows to express the 
>>> intentions.
>>> In case of Optional, .none is clearer. In case of JSON processing, .null is 
>>> clearer. In case of a semantically nullable struct, NilLiteralConvertible 
>>> usually goes to default constructor.
>>> 
>>> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
>>> 
>>> 4. There should be a single consistent terminology: no value in Swift 
>>> equals none.
>>> 
>>> - Anton
>>> 
>>> ___
>>> 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] Remove nil and NilLiteralConvertible

[John McCall via swift-evolution]

> On Jun 8, 2016, at 1:41 PM, Антон Жилин via swift-evolution 
>  wrote:
> (No joking)
> Points:
> 
> 1. When nil was added to the language, we could not infer enumeration type:
> if x != Optional.none { ... }
> 
> Now it looks like this:
> if x != .none { ... }
> 
> If at this point we had a proposal to add nil as a replacement for .none, 
> would we accept it?
> 
> 2. nil is very generic, it only approximately allows to express the 
> intentions.
> In case of Optional, .none is clearer. In case of JSON processing, .null is 
> clearer. In case of a semantically nullable struct, NilLiteralConvertible 
> usually goes to default constructor.
> 
> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
> 
> 4. There should be a single consistent terminology: no value in Swift equals 
> none.

I know we're making a lot of source-compatibility breaks in Swift 3 and so 
these lines seem blurry, but I think the spelling of "nil" is quite solidly in 
the "that ship has sailed" category, along with "struct" and "func" and "var".

John.

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

Re: [swift-evolution] Remove nil and NilLiteralConvertible

[Roth Michaels via swift-evolution]

So are you proposing to disallow the following:

let myStrings = ["s1": "hello, world", "s2": "something else"]
myStrings["s2"] = nil

Replacing it with the following:

let myStrings = ["s1": "hello, world", "s2": "something else"]
myStrings.removeValueForKey("s2")

Thus subscript(_) could only be used for adding or updating, but not
removing, key/value pairs.  I'm not sure how I feel about that yet.

Would you allow this?

let myStrings = ["s1": "hello, world", "s2": "something else"]
myStrings["s2"] = .none

If so, that would make this example strange:

enum Stuff {
  case Bone, Dome, Chrome
}

let myStuff: [String:Stuff] = ["s1": .Bone, "s2": .Dome]
myStuff["s2"] = .none
myStuff["s1"] = .Chrome

In this last example, to me it seems less clear that a dictionary index is
dropped than if nil was used.

On Wed, Jun 08 2016 at 04:41:15 PM, Антон Жилин via swift-evolution 
 wrote:
> (No joking)
> Points:
>
> 1. When nil was added to the language, we could not infer enumeration
> type:
> if x != Optional.none { ... }
>
> Now it looks like this:
> if x != .none { ... }
>
> If at this point we had a proposal to add nil as a replacement for .
> none, would we accept it?
>
> 2. nil is very generic, it only approximately allows to express the
> intentions.
> In case of Optional, .none is clearer. In case of JSON processing, .null
> is clearer. In case of a semantically nullable struct,
> NilLiteralConvertible usually goes to default constructor.
>
> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
>
> 4. There should be a single consistent terminology: no value in Swift
> equals none.
>
> - Anton
>
> ___
> 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] Remove nil and NilLiteralConvertible

[Brandon Knope via swift-evolution]

1. People will find .none ugly which is why I think it could be replaced by a 
none keyword. It is awkward
2. none is more descriptive than nil in this case. The case is named none 
(consistency!) and nil is a holdover from other languages

I understand how nil works in the context of other languages. But looking at 
Optional:
public enum Optional : NilLiteralConvertible {

/// The absence of a value.
///
/// In code, the absence of a value is typically written using the `nil`
/// literal rather than the explicit `.none` enumeration case.
case none

/// The presence of a value, stored as `Wrapped`.
case some(Wrapped)
}


These are not pointers and they sure look like one when you assign nil to an 
optional

B

Why would nil be chosen to represent the none case in the absence of other 
languages?


> On Jun 8, 2016, at 4:55 PM, Sean Heber  wrote:
> 
> If you add a new keyword called “none” without the period, but keep allowing 
> “.none” to work because Optional is really an enum… then I don’t really see 
> what has been gained here at all - you’re basically back to nil/.none => 2 
> ways to say the same thing!
> 
> l8r
> Sean
> 
> 
>> On Jun 8, 2016, at 3:52 PM, Brandon Knope via swift-evolution 
>>  wrote:
>> 
>> .none or a more appropriate keyword like “none” (imo)
>> 
>> Brandon
>> 
>>> On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> It's been pointed out before that Optional being an enum type is treated 
>>> like an implementation detail. Currently, it is possible to teach the 
>>> concept of Optional without introducing enum types or generics. How would 
>>> you do so after elimination of nil?
>>> 
>>> 
>>> On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин  
>>> wrote:
>>> (No joking)
>>> Points:
>>> 
>>> 1. When nil was added to the language, we could not infer enumeration type:
>>> if x != Optional.none { ... }
>>> 
>>> Now it looks like this:
>>> if x != .none { ... }
>>> 
>>> If at this point we had a proposal to add nil as a replacement for .none, 
>>> would we accept it?
>>> 
>>> 2. nil is very generic, it only approximately allows to express the 
>>> intentions.
>>> In case of Optional, .none is clearer. In case of JSON processing, .null is 
>>> clearer. In case of a semantically nullable struct, NilLiteralConvertible 
>>> usually goes to default constructor.
>>> 
>>> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
>>> 
>>> 4. There should be a single consistent terminology: no value in Swift 
>>> equals none.
>>> 
>>> - Anton
>>> 
>>> ___
>>> 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] Philosophy of Swift

[Jordan Rose via swift-evolution]

https://swift.org/about/  has some pretty good 
verbiage about this. In particular:

"Swift is a safe language."

in that the obvious thing should be safe, and unsafe things should require a 
bit of reaching. That's more important to me than a lot of other things that 
happen to be true.

(I've been sneakily saying this in person every time someone asks me, but I 
guess I can say it out loud here. Please don't call it an "official Apple 
opinion" or "official swift.org opinion", though. It's "one Swift compiler 
developer's opinion". :-) The official swift.org opinion is how it's phrased on 
swift.org.)

Jordan


> On Jun 8, 2016, at 6:18, Brandon Knope via swift-evolution 
>  wrote:
> 
> My favorite is that Swift is an opinionated language :P
> 
> "We intentionally want Swift to have a common “center of gravity” and be an
> “opinionated” language, rather than fall to the “design by committee” 
> approach that leads to a
> watered-down design”
> This was from Chris Lattner
> 
> Reference: Re: [Review] Replace `typealias` keyword with `associatedtype` for 
> associated ty 
> 
> 
> Brandon
> 
>> On Jun 8, 2016, at 9:03 AM, Jonathan Hull via swift-evolution 
>> > wrote:
>> 
>> I am (somewhat unexpectedly) teaching a class in Swift/iOS starting later 
>> this week, and I was hoping to get a couple of quotes to share with my 
>> students from the community (and ideally a core team member) about what they 
>> believe the general philosophy behind Swift is…
>> 
>> I have heard things like:
>> “Swift is a practical language”
>> “Swift is the first Protocol Oriented Language”
>> 
>> How would you define Swift in your own words?
>> 
>> Thanks,
>> Jon
>> ___
>> 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] Remove nil and NilLiteralConvertible

[Xiaodi Wu via swift-evolution]

On Wed, Jun 8, 2016 at 3:59 PM, Brandon Knope  wrote:

> Is it really an implementation detail? It is very leaky if it is one
> because it is highly exposed to everyone.
>
> Regardless of whether or not it is an implementation detail, nil does not
> adequately describe the “none” case it is trying to represent in my opinion
>

So you're arguing for renaming as opposed to removal then.


>
>
> B
>
>
> On Jun 8, 2016, at 4:56 PM, Xiaodi Wu  wrote:
>
> On Wed, Jun 8, 2016 at 3:52 PM, Brandon Knope  wrote:
>
>> .none or a more appropriate keyword like “none” (imo)
>>
>>
> My point is that `.none` exposes the underlying enum. The premise here is
> that the enum is an implementation detail. You'll notice that, currently,
> significant sugar and magic is devoted to allowing you to work with
> optionals without ever writing `.some` or `none`. For example, `if let x =
> ...` and friends allow you to avoid writing `if case .some(let x) = ...`,
> while you can write `return x` instead of `return .some(x)`. This was,
> IIUC, a deliberate choice to allow progressive disclosure of the language
> to learners. Renaming `nil` to `none` is a different proposal from Anton is
> proposing here.
>
>
>> Brandon
>>
>> On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> It's been pointed out before that Optional being an enum type is treated
>> like an implementation detail. Currently, it is possible to teach the
>> concept of Optional without introducing enum types or generics. How would
>> you do so after elimination of nil?
>>
>>
>> On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин 
>> wrote:
>>
>>> (No joking)
>>> Points:
>>>
>>> 1. When nil was added to the language, we could not infer enumeration
>>> type:
>>> if x != Optional.none { ... }
>>>
>>> Now it looks like this:
>>> if x != .none { ... }
>>>
>>> If at this point we had a proposal to add nil as a replacement for
>>> .none, would we accept it?
>>>
>>> 2. nil is very generic, it only approximately allows to express the
>>> intentions.
>>> In case of Optional, .none is clearer. In case of JSON processing, .null
>>> is clearer. In case of a semantically nullable struct,
>>> NilLiteralConvertible usually goes to default constructor.
>>>
>>> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
>>>
>>> 4. There should be a single consistent terminology: no value in Swift
>>> equals none.
>>>
>>> - Anton
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Jordan Rose via swift-evolution]

> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Jun 08 2016, Thorsten Seitz  > wrote:
> 
>> Ah, thanks, I forgot!  I still consider this a bug, though (will have
>> to read up again what the reasons are for that behavior).
> 
> Yes, but in the case of the issue we're discussing, the choices are:
> 
> 1. Omit from the existential's API any protocol requirements that depend
>   on Self or associated types, in which case it *can't* conform to
>   itself because it doesn't fulfill the requirements.
> 
> 2. Erase type relationships and trap at runtime when they don't line up.
> 
> Matthew has been arguing against #2, but you can't “fix the bug” without
> it.

#1 has been my preference for a while as well, at least as a starting point. 
It's possible we could also "open" the existential when it's only used by one 
parameter, i.e. the first would be legal and the second wouldn't:

func foo(x: X) { … }
func test(x: Any) {
  foo(x) // okay, passes the dynamic type
}

func bar(a: X, b: X) { … }
func test(x: Any, y: Any) {
  bar(x, y) // illegal because x.dynamicType may be different from y.dynamicType
}

(The check is not as simple as "the generic parameter is only mentioned once", 
because of constraints and such. But you get the idea.)

Jordan

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

Re: [swift-evolution] Proposal: Filter split extension on Sequence to return tuple of sequences that meet criteria and that do not

[gadiraju praneeth via swift-evolution]

Its values.filterSplit { $0 % 2 == 0 } in this case

On Wed, Jun 8, 2016 at 3:59 PM, gadiraju praneeth <
praneethgadir...@gmail.com> wrote:

> I added an extension to do this, something like this:
>
> extension Array {
>
> func filterSplit(includeElement: (Element) -> Bool) -> ([Element],
> [Element]) {
>
> var elementsSatisfyingCondition = [Element]()
>
> var elementsNotSatisfyingCondition = [Element]()
>
>
>
> self.forEach { element in
>
> if includeElement(element)
> { elementsSatisfyingCondition.append(element) }
>
> else { elementsNotSatisfyingCondition.append(element) }
>
> }
>
>
>
> return
> (elementsSatisfyingCondition, elementsNotSatisfyingCondition)
>
> }
>
> }
>
>
> that way you can right away do: values.filterSplit {  }
>
>
>
> On Wed, Jun 8, 2016 at 3:40 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> on Wed Jun 08 2016, Dave Abrahams  wrote:
>>
>> > on Wed Jun 08 2016, gadiraju praneeth 
>> wrote:
>> >
>> >> Many times, I came across a scenario where I had to filter an array
>> with a
>> >> condition and filter the same array with opposite of that condition.
>> For
>> >> example:
>> >>
>> >> let values = [2, 4, 3, 5, 6, 9]
>> >>
>> >> let divisibleByTwo = values.filter { $0 % 2 == 0 }
>> >> let notDivisibleByTwo = values.filter { $0 % 2 != 0 }
>> >>
>> >> Is there a way currently where we can filter the array into two arrays
>> >> based on a condition?
>> >
>> > Well, you need a stable partition for this if you care about ordering
>> > (see
>> >
>> https://github.com/apple/swift/blob/master/test/Prototypes/Algorithms.swift#L299
>> )
>> > but then you can do
>> >
>> > var parts = values
>> > let mid = values.stablePartition { $0 % 2 == 0 }
>> > let divisibleByTwo = parts.prefix(upTo: mid)
>> > let notDivisibleByTwo = parts.suffix(from: mid)
>> >
>> > Nate Cook has an enhancement to the result of stablyPartitioned in that
>> > prototype that would let you write:
>> >
>> >   let parts = values.stablyPartitioned { $0 % 2 == 0 }
>> >   let divisibleByTwo = parts.prefix(upTo: parts.partitionPoint)
>> >   let notDivisibleByTwo = parts.suffix(from: parts.partitionPoint)
>>
>> Hmm, come to think of it, Nate, maybe there should also be a more
>> convenient way to get the two partitions from the result.
>>
>> --
>> Dave
>>
>> ___
>> 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: Filter split extension on Sequence to return tuple of sequences that meet criteria and that do not

[gadiraju praneeth via swift-evolution]

I added an extension to do this, something like this:

extension Array {

func filterSplit(includeElement: (Element) -> Bool) -> ([Element],
[Element]) {

var elementsSatisfyingCondition = [Element]()

var elementsNotSatisfyingCondition = [Element]()



self.forEach { element in

if includeElement(element)
{ elementsSatisfyingCondition.append(element) }

else { elementsNotSatisfyingCondition.append(element) }

}



return (elementsSatisfyingCondition, elementsNotSatisfyingCondition)

}

}


that way you can right away do: values.filterSplit {  }



On Wed, Jun 8, 2016 at 3:40 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Wed Jun 08 2016, Dave Abrahams  wrote:
>
> > on Wed Jun 08 2016, gadiraju praneeth  wrote:
> >
> >> Many times, I came across a scenario where I had to filter an array
> with a
> >> condition and filter the same array with opposite of that condition. For
> >> example:
> >>
> >> let values = [2, 4, 3, 5, 6, 9]
> >>
> >> let divisibleByTwo = values.filter { $0 % 2 == 0 }
> >> let notDivisibleByTwo = values.filter { $0 % 2 != 0 }
> >>
> >> Is there a way currently where we can filter the array into two arrays
> >> based on a condition?
> >
> > Well, you need a stable partition for this if you care about ordering
> > (see
> >
> https://github.com/apple/swift/blob/master/test/Prototypes/Algorithms.swift#L299
> )
> > but then you can do
> >
> > var parts = values
> > let mid = values.stablePartition { $0 % 2 == 0 }
> > let divisibleByTwo = parts.prefix(upTo: mid)
> > let notDivisibleByTwo = parts.suffix(from: mid)
> >
> > Nate Cook has an enhancement to the result of stablyPartitioned in that
> > prototype that would let you write:
> >
> >   let parts = values.stablyPartitioned { $0 % 2 == 0 }
> >   let divisibleByTwo = parts.prefix(upTo: parts.partitionPoint)
> >   let notDivisibleByTwo = parts.suffix(from: parts.partitionPoint)
>
> Hmm, come to think of it, Nate, maybe there should also be a more
> convenient way to get the two partitions from the result.
>
> --
> Dave
>
> ___
> 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] extend trailing closure rule

[Paul Cantrell via swift-evolution]

> On Jun 8, 2016, at 3:46 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
>> 
>> On Jun 8, 2016, at 12:06, Matt Neuburg via swift-evolution 
>>  wrote:
>> 
>> Stop me if you've heard this one; I've only just joined the list, in order 
>> to raise it.
>> 
>> Here's a common thing to say:
>> 
>>   UIView.animate(withDuration:0.4, animations: {
>>   self.v.backgroundColor = UIColor.red()
>>   })
>> 
>> That's ugly. I'd rather write:
>> 
>>   UIView.animate(withDuration:0.4) {
>>   self.v.backgroundColor = UIColor.red()
>>   }
>> 
>> What stops me is that `animations:` is not eligible for trailing closure 
>> syntax, because it isn't the last parameter — `completion:` is. But 
>> `completion:` has a default value, namely `nil` — that's why I'm allowed to 
>> omit it. So why can't the compiler work its way backwards through the 
>> parameters, and say to itself: "Well, I see a trailing closure, and I don't 
>> see any `animations:` label or any `completion:` label, so this trailing 
>> closure must be the `animations:` argument and the `completions:` argument 
>> must be `nil`."
>> 
>> The idea is that this would work for _any_ function call where the function 
>> takes, as its last parameters, a series of function arguments that have 
>> default values. There can be only one trailing closure, so it should be 
>> assumed to occupy the first available slot, as it were.
>> 
>> Would this be viable? Would it make a decent proposal? m.
> 
> I'm one of those in favor of going the other way: if a function takes 
> multiple closure arguments, you shouldn't be allowed to use a trailing 
> closure at all, because it may not be obvious to readers of your code which 
> one you are using. (This is especially true if the closures have the same 
> signature.)

I’m not in favor of that. Good argument labeling can make it perfectly clear to 
readers.

Siesta even leans on this feature a bit in one of its API methods:

configure(whenURLMatches: { $0 != authentication.url }) {
$0.config.headers["authentication-token"] = self.accessToken
}

…with this local refactoring if the first closure grows unwieldy:

let specialFancyResources = {
// Special fancy matching goes here
}

configure(whenURLMatches: specialFancyResources) {
$0.config.headers["authentication-token"] = self.accessToken
}

Both of those forms seem readable to me. I’d hate to rule them out.

Cheers, P


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

Re: [swift-evolution] Remove nil and NilLiteralConvertible

[Brandon Knope via swift-evolution]

Is it really an implementation detail? It is very leaky if it is one because it 
is highly exposed to everyone.

Regardless of whether or not it is an implementation detail, nil does not 
adequately describe the “none” case it is trying to represent in my opinion

B


> On Jun 8, 2016, at 4:56 PM, Xiaodi Wu  wrote:
> 
> On Wed, Jun 8, 2016 at 3:52 PM, Brandon Knope  > wrote:
> .none or a more appropriate keyword like “none” (imo)
> 
> 
> My point is that `.none` exposes the underlying enum. The premise here is 
> that the enum is an implementation detail. You'll notice that, currently, 
> significant sugar and magic is devoted to allowing you to work with optionals 
> without ever writing `.some` or `none`. For example, `if let x = ...` and 
> friends allow you to avoid writing `if case .some(let x) = ...`, while you 
> can write `return x` instead of `return .some(x)`. This was, IIUC, a 
> deliberate choice to allow progressive disclosure of the language to 
> learners. Renaming `nil` to `none` is a different proposal from Anton is 
> proposing here.
>  
> Brandon
> 
>> On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> It's been pointed out before that Optional being an enum type is treated 
>> like an implementation detail. Currently, it is possible to teach the 
>> concept of Optional without introducing enum types or generics. How would 
>> you do so after elimination of nil?
>> 
>> 
>> On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин > > wrote:
>> (No joking)
>> Points:
>> 
>> 1. When nil was added to the language, we could not infer enumeration type:
>> if x != Optional.none { ... }
>> 
>> Now it looks like this:
>> if x != .none { ... }
>> 
>> If at this point we had a proposal to add nil as a replacement for .none, 
>> would we accept it?
>> 
>> 2. nil is very generic, it only approximately allows to express the 
>> intentions.
>> In case of Optional, .none is clearer. In case of JSON processing, .null is 
>> clearer. In case of a semantically nullable struct, NilLiteralConvertible 
>> usually goes to default constructor.
>> 
>> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
>> 
>> 4. There should be a single consistent terminology: no value in Swift equals 
>> none.
>> 
>> - Anton
>> 
>> ___
>> 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] Remove nil and NilLiteralConvertible

[Xiaodi Wu via swift-evolution]

On Wed, Jun 8, 2016 at 3:52 PM, Brandon Knope  wrote:

> .none or a more appropriate keyword like “none” (imo)
>
>
My point is that `.none` exposes the underlying enum. The premise here is
that the enum is an implementation detail. You'll notice that, currently,
significant sugar and magic is devoted to allowing you to work with
optionals without ever writing `.some` or `none`. For example, `if let x =
...` and friends allow you to avoid writing `if case .some(let x) = ...`,
while you can write `return x` instead of `return .some(x)`. This was,
IIUC, a deliberate choice to allow progressive disclosure of the language
to learners. Renaming `nil` to `none` is a different proposal from Anton is
proposing here.


> Brandon
>
> On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It's been pointed out before that Optional being an enum type is treated
> like an implementation detail. Currently, it is possible to teach the
> concept of Optional without introducing enum types or generics. How would
> you do so after elimination of nil?
>
>
> On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин 
> wrote:
>
>> (No joking)
>> Points:
>>
>> 1. When nil was added to the language, we could not infer enumeration
>> type:
>> if x != Optional.none { ... }
>>
>> Now it looks like this:
>> if x != .none { ... }
>>
>> If at this point we had a proposal to add nil as a replacement for .none,
>> would we accept it?
>>
>> 2. nil is very generic, it only approximately allows to express the
>> intentions.
>> In case of Optional, .none is clearer. In case of JSON processing, .null
>> is clearer. In case of a semantically nullable struct,
>> NilLiteralConvertible usually goes to default constructor.
>>
>> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
>>
>> 4. There should be a single consistent terminology: no value in Swift
>> equals none.
>>
>> - Anton
>>
>> ___
>> 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] Remove nil and NilLiteralConvertible

[Sean Heber via swift-evolution]

If you add a new keyword called “none” without the period, but keep allowing 
“.none” to work because Optional is really an enum… then I don’t really see 
what has been gained here at all - you’re basically back to nil/.none => 2 ways 
to say the same thing!

l8r
Sean


> On Jun 8, 2016, at 3:52 PM, Brandon Knope via swift-evolution 
>  wrote:
> 
> .none or a more appropriate keyword like “none” (imo)
> 
> Brandon
> 
>> On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> It's been pointed out before that Optional being an enum type is treated 
>> like an implementation detail. Currently, it is possible to teach the 
>> concept of Optional without introducing enum types or generics. How would 
>> you do so after elimination of nil?
>> 
>> 
>> On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин  
>> wrote:
>> (No joking)
>> Points:
>> 
>> 1. When nil was added to the language, we could not infer enumeration type:
>> if x != Optional.none { ... }
>> 
>> Now it looks like this:
>> if x != .none { ... }
>> 
>> If at this point we had a proposal to add nil as a replacement for .none, 
>> would we accept it?
>> 
>> 2. nil is very generic, it only approximately allows to express the 
>> intentions.
>> In case of Optional, .none is clearer. In case of JSON processing, .null is 
>> clearer. In case of a semantically nullable struct, NilLiteralConvertible 
>> usually goes to default constructor.
>> 
>> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
>> 
>> 4. There should be a single consistent terminology: no value in Swift equals 
>> none.
>> 
>> - Anton
>> 
>> ___
>> 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] Remove nil and NilLiteralConvertible

[Brandon Knope via swift-evolution]

.none or a more appropriate keyword like “none” (imo)

Brandon

> On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> It's been pointed out before that Optional being an enum type is treated like 
> an implementation detail. Currently, it is possible to teach the concept of 
> Optional without introducing enum types or generics. How would you do so 
> after elimination of nil?
> 
> 
> On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин  > wrote:
> (No joking)
> Points:
> 
> 1. When nil was added to the language, we could not infer enumeration type:
> if x != Optional.none { ... }
> 
> Now it looks like this:
> if x != .none { ... }
> 
> If at this point we had a proposal to add nil as a replacement for .none, 
> would we accept it?
> 
> 2. nil is very generic, it only approximately allows to express the 
> intentions.
> In case of Optional, .none is clearer. In case of JSON processing, .null is 
> clearer. In case of a semantically nullable struct, NilLiteralConvertible 
> usually goes to default constructor.
> 
> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
> 
> 4. There should be a single consistent terminology: no value in Swift equals 
> none.
> 
> - Anton
> 
> ___
> 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] Remove nil and NilLiteralConvertible

[Xiaodi Wu via swift-evolution]

It's been pointed out before that Optional being an enum type is treated
like an implementation detail. Currently, it is possible to teach the
concept of Optional without introducing enum types or generics. How would
you do so after elimination of nil?


On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин 
wrote:

> (No joking)
> Points:
>
> 1. When nil was added to the language, we could not infer enumeration type:
> if x != Optional.none { ... }
>
> Now it looks like this:
> if x != .none { ... }
>
> If at this point we had a proposal to add nil as a replacement for .none,
> would we accept it?
>
> 2. nil is very generic, it only approximately allows to express the
> intentions.
> In case of Optional, .none is clearer. In case of JSON processing, .null
> is clearer. In case of a semantically nullable struct,
> NilLiteralConvertible usually goes to default constructor.
>
> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
>
> 4. There should be a single consistent terminology: no value in Swift
> equals none.
>
> - Anton
>
> ___
> 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] Remove nil and NilLiteralConvertible

[Brandon Knope via swift-evolution]

I think you know I am very +1 on this :)

Brandon

> On Jun 8, 2016, at 4:41 PM, Антон Жилин via swift-evolution 
>  wrote:
> 
> (No joking)
> Points:
> 
> 1. When nil was added to the language, we could not infer enumeration type:
> if x != Optional.none { ... }
> 
> Now it looks like this:
> if x != .none { ... }
> 
> If at this point we had a proposal to add nil as a replacement for .none, 
> would we accept it?
> 
> 2. nil is very generic, it only approximately allows to express the 
> intentions.
> In case of Optional, .none is clearer. In case of JSON processing, .null is 
> clearer. In case of a semantically nullable struct, NilLiteralConvertible 
> usually goes to default constructor.
> 
> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
> 
> 4. There should be a single consistent terminology: no value in Swift equals 
> none.
> 
> - Anton
> ___
> 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] extend trailing closure rule

[Jordan Rose via swift-evolution]

> On Jun 8, 2016, at 12:06, Matt Neuburg via swift-evolution 
>  wrote:
> 
> Stop me if you've heard this one; I've only just joined the list, in order to 
> raise it.
> 
> Here's a common thing to say:
> 
>UIView.animate(withDuration:0.4, animations: {
>self.v.backgroundColor = UIColor.red()
>})
> 
> That's ugly. I'd rather write:
> 
>UIView.animate(withDuration:0.4) {
>self.v.backgroundColor = UIColor.red()
>}
> 
> What stops me is that `animations:` is not eligible for trailing closure 
> syntax, because it isn't the last parameter — `completion:` is. But 
> `completion:` has a default value, namely `nil` — that's why I'm allowed to 
> omit it. So why can't the compiler work its way backwards through the 
> parameters, and say to itself: "Well, I see a trailing closure, and I don't 
> see any `animations:` label or any `completion:` label, so this trailing 
> closure must be the `animations:` argument and the `completions:` argument 
> must be `nil`."
> 
> The idea is that this would work for _any_ function call where the function 
> takes, as its last parameters, a series of function arguments that have 
> default values. There can be only one trailing closure, so it should be 
> assumed to occupy the first available slot, as it were.
> 
> Would this be viable? Would it make a decent proposal? m.

I'm one of those in favor of going the other way: if a function takes multiple 
closure arguments, you shouldn't be allowed to use a trailing closure at all, 
because it may not be obvious to readers of your code which one you are using. 
(This is especially true if the closures have the same signature.)

Jordan

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

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

[Jordan Rose via swift-evolution]

> On Jun 8, 2016, at 11:06, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Jun 08 2016, Chris Lattner  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..
> 
> There is *no reason* to do this.
> 
> * Most sorting algorithms can be written so that even if the comparison
>  throws, no elements are lost
> 
> * Even if elements were lost—though it might indeed be surprising—it's
>  not actually a problem we should solve, especially not by penalizing
>  performance.  It's *very* unlikely that a partially scrambled
>  collection is of any use to the caller in real code.
> 
> * Giving commit-or-rollback semantics for every operation is not
>  something we should do by penalizing performance. Commit-or-rollback
>  does not compose, and therefore ends up uselessly penalizing
>  performance in compositions.

FWIW Dave gave me most of the same feedback in the discussion on the 
proof-of-concept pull request: 
https://github.com/apple/swift/pull/1527#discussion_r60811569 


Jordan

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

Re: [swift-evolution] Proposal: Filter split extension on Sequence to return tuple of sequences that meet criteria and that do not

[Dave Abrahams via swift-evolution]

on Wed Jun 08 2016, Dave Abrahams  wrote:

> on Wed Jun 08 2016, gadiraju praneeth  wrote:
>
>> Many times, I came across a scenario where I had to filter an array with a
>> condition and filter the same array with opposite of that condition. For
>> example:
>>
>> let values = [2, 4, 3, 5, 6, 9]
>>
>> let divisibleByTwo = values.filter { $0 % 2 == 0 }
>> let notDivisibleByTwo = values.filter { $0 % 2 != 0 }
>>
>> Is there a way currently where we can filter the array into two arrays
>> based on a condition?
>
> Well, you need a stable partition for this if you care about ordering
> (see
> https://github.com/apple/swift/blob/master/test/Prototypes/Algorithms.swift#L299)
> but then you can do 
>
> var parts = values
> let mid = values.stablePartition { $0 % 2 == 0 }
> let divisibleByTwo = parts.prefix(upTo: mid)
> let notDivisibleByTwo = parts.suffix(from: mid)
>
> Nate Cook has an enhancement to the result of stablyPartitioned in that
> prototype that would let you write:
>
>   let parts = values.stablyPartitioned { $0 % 2 == 0 }
>   let divisibleByTwo = parts.prefix(upTo: parts.partitionPoint)
>   let notDivisibleByTwo = parts.suffix(from: parts.partitionPoint)

Hmm, come to think of it, Nate, maybe there should also be a more
convenient way to get the two partitions from the result.

-- 
Dave

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

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

[Douglas Gregor via swift-evolution]

> On Jun 8, 2016, at 11:52 AM, Thorsten Seitz  wrote:
> 
>> 
>> Am 07.06.2016 um 07:55 schrieb LM > >:
>> 
>> 
>> 
>> On Jun 7, 2016, at 7:14 AM, Douglas Gregor > > wrote:
>> 
>>> 
 On Jun 6, 2016, at 10:08 PM, Thorsten Seitz > wrote:
 
 
 
 Am 06.06.2016 um 22:13 schrieb L Mihalkovic >:
 
> 
>> On Jun 6, 2016, at 9:34 PM, Douglas Gregor > > wrote:
>> 
>> 
>>> On Jun 6, 2016, at 12:12 PM, Thorsten Seitz >> > wrote:
>>> 
>>> 
>>> 
>>> Am 06.06.2016 um 18:51 schrieb Douglas Gregor >> >:
>>> 
 
> On Jun 5, 2016, at 3:24 AM, L. Mihalkovic via swift-evolution 
> > wrote:
> 
> The issue is to decide on the applicability scope. Thinking 'my 
> app/their stuff' is an illusion. To the compiler & runtime there is 
> only code split into modules, some in source code and others as 
> dylibs (.dll, .so, ...). Any extension based conditional refines a 
> protocol everywhere. What's hard is to compute the complete effects 
> of these changes predictably, reliably and fast. Because when we 
> consider 'but look, i have a single small extension', the 
> compiler must be ready to deal symetrically with anything we 
> throw at it. They can't start building 15 different ways the compute 
> the side effects based on many different scenarios because it will be 
> un-ruly code, and too complex to try to explain to us what we will 
> see.
> The circular redefinitions case is one of the knightmares that hides 
> in there... would mean having to assign priority to scopes, when 
> there is no scopes yet. At the moment, the binary conformance table 
> contains records for 3 types of conformances. First step would be to 
> add a new type to match extension based conformance, and then record 
> where it came from, and add some priority scheme to be able to 
> navigate any conformance chain(remember that the pb grows everytime 
> we decide 'oh cool, lets use a Padleft module rather than write my 
> own 15 lines to do it - see the recent pb with nodejs). Not a simple 
> task even with time, which they do not have now.
> 
> @core_team i know this is a coarse explanation, but hopefully at 
> least in the right ballpark.
 
 Roughly, yes. The specific problem regards answering the question 
 “where must the runtime look to determine whether a given type X 
 conforms to protocol P?”. Right now, the runtime conceptually needs to 
 look:
 
1) Into a list of known protocol conformances for the type X, 
 and
2) If X is a class type, the list of known protocol 
 conformances for the superclass of X (recursively)
 
 If we add the ability for a protocol extension to add a conformance to 
 another protocol, add to that:
 
3) Into the list of protocol extensions of other protocols Q 
 that provide conformance to P
>>> 
>>> So, the difference is that in the case
>>> 
>>> protocol P { ... }
>>> protocol Q : P { ... }
>>> struct X : Q {...}
>>> 
>>> X's list of known protocol conformances already contains Q and P, 
>>> whereas in the case
>>> 
>>> protocol P { ... }
>>> protocol Q { ... }
>>> struct X : Q {...}
>>> extension Q : P
>>> 
>>> X's list of known protocol conformances just contains Q and is not 
>>> extended by P as a result of the extension?
>>> Did I understand this right?
>> 
>> Yes, that’s correct.
>> 
>>> Is that (not being able to extend the conformance lists of all types as 
>>> a result of an extension) a restriction of having module boundaries?
>> 
>> Effectively, yes: you can’t simply enumerate all of the cases because 
>> some other module might add a new types/protocol 
>> extensions/conformances. It has to be dynamically discoverable.
> 
> yes… for each new module added to a known mix, the final conformances 
> list can be completely different. 
 
 But this is information known at compile time and does not have to be 
 determined at runtime. 
 An extension should be only effective in the module in which it is defined 
 and in modules using that module. All of these get to know 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Dave Abrahams via swift-evolution]

on Wed Jun 08 2016, Thorsten Seitz  wrote:

> Ah, thanks, I forgot!  I still consider this a bug, though (will have
> to read up again what the reasons are for that behavior).

Yes, but in the case of the issue we're discussing, the choices are:

1. Omit from the existential's API any protocol requirements that depend
   on Self or associated types, in which case it *can't* conform to
   itself because it doesn't fulfill the requirements.

2. Erase type relationships and trap at runtime when they don't line up.

Matthew has been arguing against #2, but you can't “fix the bug” without
it.

>
> -Thorsten
>
>> Am 08.06.2016 um 21:43 schrieb Austin Zheng :
>> 
>> It's not possible, even with Swift's current implementation of
>> existentials. A protocol type P isn't considered to conform to
>> itself, thus the following is rejected:
>> 
>> let a : MyProtocol = // ...
>> func myFunc(x: T) {
>>   // 
>> }
>> myFunc(a) // "Cannot invoke 'myFunc' with an argument list of type 
>> MyProtocol"
>> 
>> Changing how this works is probably worth a proposal by itself.
>> 
>> Austin
>> 
>> 
>> On Wed, Jun 8, 2016 at 12:34 PM, Thorsten Seitz via swift-evolution
>> > >
>> wrote:
>> 
>> > Am 08.06.2016 um 20:33 schrieb Dave Abrahams via swift-evolution
>> > > > >:
>> >
>> >
>> > on Tue Jun 07 2016, Matthew Johnson  wrote:
>> >
>> >>> On Jun 7, 2016, at 9:15 PM, Dave Abrahams
>> >>> > >>> >
>> >>> wrote:
>> >>>
>> >>>
>> >>> on Tue Jun 07 2016, Matthew Johnson > >>> > >>> >> wrote:
>> >>>
>> >>
>> > On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution
>> > > > >
>> > wrote:
>> >
>> >
>> > on Tue Jun 07 2016, Matthew Johnson
>> > > > >
>> > wrote:
>> >
>> 
>> >>> , but haven't realized
>> >>> that if you step around the type relationships encoded in Self
>> >>> requirements and associated types you end up with types that appear 
>> >>> to
>> >>> interoperate but in fact trap at runtime unless used in exactly the
>> >>> right way.
>> >>
>> >> Trap at runtime?  How so?  Generalized existentials should still be
>> >> type-safe.
>> >
>> > There are two choices when you erase static type relationships:
>> >
>> > 1. Acheive type-safety by trapping at runtime
>> >
>> > FloatingPoint(3.0 as Float) + FloatingPoint(3.0 as Double) // trap
>> >
>> > 2. Don't expose protocol requirements that involve these relationships,
>> > which would prevent the code above from compiling and prevent
>> > FloatingPoint from conforming to itself.
>> >
>> >> Or are you talking about the hypothetical types / behaviors people
>> >> think they want when they don’t fully understand what is happening...
>> >
>> > I don't know what you mean here.  I think generalized existentials will
>> > be nice to have, but I think most people will want them to do something
>> > they can't possibly do.
>> 
>>  Exactly.  What I meant is that people think they want that expression
>>  to compile because they don’t understand that the only thing it can do
>>  is trap.  I said “hypothetical” because producing a compile time error
>>  rather than a runtime trap is the only sane thing to do.  Your comment
>>  surprised me because I can’t imagine we would move forward in Swift
>>  with the approach of trapping.
>> >>>
>> >>> I would very much like to be able to create instances of “Collection
>> >>> where Element == Int” so we can throw away the wrappers in the stdlib.
>> >>> That will require some type mismatches to be caught at runtime via
>> >>> trapping.
>> >>
>> >> For invalid index because the existential accepts a type erased index?
>> >
>> > Exactly.
>> >
>> >> How do you decide where to draw the line here?  It feels like a very
>> >> slippery slope for a language where safety is a stated priority to
>> >> start adopting a strategy of runtime trapping for something as
>> >> fundamental as how you expose members on an existential.
>> >
>> > If you don't do this, the alternative is that “Collection where Element
>> > == Int” does not conform to Collection.  That's weird and not very
>> > useful.  You could expose all the methods that were on protocol
>> > extensions of Collection on this existential, unless they used
>> > associated types other than the element type.  But you couldn't pass the
>> > existential to a generic function like
>> >
>> >   func scrambled(_ c: C) -> [C.Element]
>> 
>> I don’t understand. Why couldn’t an existential be passed to that function?
>> 
>> 

Re: [swift-evolution] Proposal: Filter split extension on Sequence to return tuple of sequences that meet criteria and that do not

[Dave Abrahams via swift-evolution]

on Wed Jun 08 2016, gadiraju praneeth  wrote:

> Many times, I came across a scenario where I had to filter an array with a
> condition and filter the same array with opposite of that condition. For
> example:
>
> let values = [2, 4, 3, 5, 6, 9]
>
> let divisibleByTwo = values.filter { $0 % 2 == 0 }
> let notDivisibleByTwo = values.filter { $0 % 2 != 0 }
>
> Is there a way currently where we can filter the array into two arrays
> based on a condition?

Well, you need a stable partition for this if you care about ordering
(see
https://github.com/apple/swift/blob/master/test/Prototypes/Algorithms.swift#L299)
but then you can do 

var parts = values
let mid = values.stablePartition { $0 % 2 == 0 }
let divisibleByTwo = parts.prefix(upTo: mid)
let notDivisibleByTwo = parts.suffix(from: mid)

Nate Cook has an enhancement to the result of stablyPartitioned in that
prototype that would let you write:

  let parts = values.stablyPartitioned { $0 % 2 == 0 }
  let divisibleByTwo = parts.prefix(upTo: parts.partitionPoint)
  let notDivisibleByTwo = parts.suffix(from: parts.partitionPoint)


> If not how about something like a filterSplit function where we get a tuple
> of values:
>
> values.filterSplit { $0 % 2 == 0 } = ([2,4,6], [3,5,9])
>
> I have implemented this in our project and wanted to get your thoughts on it
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
Dave

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Thorsten Seitz via swift-evolution]

Ah, thanks, I forgot! 
I still consider this a bug, though (will have to read up again what the 
reasons are for that behavior).

-Thorsten


> Am 08.06.2016 um 21:43 schrieb Austin Zheng :
> 
> It's not possible, even with Swift's current implementation of existentials. 
> A protocol type P isn't considered to conform to itself, thus the following 
> is rejected:
> 
> let a : MyProtocol = // ...
> func myFunc(x: T) {
>   // 
> }
> myFunc(a) // "Cannot invoke 'myFunc' with an argument list of type MyProtocol"
> 
> Changing how this works is probably worth a proposal by itself.
> 
> Austin
> 
> 
> On Wed, Jun 8, 2016 at 12:34 PM, Thorsten Seitz via swift-evolution 
> > wrote:
> 
> > Am 08.06.2016 um 20:33 schrieb Dave Abrahams via swift-evolution 
> > >:
> >
> >
> > on Tue Jun 07 2016, Matthew Johnson  wrote:
> >
> >>> On Jun 7, 2016, at 9:15 PM, Dave Abrahams  >>> > wrote:
> >>>
> >>>
> >>> on Tue Jun 07 2016, Matthew Johnson  >>> >> 
> >>> wrote:
> >>>
> >>
> > On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution 
> > > wrote:
> >
> >
> > on Tue Jun 07 2016, Matthew Johnson  > > wrote:
> >
> 
> >>> , but haven't realized
> >>> that if you step around the type relationships encoded in Self
> >>> requirements and associated types you end up with types that appear to
> >>> interoperate but in fact trap at runtime unless used in exactly the
> >>> right way.
> >>
> >> Trap at runtime?  How so?  Generalized existentials should still be
> >> type-safe.
> >
> > There are two choices when you erase static type relationships:
> >
> > 1. Acheive type-safety by trapping at runtime
> >
> > FloatingPoint(3.0 as Float) + FloatingPoint(3.0 as Double) // trap
> >
> > 2. Don't expose protocol requirements that involve these relationships,
> > which would prevent the code above from compiling and prevent
> > FloatingPoint from conforming to itself.
> >
> >> Or are you talking about the hypothetical types / behaviors people
> >> think they want when they don’t fully understand what is happening...
> >
> > I don't know what you mean here.  I think generalized existentials will
> > be nice to have, but I think most people will want them to do something
> > they can't possibly do.
> 
>  Exactly.  What I meant is that people think they want that expression
>  to compile because they don’t understand that the only thing it can do
>  is trap.  I said “hypothetical” because producing a compile time error
>  rather than a runtime trap is the only sane thing to do.  Your comment
>  surprised me because I can’t imagine we would move forward in Swift
>  with the approach of trapping.
> >>>
> >>> I would very much like to be able to create instances of “Collection
> >>> where Element == Int” so we can throw away the wrappers in the stdlib.
> >>> That will require some type mismatches to be caught at runtime via
> >>> trapping.
> >>
> >> For invalid index because the existential accepts a type erased index?
> >
> > Exactly.
> >
> >> How do you decide where to draw the line here?  It feels like a very
> >> slippery slope for a language where safety is a stated priority to
> >> start adopting a strategy of runtime trapping for something as
> >> fundamental as how you expose members on an existential.
> >
> > If you don't do this, the alternative is that “Collection where Element
> > == Int” does not conform to Collection.  That's weird and not very
> > useful.  You could expose all the methods that were on protocol
> > extensions of Collection on this existential, unless they used
> > associated types other than the element type.  But you couldn't pass the
> > existential to a generic function like
> >
> >   func scrambled(_ c: C) -> [C.Element]
> 
> I don’t understand. Why couldn’t an existential be passed to that function?
> 
> -Thorsten
> 
> 
> 
> >
> >> IMO you should *have* to introduce unsafe behavior like that manually.
> >
> >  Collection where Element == Int & Index == *
> >
> > ?
> >
> >> Collection indices are already something that isn’t fully statically
> >> safe so I understand why you might want to allow this.
> >
> > By the same measure, so are Ints :-)
> >
> > The fact that a type's methods have preconditions does *not* make it
> > “statically unsafe.”
> >
> >> But I don’t think having the language's existentials do this
> >> automatically is the right approach.  Maybe there is another approach
> >> that could be used in targeted use cases where the less safe behavior
> 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Austin Zheng via swift-evolution]

It's not possible, even with Swift's current implementation of
existentials. A protocol type P isn't considered to conform to itself, thus
the following is rejected:

let a : MyProtocol = // ...
func myFunc(x: T) {
  // 
}
myFunc(a) // "Cannot invoke 'myFunc' with an argument list of type
MyProtocol"

Changing how this works is probably worth a proposal by itself.

Austin


On Wed, Jun 8, 2016 at 12:34 PM, Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > Am 08.06.2016 um 20:33 schrieb Dave Abrahams via swift-evolution <
> swift-evolution@swift.org>:
> >
> >
> > on Tue Jun 07 2016, Matthew Johnson  wrote:
> >
> >>> On Jun 7, 2016, at 9:15 PM, Dave Abrahams  wrote:
> >>>
> >>>
> >>> on Tue Jun 07 2016, Matthew Johnson  http://matthew-at-anandabits.com/>> wrote:
> >>>
> >>
> > On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> > on Tue Jun 07 2016, Matthew Johnson 
> wrote:
> >
> 
> >>> , but haven't realized
> >>> that if you step around the type relationships encoded in Self
> >>> requirements and associated types you end up with types that
> appear to
> >>> interoperate but in fact trap at runtime unless used in exactly the
> >>> right way.
> >>
> >> Trap at runtime?  How so?  Generalized existentials should still be
> >> type-safe.
> >
> > There are two choices when you erase static type relationships:
> >
> > 1. Acheive type-safety by trapping at runtime
> >
> > FloatingPoint(3.0 as Float) + FloatingPoint(3.0 as Double) // trap
> >
> > 2. Don't expose protocol requirements that involve these
> relationships,
> > which would prevent the code above from compiling and prevent
> > FloatingPoint from conforming to itself.
> >
> >> Or are you talking about the hypothetical types / behaviors people
> >> think they want when they don’t fully understand what is
> happening...
> >
> > I don't know what you mean here.  I think generalized existentials
> will
> > be nice to have, but I think most people will want them to do
> something
> > they can't possibly do.
> 
>  Exactly.  What I meant is that people think they want that expression
>  to compile because they don’t understand that the only thing it can do
>  is trap.  I said “hypothetical” because producing a compile time error
>  rather than a runtime trap is the only sane thing to do.  Your comment
>  surprised me because I can’t imagine we would move forward in Swift
>  with the approach of trapping.
> >>>
> >>> I would very much like to be able to create instances of “Collection
> >>> where Element == Int” so we can throw away the wrappers in the stdlib.
> >>> That will require some type mismatches to be caught at runtime via
> >>> trapping.
> >>
> >> For invalid index because the existential accepts a type erased index?
> >
> > Exactly.
> >
> >> How do you decide where to draw the line here?  It feels like a very
> >> slippery slope for a language where safety is a stated priority to
> >> start adopting a strategy of runtime trapping for something as
> >> fundamental as how you expose members on an existential.
> >
> > If you don't do this, the alternative is that “Collection where Element
> > == Int” does not conform to Collection.  That's weird and not very
> > useful.  You could expose all the methods that were on protocol
> > extensions of Collection on this existential, unless they used
> > associated types other than the element type.  But you couldn't pass the
> > existential to a generic function like
> >
> >   func scrambled(_ c: C) -> [C.Element]
>
> I don’t understand. Why couldn’t an existential be passed to that function?
>
> -Thorsten
>
>
>
> >
> >> IMO you should *have* to introduce unsafe behavior like that manually.
> >
> >  Collection where Element == Int & Index == *
> >
> > ?
> >
> >> Collection indices are already something that isn’t fully statically
> >> safe so I understand why you might want to allow this.
> >
> > By the same measure, so are Ints :-)
> >
> > The fact that a type's methods have preconditions does *not* make it
> > “statically unsafe.”
> >
> >> But I don’t think having the language's existentials do this
> >> automatically is the right approach.  Maybe there is another approach
> >> that could be used in targeted use cases where the less safe behavior
> >> makes sense and is carefully designed.
> >
> > Whether it makes sense or not really depends on the use-cases.  There's
> > little point in generalizing existentials if the result isn't very
> useful.
> > The way to find out is to take a look at the examples we currently have
> > of protocols with associated types or Self requirements and consider
> > what you'd be able to do with their existentials if type relationships
> > couldn't be erased.
> >
> > We have known use-cases, 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Thorsten Seitz via swift-evolution]

> Am 08.06.2016 um 20:33 schrieb Dave Abrahams via swift-evolution 
> :
> 
> 
> on Tue Jun 07 2016, Matthew Johnson  wrote:
> 
>>> On Jun 7, 2016, at 9:15 PM, Dave Abrahams  wrote:
>>> 
>>> 
>>> on Tue Jun 07 2016, Matthew Johnson >> > wrote:
>>> 
>> 
> On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Tue Jun 07 2016, Matthew Johnson  wrote:
> 
 
>>> , but haven't realized
>>> that if you step around the type relationships encoded in Self
>>> requirements and associated types you end up with types that appear to
>>> interoperate but in fact trap at runtime unless used in exactly the
>>> right way.
>> 
>> Trap at runtime?  How so?  Generalized existentials should still be
>> type-safe.  
> 
> There are two choices when you erase static type relationships:
> 
> 1. Acheive type-safety by trapping at runtime
> 
> FloatingPoint(3.0 as Float) + FloatingPoint(3.0 as Double) // trap
> 
> 2. Don't expose protocol requirements that involve these relationships,
> which would prevent the code above from compiling and prevent
> FloatingPoint from conforming to itself.
> 
>> Or are you talking about the hypothetical types / behaviors people
>> think they want when they don’t fully understand what is happening...
> 
> I don't know what you mean here.  I think generalized existentials will
> be nice to have, but I think most people will want them to do something
> they can't possibly do.
 
 Exactly.  What I meant is that people think they want that expression
 to compile because they don’t understand that the only thing it can do
 is trap.  I said “hypothetical” because producing a compile time error
 rather than a runtime trap is the only sane thing to do.  Your comment
 surprised me because I can’t imagine we would move forward in Swift
 with the approach of trapping.
>>> 
>>> I would very much like to be able to create instances of “Collection
>>> where Element == Int” so we can throw away the wrappers in the stdlib.
>>> That will require some type mismatches to be caught at runtime via
>>> trapping.
>> 
>> For invalid index because the existential accepts a type erased index?
> 
> Exactly.
> 
>> How do you decide where to draw the line here?  It feels like a very
>> slippery slope for a language where safety is a stated priority to
>> start adopting a strategy of runtime trapping for something as
>> fundamental as how you expose members on an existential.
> 
> If you don't do this, the alternative is that “Collection where Element
> == Int” does not conform to Collection.  That's weird and not very
> useful.  You could expose all the methods that were on protocol
> extensions of Collection on this existential, unless they used
> associated types other than the element type.  But you couldn't pass the
> existential to a generic function like
> 
>   func scrambled(_ c: C) -> [C.Element]

I don’t understand. Why couldn’t an existential be passed to that function?

-Thorsten



> 
>> IMO you should *have* to introduce unsafe behavior like that manually.
> 
>  Collection where Element == Int & Index == *
> 
> ?
> 
>> Collection indices are already something that isn’t fully statically
>> safe so I understand why you might want to allow this.  
> 
> By the same measure, so are Ints :-)
> 
> The fact that a type's methods have preconditions does *not* make it
> “statically unsafe.”
> 
>> But I don’t think having the language's existentials do this
>> automatically is the right approach.  Maybe there is another approach
>> that could be used in targeted use cases where the less safe behavior
>> makes sense and is carefully designed.
> 
> Whether it makes sense or not really depends on the use-cases.  There's
> little point in generalizing existentials if the result isn't very useful.
> The way to find out is to take a look at the examples we currently have
> of protocols with associated types or Self requirements and consider
> what you'd be able to do with their existentials if type relationships
> couldn't be erased.  
> 
> We have known use-cases, currently emulated in the standard library, for
> existentials with erased type relationships.  *If* these represent the
> predominant use cases for something like generalized existentials, it
> seems to me that the language feature should support that.  Note: I have
> not seen anyone build an emulation of the other kind of generalized
> existential.  My theory: there's a good reason for that :-).
> 
> -- 
> Dave
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list

Re: [swift-evolution] Add a while clause to for loops

[Xiaodi Wu via swift-evolution]

On Wed, Jun 8, 2016 at 2:31 PM, Erica Sadun  wrote:

>
> > On Jun 8, 2016, at 1:07 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> > I should add, on the topic of removing `where`, there would be a higher
> threshold for a successful proposal and I would have to convince people
> that the `where` clause is actually harmful. I do wonder if I could succeed
> in that endeavor. But when it comes to adding something like `while`,
> you've yet to convince me it offers more than just stylistic choice. IMO,
> that is insufficient for a proposal as consequential as adding syntax to
> the language itself (a much more serious addition than changing API in the
> stdlib, for example).
>
> I think it would be valuable to defer this discussion until after WWDC to
> see how SE-0099 does. The core team's response to while exfoliation will
> greatly affect both how this suggestion goes.
>

Probably wise.


>
> (As is, if this moves forward, I'd say go with either where or while but
> not both, or eliminate while entirely.)
>
> --- E
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Add a while clause to for loops

[Erica Sadun via swift-evolution]

> On Jun 8, 2016, at 1:07 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> I should add, on the topic of removing `where`, there would be a higher 
> threshold for a successful proposal and I would have to convince people that 
> the `where` clause is actually harmful. I do wonder if I could succeed in 
> that endeavor. But when it comes to adding something like `while`, you've yet 
> to convince me it offers more than just stylistic choice. IMO, that is 
> insufficient for a proposal as consequential as adding syntax to the language 
> itself (a much more serious addition than changing API in the stdlib, for 
> example).

I think it would be valuable to defer this discussion until after WWDC to see 
how SE-0099 does. The core team's response to while exfoliation will greatly 
affect both how this suggestion goes.

(As is, if this moves forward, I'd say go with either where or while but not 
both, or eliminate while entirely.)

--- E


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

Re: [swift-evolution] extend trailing closure rule

[Rimantas Liubertas via swift-evolution]

>  
> That's ugly. I'd rather write:
>  
> UIView.animate(withDuration:0.4) {
> self.v.backgroundColor = UIColor.red()
> }
>  
> What stops me is that `animations:` is not eligible for trailing closure 
> syntax, because it isn't the last parameter — `completion:` is.  

Actually you can. UIView has three signatures ‘animateWithduration’:

class func animateWithDuration(_ duration: NSTimeInterval 
(file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_DataTypes/index.html#//apple_ref/swift/tdef/c:@T@NSTimeInterval),
animations animations: () -> Void 
(file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Swift/Reference/Swift_StandardLibrary_TypeAliases/index.html#//apple_ref/swift/tdef/s:s4Void))

class func animateWithDuration(_ duration: NSTimeInterval 
(file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_DataTypes/index.html#//apple_ref/swift/tdef/c:@T@NSTimeInterval),
animations animations: () -> Void 
(file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Swift/Reference/Swift_StandardLibrary_TypeAliases/index.html#//apple_ref/swift/tdef/s:s4Void),
completion completion: ((Bool 
(file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Swift/Reference/Swift_Bool_Structure/index.html#//apple_ref/swift/struct/s:Sb))
 -> Void 
(file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Swift/Reference/Swift_StandardLibrary_TypeAliases/index.html#//apple_ref/swift/tdef/s:s4Void))?)

class func animateWithDuration(_ duration: NSTimeInterval 
(file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_DataTypes/index.html#//apple_ref/swift/tdef/c:@T@NSTimeInterval),
 delay delay: NSTimeInterval 
(file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_DataTypes/index.html#//apple_ref/swift/tdef/c:@T@NSTimeInterval),
   options options: UIViewAnimationOptions 
(file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/UIKit/Reference/UIView_Class/index.html#//apple_ref/swift/struct/c:@E@UIViewAnimationOptions),
animations animations: () -> Void 
(file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Swift/Reference/Swift_StandardLibrary_TypeAliases/index.html#//apple_ref/swift/tdef/s:s4Void),
completion completion: ((Bool 
(file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Swift/Reference/Swift_Bool_Structure/index.html#//apple_ref/swift/struct/s:Sb))
 -> Void 
(file:///Users/rimliu/Library/Developer/Shared/Documentation/DocSets/com.apple.adc.documentation.iOS.docset/Contents/Resources/Documents/documentation/Swift/Reference/Swift_StandardLibrary_TypeAliases/index.html#//apple_ref/swift/tdef/s:s4Void))?)

so your version is valid.


Best regards,
Rimantas
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Add a while clause to for loops

[Hignite, Jamie via swift-evolution]

+1 as well


Thanks!

Jamie


On 6/7/16, 7:20 AM, "swift-evolution-boun...@swift.org on behalf of
Vladimir.S via swift-evolution"  wrote:


>My +1 to the proposal and for Charlie's opinion. I believe `while` in
>`for` 
>loop would be very handy and helpful in some situations, it is a pair for
>existed `where`, its meaning is obvious, and its existence can't depend
>on 
>existence of any method in collections. I'd like to see a formal proposal
>for this feature.
>
>On 07.06.2016 8:18, Charlie Monroe via swift-evolution wrote:
>> I strongly disagree.
>>
>> Exchanging
>>
>> for result in results where result.value != .Warning while result.value
>>!=
>> .Error {
>> /// ...
>> }
>>
>> for either
>>
>> for result in results.filter({ $0.value != .Warning }).prefix(while: {
>> $0.value != .Error })) {
>> /// ...
>> }
>>
>> or
>>
>> for result in results {
>> if result.value == .Warning { continue }
>> if result.value == .Error { break }
>>
>> /// ...
>> }
>>
>> Seems like an absolute step back. Not to mention filter(_:) doesn't
>>return
>> a lazy collection, but will recreate it, while the `where` will do
>> on-the-fly check.
>>
>>> On Jun 7, 2016, at 1:34 AM, Xiaodi Wu via swift-evolution
>>> > wrote:
>>>
>>> Personally, given this discussion and the one about `where` in if and
>>> while statements, I would not be opposed to elimination of `where` in
>>> control statements altogether.
>>>
>>> My reasoning would be that words like filter and prefix unambiguously
>>> indicate what happens to elements of a sequence for which the predicate
>>> returns false, whereas words like where and while are ambiguous.
>>>
>>> On Mon, Jun 6, 2016 at 17:52 Tim Vermeulen >> > wrote:
>>>
>>> I didn¹t mean we should really get rid of the `where` clause, it¹s
>>> great. I guess the point I was trying to make is that we can use a
>>> `where` clause with a `for` loop in Swift, despite the existence of
>>> the `filter` method. So despite `prefix(while:)` in Swift 3, there
>>> might be room for a `while` clause. I think it makes the code a lot
>>> more readable, much like how `where` can make a `for` loop a lot
>>>more
>>> readable than using `filter`.
>>>
>>> > The burden of proof for adding new features is different from
>>>that
>>> for taking away existing features.
>>> >
>>> > If a feature doesn't yet exist, a successful proposal will show
>>>how
>>> it provides additional and non-trivial utility. If a feature
>>>already
>>> exists, a successful proposal to remove it will show how it is
>>> harmful to the language or contrary to the direction in which it is
>>> evolving.
>>> >
>>> > On Mon, Jun 6, 2016 at 15:38 Tim Vermeulen>> (mailto:tvermeu...@me.com
>>> )>wrote:
>>> > > The functionality of the `where` clause in `for` loops also
>>> already can be mimicked using `filter`. Wouldn¹t we have to get
>>>ride
>>> of the `where` clause by that logic?
>>> > >
>>> > > >The functionality being asked for here is already accepted for
>>> inclusion to Swift as a method on Sequence named `prefix(while:)`
>>> (SE-0045):
>>> > > >
>>> > > >`for element in array.prefix(while: { someCondition($0) }) {
>>>... }`
>>> > > >On Mon, Jun 6, 2016 at 14:31 T.J. Usiyan via
>>> swift-evolution>> (mailto:swift-evolution@swift.org
>>> 
>>>)(mailto:swift-evolution@swift.org
>>> )>wrote:
>>> > > >>(As I said, I can live with `while`. I am simply presenting a
>>> potential point of confusion.)
>>> > > >>You aren't evaluating the statements in the loop 'while' the
>>> condition isn't met. The first time that the condition isn't met,
>>> evaluation of the loop stops. I get that this is technically true
>>>for
>>> the `while` construct but I suggest that the only reason that it
>>> works there is that 'stopping the first time that the condition
>>>isn't
>>> met' *is* the construct. Here, we have a loop that we execute for
>>> each thing and we're tacking on/intermingling the `while`
>>>construct.
>>> > > >>
>>> > > >>
>>> > > >>
>>> > > >>On Mon, Jun 6, 2016 at 2:19 PM, Thorsten
>>> Seitz>> (mailto:tseit...@icloud.com
>>> )(mailto:tseit...@icloud.com
>>> )>wrote:
>>> > > >>>
>>> > > Am 06.06.2016 um 19:43 schrieb Tim Vermeulen via
>>> swift-evolution>> (mailto:swift-evolution@swift.org
>>> 

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[J. Charles M. N. via swift-evolution]

This confused me at the beginning.

But doesn't Int! In parameter type means the function is awaiting an unwrapped 
value so the user should ensure that it data parameter is available, valid, and 
unwrapped?

--
J. Charles 

> Le 8 juin 2016 à 13:30, Spromicky via swift-evolution 
>  a écrit :
> 
> Hello, everyone!
> 
> I wanna propose to you to remove force unwrapping in fuction signature for 
> swift code. That no sense in clear swift code. If we wanna use some optional 
> value as function param, that is not optional, we must unwrap it before 
> function call.
> People who new in swift look at how they old Obj-C code (without nullability 
> modifiers) translate in to swift: 
> 
> Obj-C:
> - (void)foo:(NSInteger)bar {
>//...
> }
> 
> Swift transaliton:
> func foo(bar: Int!) {
>//...
> }
> 
> And think that force unwrapping in signature is good practice. And start 
> write functions in clear swift code like this:
> 
> func newFoo(bar: Int!) {
>//...
> }
> 
> and use it like this:
> 
> let bar: Int? = 1
> newFoo(bar)
> 
> And it really work, and they does not think that this can crash in case if 
> `bar` will be `nil`.
> But in clear swift we wanna work with parametrs in function that clearly or 
> optional, or not.
> 
> func newFoo(bar: Int) {
>//...
> }
> 
> or 
> 
> func newFoo(bar: Int?) {
>//...
> }
> 
> When we write a new function we know what we need in this case and use 
> optional params or not. 
> 
> So my proposal is remove force unwrapping(`!`) from function signatures, 
> cause it have no sense, and that confuse new users.
> ___
> 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-0041: Updating Protocol Naming Conventions for Conversions

[Dave Abrahams via swift-evolution]

on Wed May 18 2016, Brent Royal-Gordon  wrote:

>>> If we're doing this, I wonder if category 1 shouldn't just be
>> `Convertible`. This would preserve our `LiteralConvertible`
>> protocols with the same names (which, consistency issues aside, seem
>> perfectly cromulent), while shifting the `StringConvertible`
>> protocols over to the `Representable` category.
>> 
>> Do you really think 'Convertible' is more clear than 'Initializable'?
>
> I don't think `Convertible` is clearer than `Initializable`, but I
> think it rolls off the tongue better, is easier to spell, is more
> compatible with non-initializer implementations, and in general wins
> on a lot of squishy, subjective, hard-to-define axes.
>
> Subjectively, I've noticed that a lot of people *don't* think of
> things like `Double(myFloat)` as being initializers; they think of
> them as conversions. To those people, `Convertible` is probably the
> right name.

Convertible also tends to implies some semantics, whereas Initializable
just describes a valid syntax.  Protocols that merely describe what
you're allowed to write in code but nothing about its meaning are
usually a bad idea.

-- 
Dave

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

Re: [swift-evolution] Add a while clause to for loops

[Xiaodi Wu via swift-evolution]

On Wed, Jun 8, 2016 at 2:01 PM, Xiaodi Wu  wrote:

> On Wed, Jun 8, 2016 at 1:58 PM, Tim Vermeulen  wrote:
>
>> That’s why I said “potentially less elegant”, some people might prefer
>> `where` over `guard`. This proposal would give them the choice (in very
>> specific situations) to use `where` rather than `guard` if they don’t want
>> to sacrifice performance.
>>
>
> Since Swift strives to be an opinionated language without dialects, there
> shouldn't be more "choice" but rather one general solution, IMO. Since
> `guard` doesn't sacrifice performance and is the most general, I would
> oppose adding the option of `while` to offer more choice.
>

I should add, on the topic of removing `where`, there would be a higher
threshold for a successful proposal and I would have to convince people
that the `where` clause is actually harmful. I do wonder if I could succeed
in that endeavor. But when it comes to adding something like `while`,
you've yet to convince me it offers more than just stylistic choice. IMO,
that is insufficient for a proposal as consequential as adding syntax to
the language itself (a much more serious addition than changing API in the
stdlib, for example).


>
>
>>
>> > On Wed, Jun 8, 2016 at 1:35 PM, Tim Vermeulen via swift-evolution<
>> swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
>> > > This is a really strong argument in my opinion. If we don’t add a
>> `while` to for loops, then in some situations we will have to rewrite a
>> `where` clause to something potentially less elegant, given that we don’t
>> want to give up performance.
>> > I disagree. I argue that what you call "less elegant", namely if (or
>> guard) inside the loop, is the most elegant solution.
>> >
>> > >
>> > > >IMO `.prefix` is just not the equal alternative for as proposed
>> `while` :
>> > > >in case of 'while' expression `number<4_000_000` will be calculated
>> > > >*only* for those who `number % 2 == 0`. In case of `prefix` - the
>> > > >expression will be processed for each `number` and only after this
>> filtered
>> > > >by `number % 2`. Let's assume we need to check for some
>> > > >veryExpensiveTest(number):
>> > > >
>> > > >for number in fibonacci where number % 2 == 0 while
>> > > >veryExpensiveTest(number) {}
>> > > >
>> > > >let numbers = fibonacci.prefix { veryExpensiveTest($0) }
>> > > >for number in numbers where number % 2 == 0 {}
>> > > >
>> > > >So, `while` for `for` loops just can't be always replaced with
>> `prefix`
>> > > >
>> > > >On 08.06.2016 2:02, Xiaodi Wu via swift-evolution wrote:
>> > > >>On Tue, Jun 7, 2016 at 5:11 PM, Tim Vermeulen> (mailto:tvermeu...@me.com)
>> > > >>>wrote:
>> > > >>
>> > > >>I’ve been thinking about this for a bit now, and I think it would
>> make
>> > > >>most sense to evaluate these clauses from left to right. However,
>> cases
>> > > >>where the order matters are very uncommon, and I would rather have
>> the
>> > > >>power to choose which clause is evaluated first than to have a
>> forced
>> > > >>default order. Either way I don’t see this as a reason not to allow
>> > > >>combining the two clauses because IMO it can lead to some very clean
>> > > >>code. For instance, say we want to loop through all even fibonacci
>> > > >>numbers below 4 million (see problem #2 from project euler), we
>> could
>> > > >>do this:
>> > > >>
>> > > >>`for number in fibonacci where number % 2 == 0 while
>> number<4_000_000
>> > > >>{ }`
>> > > >>
>> > > >>
>> > > >>This statement looks like spaghetti to me. I would not at all
>> support
>> > > >>extending the language to permit it. Do you really think it's more
>> readable
>> > > >>than going step-by-step?
>> > > >>
>> > > >>```
>> > > >>let numbers = fibonacci.prefix { $0<4_000_000 }
>> > > >>for number in numbers where number % 2 == 0 {
>> > > >>// ...
>> > > >>}
>> > > >>```
>> > > >>
>> > > >>or just:
>> > > >>
>> > > >>```
>> > > >>let numbers = fibonacci.prefix { $0<4_000_000 }
>> > > >>let evens = numbers.filter { $0 % 2 == 0 }
>> > > >>for number in evens {
>> > > >>// ...
>> > > >>}
>> > > >>```
>> > > >>
>> > > >>
>> > > >>I could have ordered the two clauses in any way I want. If combining
>> > > >>the clauses weren’t allowed, I’d have to put (at least) one of them
>> > > >>inside the block, which would be a (minor) pain.
>> > > >>
>> > > >>I don’t currently have a very strong opinion about the order of
>> > > >>evaluation, so I might be convinced otherwise. But combining the two
>> > > >>clauses is so powerful that I don’t think it’s worth to get rid of
>> just
>> > > >>because of an edge case.
>> > > >>
>> > > >>>It may be workable if you can have only one or the other, but
>> mixing and matching them as proposed above would be a world of hurt:
>> > > >>>
>> > > >>>```
>> > > >>>for foo in bar where condition1 while condition2 { ... }
>> > > >>>```
>> > > >>>
>> > > >>>If condition1 and condition2 both evaluate to 

[swift-evolution] [Draft] Allow multiple conformances to the same protocol

[Антон Жилин via swift-evolution]

==Motivation==

protocol From {
associatedtype FromType
init(_ value: FromType)
}

The problem is, one type cannot implement multiple From "conversions".

==Proposed solution==

Allow specifying all associated types using generic syntax.

extension Int : From { }
extension Int : From { }

This is only allowed in conformance declarations.

==Future directions==

We can replace all *Convertible protocols with From and Into, which will be
defined similarly to Rust.

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