Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Matthew Johnson via swift-evolution]

> On Jan 4, 2016, at 12:40 PM, Douglas Gregor  wrote:
> 
>> 
>> On Jan 4, 2016, at 10:30 AM, Matthew Johnson > > wrote:
>> 
>>> 
>>> On Jan 4, 2016, at 12:21 PM, Douglas Gregor via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Jan 3, 2016, at 4:19 PM, David Waite > wrote:
 
 This would be wonderful - is it something that could happen in the Swift 3 
 timeframe?
>>> 
>>> I hesitate to say “yes” here. I think it fits with the goals of Swift 3, 
>>> but my main concern is that there isn’t enough engineering bandwidth to 
>>> implement it for Swift 3.
>>> 
 Is it something that myself or someone else could work on a formal 
 proposal for?
>>> 
>>> Yes, absolutely. This is a case where I think it’s useful to design what we 
>>> want, even if we cannot fit the implementation into the Swift 3 schedule. 
>>> It’s also a case where the compiler has a lot of the pieces already 
>>> implemented (with some runtime bits landing soon), so the implementation 
>>> should not be *that* hard and will likely not require architectural changes.
>> 
>> Interesting.  I was under the impression the core team was taking on the 
>> generics features. 
> 
> We are, and lots of them. I doubt we can handle another.
> 
>>  I am also very interested in helping to accelerate the process if that is 
>> possible (whether that means Swift 3 or not).
>> 
>> Are you thinking specifically about unbound existentials like in your 
>> Equatable example or also partly / fully bound existentials such as 
>> SequenceType?
> 
> I was thinking mostly about the former. However, the latter is also a 
> highly-requested feature [*] that complements this one, and I think it’s 
> reasonable to discuss both together.
> 
>   - Doug
> 
> [*] And is often the underlying reason why developers ask for parameterized 
> protocols.

Agree.  The other primary motivation I know of for that request is something 
like ConvertibleTo where you multiple conformances would be possible.  

I am familiar with the reasons why Swift is avoiding that path. :)

> 
> 
>> 
>>> 
>>> - Doug
>>> 
 
 -DW
 
> On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution 
> > wrote:
> 
> 
>> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
>> > wrote:
>> 
>> Introduction of interfaces will clean up the current blend of static and 
>> dynamic protocols, and solve at least three popular issues.
>> Please see:
>> https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
>>  
>> 
> I am *completely* against this proposal.
> 
> Fundamentally, you're trying to address the limitation that protocols 
> with Self or associated type requirements can't be existential. But it's 
> just a limitation that isn't (conceptually) that hard to fix: the primary 
> operation you need to work with an existing of such a protocol is to 
> "open" a value of existential type, giving a name to the dynamic type it 
> stores. Let's invent one:
> 
>   func eq(x: Equatable, y: Equatable) -> Bool {
> // give the name T to the dynamic type stored in xT
> let xT = open x as T
> // is y also storing a T?
> guard let yT = y as? T else { return false }
> // check whether the Ts are equal
> return xT == yT
>   }
> 
> Ignore the syntax: semantically, we've gone from a "dynamic" existential 
> thing back to something more "static", just by giving a name to the type. 
> Swift generics aren't really even static in any sense: what the do is 
> give names to the types of values so one can establish relationships 
> among different values. "open..as" would do that for existentials. 
> 
> Note that ether Swift compilers AST and SIL both have "open existential" 
> operations that do this internally. They have no spelling in Swift code, 
> but they are useful to describe operations on existentials. At present, 
> they cannot be formed when the existential involves a protocol with Self 
> or associated type requirements, but that's a limitation that isn't hard 
> to address. 
> 
> As for your concerns about knowing when one can dynamically override and 
> when one cannot...  There are issues here that need to be addressed. They 
> aren't significant enough to warrant such a drastic change, and may not 
> even require language changes at all. 
> 
>   - Doug
> 
> 
> 
> 

Re: [swift-evolution] Proposal: named invariants for variable declarations

[Howard Lovatt via swift-evolution]

Alternatively the Properties Behaviour syntax proposal could be applied to any 
declaration, assuming that it is accepted. 


> On 5 Jan 2016, at 4:18 AM, Amir Michail via swift-evolution 
>  wrote:
> 
> Examples:
> 
> invariant vectorIndex(v:Int) { return 0..<3 ~= v }
> 
> var i:Int,vectorIndex: = 2
> i = 3 // run-time error
> 
> invariant positive(v:Int) { return v > 0 }
> invariant odd(v:Int) { return v % 2 == 1 }
> 
> var x:Int, positive, odd = 5
> 
> x = 2 // run-time error
> 
> func f(z:Int, positive, odd) {
> …
> }
> 
> f(-3) // run-time error
> 
> 
> 
> 
> 
> 
> ___
> 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] Trial balloon: Ensure that String always contains valid Unicode

[Dmitri Gribenko via swift-evolution]

On Mon, Jan 4, 2016 at 9:37 PM, Kevin Ballard via swift-evolution <
swift-evolution@swift.org> wrote:

> I agree in principle that it would be great if String could enforce that
> it's always valid.
>
> But unfortunately, in practice, there's no way to do that without making
> it expensive to bridge from Obj-C. Because, as you've demonstrated, you can
> create NSStrings that contain things that aren't actually valid unicode
> sequences, every single bridge from an NSString to a String would have to
> be checked for validity. Not only that, but it's not clear what the
> behavior would be if an invalid string is found, since these bridges are
> unconditional - would Swift panic? Would it silently replace the invalid
> sequence with U+FFFD? Or something else entirely? But the question doesn't
> really matter, because turning these bridges from O(1) into O(N) would be
> an unacceptable performance penalty anyway.
>

Currently String replaces invalid sequences with U+FFFD lazily during
access, but there are corner cases related to Objective-C bridging that can
still leak invalid Unicode.

Dmitri

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

Re: [swift-evolution] ternary operator ?: suggestion

[Howard Lovatt via swift-evolution]

-1 for me. None of it looks or feels like Swift, more like Haskell. I would 
prefer a library solution for now and remove ?: from the language and add a 
which into the standard library and see how that goes and if there is need for 
more.

Sorry,

Howard.

> On 5 Jan 2016, at 7:24 AM, Paul Ossenbruggen via swift-evolution 
>  wrote:
> 
> Any feedback on this? I am rethinking the idea of #( because of the # prior 
> usage as a preprocessor directive, but like how it stands out and has a 
> meaning.  If no feedback, does it make sense to update my proposal with these 
> ideas? Or does this feel like the wrong direction. 
> 
> 
>> On Dec 30, 2015, at 8:52 AM, Paul Ossenbruggen > > wrote:
>> 
>> Some more ideas, this moves away from the notion that we should make it look 
>> really close to the ternary but keeps all the benefits of the ternary and 
>> improves upon it. Since I have been suggesting a breaking change, it is a 
>> good time to rethink it a bit. With this idea a horizontal line 
>> (double-dash) separates the control value from the choices, the vertical 
>> line (bar) indicates none of the above. 
>> 
>> Rather than use the ?( as I have suggested in the past, I think #( works 
>> here, where you can think of it as a numerical index. The advantage of this 
>> is, it stands out better and leaves ? for optionals only. This works well 
>> with the list form. In the enum case the index is the enum key. I can see 
>> that this however may be a problem because # is used for preprocessor like 
>> directives. I am suggesting though just the #( sequence is treated 
>> differently. Or the ?( is fine with me as well.
>> 
>> I have gone through a lot of options, some others I looked at are !( which 
>> could be read as "match stick” paren, where the word “match” matches a case, 
>> I am pretty sure that would not be considered any better than ?( because it 
>> is used for optionals. Another is “witch hat paren” ^( which can be read as 
>> “which”.  This might create a parse problem with "power of" though, which 
>> maybe using ^[ (hat square bracket) could resolve that but not sure if that 
>> would create other problems. Some other choices would be &(  and @( but did 
>> not choose them because  they don’t have meaning to me but they do have the 
>> advantage of standing out like the #(. 
>> 
>> let fa = #(truth -- 1 | 0) // boolean case. 
>> let fb = #(pickOne -- "A", "B", "C", "D", "E", "F", "G" | "Z”) // list form, 
>> pick index, zero based. 
>> let fc = #(color -- .Red: 0xFF, .Green: 0x00FF00, .Blue: 0xFF | 
>> 0xFF) // enum form.
>> let fd = #(color -- .Red:0xFF, 
>>  .Green:  0x00FF00, 
>>  .Blue:   0xFF 
>>  | 0xFF) // enum multiline, default: can be used here if 
>> preferred.
>> let fe = #(color -- .Red:0xFF, 
>>  .Green:  0x00FF00, 
>>  .Blue:   0xFF) // if all cases handled, the last bar is 
>> optional
>> 
>> This visually kind of represents what is going on. Horizontal-line directs 
>> eye to one of the normal choices. Vertical-line says none found stop looking 
>> and do the otherwise choice. Kind of like a train switch. 
>> 
>> The strong feedback was that a replacement has to be usable in places where 
>> a ternary could be used. So it needs to work on a single line (and 
>> multiline) and needs to be compact. By having a compact, “else" that is 
>> possible on a single line. 
>> 
>> Comparisons to ternary and other approaches:
>> • It is very concise like ternary and can fit in places that a ternary does.
>> • The horizontal line serves to provide a place to align the choices to pick 
>> from, not as necessary with ternary. 
>> • The vertical line stops the eye and indicates this is the “else” or 
>> “default” choice, the colon does that in ternary but the bar stands out more.
>> • The parens group the expression, in a way that the ternary does not. With 
>> a ternary it is not until you get to the question mark and the barely 
>> visible colon that you realize it is a ternary. 
>> • The #( indicates immediately that the expression has started unlike a 
>> ternary. 
>> • #( clearly show beginning and end of the construct so that it is 
>> immediately identifiable unlike ternary.
>> • Makes quick one line conversions easily achievable just as ternary can but 
>> allowing more than just boolean.  
>> • The “else” choice is always last and is compactly represented with 
>> vertical bar like ternary but more visible. This also differs from the 
>> switch statement form, in that it is much more compact than “default:"
>> • The dash does not create a double colon for enum case as was mentioned as 
>> a problem in previous designs.
>> • All data types for the control are handled the same way, like ternary but 
>> now supports more than boolean, it supports any enumerable tope.
>> • The list form looks like a 

Re: [swift-evolution] Keyword Discoverability

[Howard Lovatt via swift-evolution]

I would prefer library functions rather than language constructs, basically if 
in doubt but it in the library rather than a language construct. Library 
functions are much easier to discover and document.

> On 4 Jan 2016, at 9:43 PM, John Joyce via swift-evolution 
>  wrote:
> 
> Hello all
> 
> It feels like Swift has some risk of going the direction of C++ at times. By 
> that I mean complexity creep. 
> Increasingly nuanced scoping results in more keywords and constructs. 
> Useful and good but increasingly complex and steepening learning curve. 
> 
> I'd like to kick off discussion of ways to increase discoverability. 
> 
> One thought is tools.  
> In thinking about contextual completions like Xcode's Open Quickly or the 
> universal field thing in Sublime, it sure seems like some way to invoke a 
> list of keywords and constructs available-in-the-current-scope would be 
> helpful. 
> 
> Thoughts ?
> 
> ___
> 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] Swift 2.2: #if swift language version

[Drew Crawford via swift-evolution]

The swift package manager is currently considering its own define 
,
 so it's now the second official project that could benefit from this syntax.

David, any interest in writing this up?

> On Jan 3, 2016, at 4:48 AM, Goffredo Marocchi  wrote:
> 
> +1 from me as well, supporting conditional compilation when the two versions 
> of foundation differ and may differ for the foreseeable future seems a must 
> on this end.
> 
> Sent from my iPhone
> 
> On 3 Jan 2016, at 10:12, Drew Crawford via swift-evolution 
> > wrote:
> 
>>> If we are going to support something like this, I’d rather see it be 
>>> something everyone could leverage as there are many use cases for this 
>>> feature:
>>> 
>>> #if available("package-name", "1.2.*")
>>> #endif
>> 
>> Big +1.
>> 
>> I've asked specifically to get some kind of conditional compilation on 
>> corelibs-foundation 
>> 
>>  being used.  corelibs-founcation is currently incompatible with Darwin 
>> Foundation, and so it is impractical to make a single codebase build for 
>> both.
>> 
>> But building the same application against both Foundations and spotting 
>> differences is one of the important ways we're going to spot bugs.
>> 
>> So I think the code quality of Foundation ultimately hinges on getting some 
>> feature like this in the language.
>> 
>> ___
>> 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] Trial balloon: Ensure that String always contains valid Unicode

[Kevin Ballard via swift-evolution]

I agree in principle that it would be great if String could enforce that
it's always valid.

But unfortunately, in practice, there's no way to do that without making
it expensive to bridge from Obj-C. Because, as you've demonstrated, you
can create NSStrings that contain things that aren't actually valid
unicode sequences, every single bridge from an NSString to a String
would have to be checked for validity. Not only that, but it's not clear
what the behavior would be if an invalid string is found, since these
bridges are unconditional - would Swift panic? Would it silently replace
the invalid sequence with U+FFFD? Or something else entirely? But the
question doesn't really matter, because turning these bridges from O(1)
into O(N) would be an unacceptable performance penalty anyway.

-Kevin Ballard

On Fri, Dec 18, 2015, at 01:47 PM, Paul Cantrell via swift-evolution wrote:
> I was quite surprised to learn that it’s possible to create Swift
> strings that do not contain things other than valid Unicode
> characters. Is it feasible to guarantee that this cannot happen?
>
> String.init(bytes:encoding:) is failable, and does in fact validate
> that the given bytes are decodable with the given encoding in most
> circumstances:
>
> // Returns nil String(        bytes: [0xD8, 0x00] as [UInt8],
> encoding: NSUTF8StringEncoding)
>
> However, that initializer does *not* reject invalid surrogate
> characters in UTF-16:
>
> // Succeeds (wat?!) let bogusStr = String(        bytes: [0xD8, 0x00]
> as [UInt8],        encoding: NSUTF16BigEndianStringEncoding)!
>
> Ever wonder why dataWithJSONObject(…) is declared “throws?” Now
> you know!
>
> // Throws an error try! NSJSONSerialization.dataWithJSONObject(
> ["foo": bogusStr], options: [])
>
> And why does the URL escaping method in Foundation return an optional
> even though it escapes the string using UTF-8, which is a complete
> Unicode encoding? Same reason:
>
> // Returns nil
> bogusStr.stringByAddingPercentEncodingWithAllowedCharacters(
> NSCharacterSet.alphanumericCharacterSet())
>
> AFAIK, the first method could lose its “throws” modifier and the
> second method would not need to return an optional if only String
> itself guaranteed that it would always contain valid Unicode. There
> are likely other APIs that would see similar benefits.
>
> Are there downsides to making all String initializers guarantee that
> the Strings always contain valid Unicode? I can think of two
> possibilities:
>
>  * Is there some circumstance where you actually want a String to
>contain unpaired UTF-16 surrogate characters? I can’t imagine what
>that would be, but perhaps someone else can.
>  * Is it important to ensure that String.init(…) is O(1) when it
>uses UTF-16? This seems thin: I assume that the library has to
>copy the raw bytes regardless, and it’s O(n) for other character
>encodings, so…?
>
> Cheers,
>
> Paul
>
>
> _
> 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] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

Any feedback on this? I am rethinking the idea of #( because of the # prior 
usage as a preprocessor directive, but like how it stands out and has a 
meaning.  If no feedback, does it make sense to update my proposal with these 
ideas? Or does this feel like the wrong direction. 


> On Dec 30, 2015, at 8:52 AM, Paul Ossenbruggen  wrote:
> 
> Some more ideas, this moves away from the notion that we should make it look 
> really close to the ternary but keeps all the benefits of the ternary and 
> improves upon it. Since I have been suggesting a breaking change, it is a 
> good time to rethink it a bit. With this idea a horizontal line (double-dash) 
> separates the control value from the choices, the vertical line (bar) 
> indicates none of the above. 
> 
> Rather than use the ?( as I have suggested in the past, I think #( works 
> here, where you can think of it as a numerical index. The advantage of this 
> is, it stands out better and leaves ? for optionals only. This works well 
> with the list form. In the enum case the index is the enum key. I can see 
> that this however may be a problem because # is used for preprocessor like 
> directives. I am suggesting though just the #( sequence is treated 
> differently. Or the ?( is fine with me as well.
> 
> I have gone through a lot of options, some others I looked at are !( which 
> could be read as "match stick” paren, where the word “match” matches a case, 
> I am pretty sure that would not be considered any better than ?( because it 
> is used for optionals. Another is “witch hat paren” ^( which can be read as 
> “which”.  This might create a parse problem with "power of" though, which 
> maybe using ^[ (hat square bracket) could resolve that but not sure if that 
> would create other problems. Some other choices would be &(  and @( but did 
> not choose them because  they don’t have meaning to me but they do have the 
> advantage of standing out like the #(. 
> 
> let fa = #(truth -- 1 | 0) // boolean case. 
> let fb = #(pickOne -- "A", "B", "C", "D", "E", "F", "G" | "Z”) // list form, 
> pick index, zero based. 
> let fc = #(color -- .Red: 0xFF, .Green: 0x00FF00, .Blue: 0xFF | 
> 0xFF) // enum form.
> let fd = #(color -- .Red:0xFF, 
>   .Green:  0x00FF00, 
>   .Blue:   0xFF 
>   | 0xFF) // enum multiline, default: can be used here if 
> preferred.
> let fe = #(color -- .Red:0xFF, 
>   .Green:  0x00FF00, 
>   .Blue:   0xFF) // if all cases handled, the last bar is 
> optional
> 
> This visually kind of represents what is going on. Horizontal-line directs 
> eye to one of the normal choices. Vertical-line says none found stop looking 
> and do the otherwise choice. Kind of like a train switch. 
> 
> The strong feedback was that a replacement has to be usable in places where a 
> ternary could be used. So it needs to work on a single line (and multiline) 
> and needs to be compact. By having a compact, “else" that is possible on a 
> single line. 
> 
> Comparisons to ternary and other approaches:
> • It is very concise like ternary and can fit in places that a ternary does.
> • The horizontal line serves to provide a place to align the choices to pick 
> from, not as necessary with ternary. 
> • The vertical line stops the eye and indicates this is the “else” or 
> “default” choice, the colon does that in ternary but the bar stands out more.
> • The parens group the expression, in a way that the ternary does not. With a 
> ternary it is not until you get to the question mark and the barely visible 
> colon that you realize it is a ternary. 
> • The #( indicates immediately that the expression has started unlike a 
> ternary. 
> • #( clearly show beginning and end of the construct so that it is 
> immediately identifiable unlike ternary.
> • Makes quick one line conversions easily achievable just as ternary can but 
> allowing more than just boolean.  
> • The “else” choice is always last and is compactly represented with vertical 
> bar like ternary but more visible. This also differs from the switch 
> statement form, in that it is much more compact than “default:"
> • The dash does not create a double colon for enum case as was mentioned as a 
> problem in previous designs.
> • All data types for the control are handled the same way, like ternary but 
> now supports more than boolean, it supports any enumerable tope.
> • The list form looks like a Array sort of, the enum form looks sort of like 
> a Dictionary, this should make it seem familiar.
> • The enum form also supports pattern matching. (see below for examples). 
> Which ternary does not.
> • The vast majority of switch statements, at least that I typically use, 
> could be done with this and be much more compact and concise. However if your 
> needs are more complex, then the switch statement is still available. 
> • You get the benefits of automatic type 

Re: [swift-evolution] [Proposal]: Drastically improve searching API (indexOf(…)) of CollectionType

[Brent Royal-Gordon via swift-evolution]

I'm not sure about the rest of this, but...

>> 1. A backwards-compatible refactoring of `CollectionType.indices`, moving it 
>> to `Indexable`.
>> 
>> 2. A backwards-compatible refactoring of `indexOf(…)` (adding optional 
>> `range:` and moving it to `Indexable`).
>> 
>> 3. The addition of `rangeOf(…)`, `countOf(…)` and `isSorted(…)` to 
>> `Indexable` with a TIME complexity of `O(self.count)`.
>> 
>> 4. The introduction of a `BinarySearchView` on `Indexable`, allowing for 
>> fast (`O(log2(self.count))`) searches on `Indexable` via `indexOf(…)`, 
>> `rangeOf(…)`, `countOf(…)`, `lowerBoundOf(…)`, `upperBoundOf(…)` without 
>> cluttering `Indexable`'s interface.

I don't think you quite understand what `Indexable` is for.

`Indexable` is a minimal protocol containing the very most basic parts of 
`CollectionType`'s interface. It's used to avoid circular definitions in 
`CollectionType`. The doc comments on it describe it as "almost an 
implementation detail". I don't think it's appropriate to move a whole bunch of 
stuff into `Indexable` when it's supposed to be a minimal protocol.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Draft Proposal] Require `final` on protocol extension members

[Howard Lovatt via swift-evolution]

+1, adds nice clarity

> On 4 Jan 2016, at 11:28 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> Now that everyone's presumably back from vacation, I figured I'd repost this 
> proposal.
> 
> (If nobody has any comments, how can I get the ball rolling on starting a 
> review?)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> 
> 
> I've been working on this on-and-off for a few weeks, and I've finished 
> drafting a formal proposal. Comments welcome.
> 
> 
> 
> 
> 
> # Require `final` on protocol extension members
> 
> ## Introduction
> 
> Protocol extension members which aren't listed in the protocol itself have an 
> unusual behavior: a conforming type can implement an identically named 
> member, but instances with the protocol's type are always statically 
> dispatched to the protocol's implementation. This can lead to the same 
> instance displaying different behavior when it's cast to a  protocol it 
> conforms to. In effect, the conforming type's member shadows the protocol's, 
> rather than overriding it. This behavior is very surprising to some users.
> 
> The lack of a warning on this is [currently considered a 
> bug](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001861.html),
>  but I think we should go further and cause it to be an error. However, we 
> should also provide an escape hatch which permits conflicts in cases where 
> they're necessary.
> 
> ## Motivation
> 
> Suppose you write a protocol and extension like this:
> 
>   protocol Turnable {
>   func turning() -> Self
>   mutating func turn()
>   }
>   extension Turnable {
>   mutating func turn() {
>   self = turning()
>   }
>   
>   func turningRepeatedly(additionalTurns: Int) -> Self {
>   var turnedSelf = self
>   for _ in 1...additionalTurns {
>   turnedSelf.turn()
>   }
>   return turnedSelf
>   }
>   }
> 
> Now you want to write a conforming type, `SpimsterWicket`. There are three 
> different rules about whether your type has to, or can, implement its own 
> versions of these methods.
> 
> 1. `turning()` is a “protocol method”: it is listed in the protocol but is 
> not included in the extension. You *must* implement `turning()` to conform to 
> `Turnable`.
> 2. `turn()` is a “defaulted protocol method”: it is listed in the protocol 
> but there is also an implementation of it in the extension. You *may* 
> implement `turn()`; if you don’t, the protocol extension’s implementation 
> will be used.
> 3. `turningRepeatedly(_: Int)` is a “protocol extension method”: it is *not* 
> listed in the protocol, but only in the protocol extension. This is the case 
> we are trying to address.
> 
> Currently, in case 3, Swift permits you to implement your own 
> `turningRepeatedly(_: Int)`. However, your implementation may not be called 
> in every circumstance that you expect. If you call `turningRepeatedly` on a 
> variable of type `SpimsterWicket`, you’ll get `SpimsterWicket`’s 
> implementation of the method; however, if you call `turningRepeatedly` on a 
> variable of type `Turnable`, you’ll get `Turnable`’s implementation of the 
> method.
> 
>   var wicket: SpimsterWicket = SpimsterWicket()
>   var turnable: Turnable = wicket
>   
>   wicket.turn()   // Calls 
> SpimsterWicket.turn()
>   turnable.turn() // Also calls 
> SpimsterWicket.turn()
>   
>   wicket.turningRepeatedly(5) // Calls 
> SpimsterWicket.turningRepeatedly(_:)
>   turnable.turningRepeatedly(5)   // Calls Turnable.turningRepeatedly(_:)
> 
> In most parts of Swift, casting an instance or assigning it to a variable of 
> a different type doesn’t change which implementation will be called when you 
> put it on the left-hand side of a dot. (I’m leaving aside Objective-C 
> bridging, like `Int` to `NSNumber`, which is really a different operation 
> being performed with the same syntax.) If you put a `UIControl` into a 
> variable of type `UIView`, and then call `touchesBegan()` on that variable, 
> Swift will still call `UIControl.touchesBegan()`. The same is true of 
> defaulted protocol methods—if you call `turn()` on `turnable`, you’ll get 
> `SpimsterWicket.turn()`.
> 
> But this is not true of protocol extension methods. There, the static type of 
> the variable—the type known at compile time, the type that the variable is 
> labeled with—is used. Thus, calling `turningRepeatedly(_:)` on `wicket` gets 
> you `SpimsterWicket`’s implementation, but calling it on `turnable`—even 
> though it's merely the same instance casted to a different type—gets you 
> `Turnable`’s implementation.
> 
> This creates what I call an 

[swift-evolution] [Proposal] Add zip2WithNilPadding function

[Антон Миронов via swift-evolution]

Function zip constructs a sequence of pairs out of two sequences 
(Zip2Sequence). This sequence contains `min(sequence1.count, sequence2.count)` 
elements. I suggest to add sequence that contains `max(sequence1.count, 
sequence2.count)` elements (Zip2SequenceWithNilPadding). 
For example: 

let n = [2, 3, 5, 7, 11]
let s = ["two", "three", "five", "seven", "eleven", "thirteen"]
let regularZip = zip(n, s)
// regularZip: 2 => two, 3 => three, 5 => five, 7 => seven, 11 => eleven (5 
items)
let proposedZip = zipWithNilPadding(n, s)
// proposedZip: 2 => two, 3 => three, 5 => five, 7 => seven, 11 => eleven, nil 
=> thirteen (6 items)

I personally use zip to manage two sequences as one. Sometimes I do need to 
manage leftovers from longer sequence. In such case regular zip is not helpful.

About types. In oppose to Zip2Sequence that contains pairs of elements from 
each sequence (Sequence1.Generator.Element, Sequence2.Generator.Element), 
Zip2SequenceWithNilPadding will have to contain pairs of optional elements from 
each sequence (Sequence1.Generator.Element?, Sequence2.Generator.Element?).

Original idea from here: 
http://stackoverflow.com/questions/25153477/in-swift-i-would-like-to-join-two-sequences-in-to-a-sequence-of-tuples

Thanks,
Anton Mironov

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

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

[Félix Cloutier via swift-evolution]

I like this syntax, but I don't like that it could be ambiguous with 
successively calling animateWithDuration then some function called completion.

Other than that, I think that developers should be smart enough to exercise 
self-restraint with trailing closures when they're not appropriate. I don't 
understand what you (QQ Mail) mean with "you have to write it manually".

Félix

> Le 4 janv. 2016 à 12:50:15, Michel Fortin via swift-evolution 
>  a écrit :
> 
> Le 4 janv. 2016 à 7:45, QQ Mail via swift-evolution 
>  a écrit :
>> I would like to write like this: 
>> 
>> UIView.animateWithDuration(0.3,
>> 
>>animations: { () -> Void in
>>// animation code here
>>},
>>completion: { Bool -> Void in
>>// completion code here
>>}
>> )
> 
> Maybe, instead of disallowing trailing closures, we could allow consecutive 
> closures to be expressed like that:
> 
> UIView.animateWithDuration(0.3) {
>   // animation code here
> } completion { success in
>   // completion code here
> }
> 
> -- 
> Michel Fortin
> https://michelf.ca
> 
> ___
> 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]: support disable to trailing closure syntax

[Kevin Ballard via swift-evolution]

What's the point of this? What problem does it solve? If you don't want
a trailing closure, just don't use trailing closure syntax. I don't see
what benefit there is in explicitly annotating the function to disallow
trailing closure syntax with it; just because you don't want to use
trailing closure syntax doesn't mean nobody should be able to use it.
And other people using it shouldn't affect you.

-Kevin Ballard

On Mon, Jan 4, 2016, at 04:45 AM, QQ Mail via swift-evolution wrote:
> Hi, All: trailing closure is good for most cases, but sometimes it is
> also make code unclear, for example:
>
> UIView.animateWithDuration(0.3, animations: { () -> Void in //
> animation code here    }) { (Bool) -> Void in // completion
> code here }
>
> the label been removed and the code also not aligned well. I would
> like to write like this:
>
> UIView.animateWithDuration(0.3,
>


> animations: { () -> Void in // animation code here    },
> completion: { Bool -> Void in // completion code here    } )
>
> It is possible, just every time you have to write it manually. It’s a
> little wast. So I have a thought, since we already know this function
> is not well suit for trailing closure, can we add a attribute to
> disable it, for example:
>
> extensionUIView {
>
> @disable_trailing_closure    public static func
> animateWithDuration(duration:NSTimeInterval, animations:()->Void, 
> completion:()-
> >Void) { // implementations ...    } }
>
> I also found another one have issue for this too. link:
> http://www.natashatherobot.com/swift-trailing-closure-syntax/ what do
> you think?
>
> Best Regards
>
> ChenYungui
>
> _
> 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] Swift 2.2: #if swift language version

[David Owens II via swift-evolution]

I could (assuming I’m the David you’re referring to), though it will probably 
be towards the end of the week or early next week before I get a chance to get 
to it.

-David

> On Jan 4, 2016, at 1:03 PM, Drew Crawford  wrote:
> 
> The swift package manager is currently considering its own define 
> ,
>  so it's now the second official project that could benefit from this syntax.
> 
> David, any interest in writing this up?
> 
>> On Jan 3, 2016, at 4:48 AM, Goffredo Marocchi > > wrote:
>> 
>> +1 from me as well, supporting conditional compilation when the two versions 
>> of foundation differ and may differ for the foreseeable future seems a must 
>> on this end.
>> 
>> Sent from my iPhone
>> 
>> On 3 Jan 2016, at 10:12, Drew Crawford via swift-evolution 
>> > wrote:
>> 
 If we are going to support something like this, I’d rather see it be 
 something everyone could leverage as there are many use cases for this 
 feature:
 
 #if available("package-name", "1.2.*")
 #endif
>>> 
>>> Big +1.
>>> 
>>> I've asked specifically to get some kind of conditional compilation on 
>>> corelibs-foundation 
>>> 
>>>  being used.  corelibs-founcation is currently incompatible with Darwin 
>>> Foundation, and so it is impractical to make a single codebase build for 
>>> both.
>>> 
>>> But building the same application against both Foundations and spotting 
>>> differences is one of the important ways we're going to spot bugs.
>>> 
>>> So I think the code quality of Foundation ultimately hinges on getting some 
>>> feature like this in the language.
>>> 
>>> ___
>>> 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] Trial balloon: Ensure that String always contains valid Unicode

[Tony Parker via swift-evolution]

> On Dec 19, 2015, at 7:59 PM, Dmitri Gribenko  wrote:
> 
> On Fri, Dec 18, 2015 at 1:47 PM, Paul Cantrell via swift-evolution 
> > wrote:
> I was quite surprised to learn that it’s possible to create Swift strings 
> that do not contain things other than valid Unicode characters. Is it 
> feasible to guarantee that this cannot happen?
> 
> String.init(bytes:encoding:) is failable, and does in fact validate that the 
> given bytes are decodable with the given encoding in most circumstances:
> 
> // Returns nil
> String(
> bytes: [0xD8, 0x00] as [UInt8],
> encoding: NSUTF8StringEncoding)
> 
> However, that initializer does not reject invalid surrogate characters in 
> UTF-16:
> 
> // Succeeds (wat?!)
> let bogusStr = String(
> bytes: [0xD8, 0x00] as [UInt8],
> encoding: NSUTF16BigEndianStringEncoding)!
> 
> Adding this would be a useful guarantee, I support this.  The current 
> behavior looks inconsistent to me.  OTOH, the current behavior of 
> String(bytes:encoding:) mirrors the behavior of the NSString method, so this 
> would create inconsistency.  But I think the extra guarantee is worth it.
> 
> Tony, what do you think?
> 

NSString deals with this issue more on the ‘get’ side. For example, 
CFStringGetBytes has a ‘lossByte’ for use in replacement when the requested 
encoding cannot represent something stored by the receiver string. Also, the 
abstract NSString interface can be extended to add additional encodings (which 
is why the string encoding values are not an enumeration).

- Tony

> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko  >*/


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

Re: [swift-evolution] ternary operator ?: suggestion

[Rod Brown via swift-evolution]

For all the proposals I've seen on this topic, I have to say -1.

While I agree with the notions surrounding this operator, I've yet to see a 
better alternative presented, and none that feel truly Swift.

If someone has a great proposal, though, I look forward to seeing it.

- Rod

> On 5 Jan 2016, at 7:28 AM, Howard Lovatt via swift-evolution 
>  wrote:
> 
> -1 for me. None of it looks or feels like Swift, more like Haskell. I would 
> prefer a library solution for now and remove ?: from the language and add a 
> which into the standard library and see how that goes and if there is need 
> for more.
> 
> Sorry,
> 
> Howard.
> 
>> On 5 Jan 2016, at 7:24 AM, Paul Ossenbruggen via swift-evolution 
>>  wrote:
>> 
>> Any feedback on this? I am rethinking the idea of #( because of the # prior 
>> usage as a preprocessor directive, but like how it stands out and has a 
>> meaning.  If no feedback, does it make sense to update my proposal with 
>> these ideas? Or does this feel like the wrong direction. 
>> 
>> 
>>> On Dec 30, 2015, at 8:52 AM, Paul Ossenbruggen  wrote:
>>> 
>>> Some more ideas, this moves away from the notion that we should make it 
>>> look really close to the ternary but keeps all the benefits of the ternary 
>>> and improves upon it. Since I have been suggesting a breaking change, it is 
>>> a good time to rethink it a bit. With this idea a horizontal line 
>>> (double-dash) separates the control value from the choices, the vertical 
>>> line (bar) indicates none of the above. 
>>> 
>>> Rather than use the ?( as I have suggested in the past, I think #( works 
>>> here, where you can think of it as a numerical index. The advantage of this 
>>> is, it stands out better and leaves ? for optionals only. This works well 
>>> with the list form. In the enum case the index is the enum key. I can see 
>>> that this however may be a problem because # is used for preprocessor like 
>>> directives. I am suggesting though just the #( sequence is treated 
>>> differently. Or the ?( is fine with me as well.
>>> 
>>> I have gone through a lot of options, some others I looked at are !( which 
>>> could be read as "match stick” paren, where the word “match” matches a 
>>> case, I am pretty sure that would not be considered any better than ?( 
>>> because it is used for optionals. Another is “witch hat paren” ^( which can 
>>> be read as “which”.  This might create a parse problem with "power of" 
>>> though, which maybe using ^[ (hat square bracket) could resolve that but 
>>> not sure if that would create other problems. Some other choices would be 
>>> &(  and @( but did not choose them because  they don’t have meaning to me 
>>> but they do have the advantage of standing out like the #(. 
>>> 
>>> let fa = #(truth -- 1 | 0) // boolean case. 
>>> let fb = #(pickOne -- "A", "B", "C", "D", "E", "F", "G" | "Z”) // list 
>>> form, pick index, zero based. 
>>> let fc = #(color -- .Red: 0xFF, .Green: 0x00FF00, .Blue: 0xFF | 
>>> 0xFF) // enum form.
>>> let fd = #(color -- .Red:0xFF, 
>>> .Green:  0x00FF00, 
>>> .Blue:   0xFF 
>>> | 0xFF) // enum multiline, default: can be used here if 
>>> preferred.
>>> let fe = #(color -- .Red:0xFF, 
>>> .Green:  0x00FF00, 
>>> .Blue:   0xFF) // if all cases handled, the last bar is 
>>> optional
>>> 
>>> This visually kind of represents what is going on. Horizontal-line directs 
>>> eye to one of the normal choices. Vertical-line says none found stop 
>>> looking and do the otherwise choice. Kind of like a train switch. 
>>> 
>>> The strong feedback was that a replacement has to be usable in places where 
>>> a ternary could be used. So it needs to work on a single line (and 
>>> multiline) and needs to be compact. By having a compact, “else" that is 
>>> possible on a single line. 
>>> 
>>> Comparisons to ternary and other approaches:
>>> • It is very concise like ternary and can fit in places that a ternary does.
>>> • The horizontal line serves to provide a place to align the choices to 
>>> pick from, not as necessary with ternary. 
>>> • The vertical line stops the eye and indicates this is the “else” or 
>>> “default” choice, the colon does that in ternary but the bar stands out 
>>> more.
>>> • The parens group the expression, in a way that the ternary does not. With 
>>> a ternary it is not until you get to the question mark and the barely 
>>> visible colon that you realize it is a ternary. 
>>> • The #( indicates immediately that the expression has started unlike a 
>>> ternary. 
>>> • #( clearly show beginning and end of the construct so that it is 
>>> immediately identifiable unlike ternary.
>>> • Makes quick one line conversions easily achievable just as ternary can 
>>> but allowing more than just boolean.  
>>> • The “else” choice is always last and is compactly 

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Sebastian Hagedorn via swift-evolution]

>   * What is your evaluation of the proposal?

+1. Solves a real problem I’ve come across before.

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

Yes, because the problem can cause serious frustration, for beginners in 
particular.

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

Yes, because readability is improved. No need to consider the context anymore, 
the keyword itself makes it very clear what is declared.

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

I haven’t used any language with a comparable feature.

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

I’ve read the review carefully and followed the prior discussion briefly.

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

[swift-evolution] Keyword Discoverability

[John Joyce via swift-evolution]

Hello all

It feels like Swift has some risk of going the direction of C++ at times. By 
that I mean complexity creep. 
Increasingly nuanced scoping results in more keywords and constructs. 
Useful and good but increasingly complex and steepening learning curve. 

I'd like to kick off discussion of ways to increase discoverability. 

One thought is tools.  
In thinking about contextual completions like Xcode's Open Quickly or the 
universal field thing in Sublime, it sure seems like some way to invoke a list 
of keywords and constructs available-in-the-current-scope would be helpful. 

Thoughts ?

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

Re: [swift-evolution] Keyword Discoverability

[Developer via swift-evolution]

Give escape a whack sometime.

~Robert Widmann

2016/01/04 3:43、John Joyce via swift-evolution  
のメッセージ:

> Hello all
> 
> It feels like Swift has some risk of going the direction of C++ at times. By 
> that I mean complexity creep. 
> Increasingly nuanced scoping results in more keywords and constructs. 
> Useful and good but increasingly complex and steepening learning curve. 
> 
> I'd like to kick off discussion of ways to increase discoverability. 
> 
> One thought is tools.  
> In thinking about contextual completions like Xcode's Open Quickly or the 
> universal field thing in Sublime, it sure seems like some way to invoke a 
> list of keywords and constructs available-in-the-current-scope would be 
> helpful. 
> 
> Thoughts ?
> 
> ___
> 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] Separate protocols and interfaces

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

Cleared up that interfaces can be used in static dispatch as well. Added
other possible keyword variants instead of protocol/interface (there may
still be more). Added some lines about interoperation with existentials
proposal.
I agree that current proposal is in opposition of it, and that existentials
proposal can be cleaner if properly implemented. Whether the two proposals
are compatible, will be more clear once the syntax for existential types is
established.

Proposal page:
https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Rod Brown via swift-evolution]

>>* What is your evaluation of the proposal?
+1

>>* Is the problem being addressed significant enough to warrant a change 
>> to Swift?
Definitely. This is very confusing to have typealias mean two different things.

>>* Does this proposal fit well with the feel and direction of Swift?
Yes. While it does add something, it simplifies and removes confusion.

>>* If you have you used other languages or libraries with a similar 
>> feature, how do you feel that this proposal compares to those?
I haven't used similar features in other languages.

>>* How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
Read the review, run into the problem myself, and followed the discussion here.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Trial balloon: Ensure that String always contains valid Unicode

[Félix Cloutier via swift-evolution]

There are precedents for lazily checking for validity after bridging. Using 
`array as! [T]` on a NSArray without generics  fails lazily if you access an 
object that's not a T.

Félix

> Le 4 janv. 2016 à 14:59:47, Dmitri Gribenko via swift-evolution 
>  a écrit :
> 
> On Mon, Jan 4, 2016 at 9:37 PM, Kevin Ballard via swift-evolution 
> > wrote:
> I agree in principle that it would be great if String could enforce that it's 
> always valid.
>  
> But unfortunately, in practice, there's no way to do that without making it 
> expensive to bridge from Obj-C. Because, as you've demonstrated, you can 
> create NSStrings that contain things that aren't actually valid unicode 
> sequences, every single bridge from an NSString to a String would have to be 
> checked for validity. Not only that, but it's not clear what the behavior 
> would be if an invalid string is found, since these bridges are unconditional 
> - would Swift panic? Would it silently replace the invalid sequence with 
> U+FFFD? Or something else entirely? But the question doesn't really matter, 
> because turning these bridges from O(1) into O(N) would be an unacceptable 
> performance penalty anyway.
> 
> Currently String replaces invalid sequences with U+FFFD lazily during access, 
> but there are corner cases related to Objective-C bridging that can still 
> leak invalid Unicode.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko  >*/
>  ___
> 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] ternary operator ?: suggestion

[Charles Constant via swift-evolution]

Our ternary-like switch is now in the "commonly_proposed.md" file, which
doesn't bode very well. It puzzles me that there isn't more enthusiasm. Are
we the only ones who get irritated taking up so much space with a "switch"
when all we need to do is transform between two sets of values?

I think we need to revamp the proposal somehow to make the idea clearer,
because it ought to be pretty compelling.

• Does anyone here have better "side by side" examples of code
before/after?

• Can anyone think of a way to revise the (English) language of the
proposal to make it shorter and sweeter?

Apologies for prescribing instead of doing. My only excuse is that I'm "too
busy"




On Mon, Jan 4, 2016 at 3:03 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 4, 2016, at 2:37 PM, Paul Ossenbruggen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Good feedback, I am all for making it feel more like swift. Any ideas
> would be welcome. I will also try to come up with some myself.
>
>
> My suggestion is to leave ternary alone and try to come up with a
> ternary-like switch expression that is workable.  I think that is likely
> the best change possible at this point.
>
>
>
> On Jan 4, 2016, at 12:34 PM, Rod Brown  wrote:
>
> For all the proposals I've seen on this topic, I have to say -1.
>
> While I agree with the notions surrounding this operator, I've yet to see
> a better alternative presented, and none that feel truly Swift.
>
> If someone has a great proposal, though, I look forward to seeing it.
>
> - Rod
>
> On 5 Jan 2016, at 7:28 AM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> -1 for me. None of it looks or feels like Swift, more like Haskell. I
> would prefer a library solution for now and remove ?: from the language and
> add a which into the standard library and see how that goes and if there is
> need for more.
>
> Sorry,
>
> Howard.
>
> On 5 Jan 2016, at 7:24 AM, Paul Ossenbruggen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Any feedback on this? I am rethinking the idea of #( because of the #
> prior usage as a preprocessor directive, but like how it stands out and has
> a meaning.  If no feedback, does it make sense to update my proposal with
> these ideas? Or does this feel like the wrong direction.
>
>
> On Dec 30, 2015, at 8:52 AM, Paul Ossenbruggen  wrote:
>
> Some more ideas, this moves away from the notion that we should make it
> look really close to the ternary but keeps all the benefits of the ternary
> and improves upon it. Since I have been suggesting a breaking change, it is
> a good time to rethink it a bit. With this idea a horizontal line
> (double-dash) separates the control value from the choices, the vertical
> line (bar) indicates none of the above.
>
> Rather than use the ?( as I have suggested in the past, I think #( works
> here, where you can think of it as a numerical index. The advantage of this
> is, it stands out better and leaves ? for optionals only. This works well
> with the list form. In the enum case the index is the enum key. I can see
> that this however may be a problem because # is used for preprocessor like
> directives. I am suggesting though just the #( sequence is treated
> differently. Or the ?( is fine with me as well.
>
> I have gone through a lot of options, some others I looked at are !( which
> could be read as "match stick” paren, where the word “match” matches a
> case, I am pretty sure that would not be considered any better than ?(
> because it is used for optionals. Another is “witch hat paren” ^( which can
> be read as “which”.  This might create a parse problem with "power of"
> though, which maybe using ^[ (hat square bracket) could resolve that but
> not sure if that would create other problems. Some other choices would be
> &(  and @( but did not choose them because  they don’t have meaning to me
> but they do have the advantage of standing out like the #(.
>
> let fa = #(truth -- 1 | 0) // boolean case.
> let fb = #(pickOne -- "A", "B", "C", "D", "E", "F", "G" | "Z”) // list
> form, pick index, zero based.
> let fc = #(color -- .Red: 0xFF, .Green: 0x00FF00, .Blue: 0xFF |
> 0xFF) // enum form.
> let fd = #(color -- .Red:0xFF,
>   .Green:  0x00FF00,
>   .Blue:   0xFF
>  | 0xFF) // enum multiline, default: can be used here if
> preferred.
> let fe = #(color -- .Red:0xFF,
>   .Green:  0x00FF00,
>   .Blue:   0xFF) // if all cases handled, the last bar is optional
>
> This visually kind of represents what is going on. Horizontal-line directs
> eye to one of the normal choices. Vertical-line says none found stop
> looking and do the otherwise choice. Kind of like a train switch.
>
> The strong feedback was that a replacement has to be usable in places
> where a ternary could be used. So it needs to work on a single line (and
> 

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

[David Farler via swift-evolution]

We already have @- and #-prefixed availability-like constructs, so I would 
prefer something more specific to the task – I wouldn't want to dilute the 
meaning of a package name argument by supplying it with the magic package 
"swift", for example. Changes to the language can be highly disruptive to all 
Swift code, so that's why I think it warrants its own build configuration. 

David

> On Dec 20, 2015, at 10:45 PM, David Owens II via swift-evolution 
>  wrote:
> 
> If we are going to support something like this, I’d rather see it be 
> something everyone could leverage as there are many use cases for this 
> feature:
> 
> #if available("package-name", "1.2.*")
> #endif
> 
> Then at least everyone can opt-in to using it for availability checks. This 
> should of course tie into the Swift Package Manager and use proper semver 
> syntax (might as well use node’s example: https://docs.npmjs.com/misc/semver 
> ).
> 
> Another solution would be to simply factor out the code into separate files 
> and add each to the appropriate build configuration. Then nothing new needs 
> to be added.
> 
> -David
> 
>> On Dec 20, 2015, at 2:01 PM, James Campbell via swift-evolution 
>> > wrote:
>> 
>> Also in future versions features may go away meaning older libraries may 
>> assume that greater than swift 2 is all that is needed to imply 
>> compatibility. Also libraries may be written against features they may not 
>> know which version of swift it will get into. Additionally certain features 
>> aren't available across platforms so how do you know what swift 2 means 
>> across platforms ? 
>> 
>> Swift version conditionals are a useful fallback but we should also try and 
>> make feature conditionals a first class citizen too. 
>> 
>> I love the @supports syntax in CSS, if we could do that then that would be 
>> awesome :)  it's a great way of handling implementations across platforms 
>> 
>> Sent from my iPhone
>> 
>> On 20 Dec 2015, at 21:00, Andrey Tarantsov via swift-evolution 
>> > wrote:
>> 
 I suspect with the race to a stable language, the plan is to design 
 features as if the language were to stay solid.
>>> 
>>> Are you implying that Swift 4 will have zero new features? Nothing that 
>>> libraries will want to use conditionally when available?
>>> 
>>> A.
>>> 
>>> ___
>>> 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] [swift-build-dev] [swiftpm] Add proposal for C language support

[Daniel Dunbar via swift-evolution]

> On Jan 3, 2016, at 6:34 AM, Maury Markowitz via swift-evolution 
>  wrote:
> 
>> On Jan 2, 2016, at 9:00 AM, Daniel Dunbar via swift-build-dev 
>>  wrote:
>> 
>> Happy 2016!
>> 
>> I am working on an initial proposal for adding support for C language 
>> targets to the Swift package manager, and am interested in feedback:
> 
> The idea of including C libraries/code in Swift projects *without* having to 
> use Xcode strikes me as *very* valuable. Two questions:
> 
> a) for item (2) in "solution" I see the advantages of placing the bridging in 
> a separate directory, but I want to point out that this may make the 
> interactions between various devenvs and things like GitHub more annoying. 
> Xcode's Bridging-Header solution has it's own problems, but may be easier to 
> work with in complex projects. Generally I think more flexibility here might 
> be valuable, even going so far as a ".bh" for the bridging files, allowing 
> them to be placed anywhere.

We anticipate directly adding support for targets with both C and Swift code, 
at some point (which is where the bridging header comes in), but that is more 
involved and something I wanted to explicitly tackle separately. This proposal 
is very focused at adding support for building C source code that is a part of 
the project, and exposing the headers that declare the interfaces to that code. 
It is not really intended to tackle the problem of using C headers to expose 
*other* code.

> b) for (3), I'm facing this problem right now porting some very old C that 
> has a main.c that includes main() as well as other more general code that the 
> rest of the system uses. I solved this by changing main(), but that's not 
> ideal, I would greatly prefer to use the original code verbatim. So for the 
> 10% of cases where this is a problem, perhaps a compiler directive would be 
> useful?

If you are integrating the code directly into your project I feel like it makes 
more sense to require some adaption in order to keep the conventions simple. 
There are likely a large number of adaptions necessary to integrate existing C 
projects into these conventions, over time I expect we will allow customization 
for common problems (and ones that are easy to define a syntax for 
customizing), but I'm not sure if this one would bubble up to that level of 
importance.

 - Daniel

> 
> 
> ___
> 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] Trial balloon: Ensure that String always contains valid Unicode

[Kevin Ballard via swift-evolution]

That kind of lazy checking of arrays is used pretty rarely (since, as
you say, it only occurs with an `as!` expression). But doing lazy
checking of strings would end up having to check *every* string that
comes from ObjC (which, in a Swift app that uses Cocoa frameworks, is
likely to be most strings the app works with).

-Kevin Ballard

On Mon, Jan 4, 2016, at 02:41 PM, Félix Cloutier wrote:
> There are precedents for lazily checking for validity after bridging.
> Using `array as! [T]` on a NSArray without generics  fails lazily if
> you access an object that's not a T.
>
> Félix
>
>> Le 4 janv. 2016 à 14:59:47, Dmitri Gribenko via swift-evolution > evolut...@swift.org> a écrit :
>>
>> On Mon, Jan 4, 2016 at 9:37 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote:
>>> __
>>> I agree in principle that it would be great if String could enforce
>>> that it's always valid.
>>>
>>> But unfortunately, in practice, there's no way to do that without
>>> making it expensive to bridge from Obj-C. Because, as you've
>>> demonstrated, you can create NSStrings that contain things that
>>> aren't actually valid unicode sequences, every single bridge from an
>>> NSString to a String would have to be checked for validity. Not only
>>> that, but it's not clear what the behavior would be if an invalid
>>> string is found, since these bridges are unconditional - would Swift
>>> panic? Would it silently replace the invalid sequence with U+FFFD?
>>> Or something else entirely? But the question doesn't really matter,
>>> because turning these bridges from O(1) into O(N) would be an
>>> unacceptable performance penalty anyway.
>>
>> Currently String replaces invalid sequences with U+FFFD lazily during
>> access, but there are corner cases related to Objective-C bridging
>> that can still leak invalid Unicode.
>>
>> Dmitri
>>
>> --
>> main(i,j){for(i=2;;i++){for(j=2;j> (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
>>
___
>> 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 Draft] Flexible memberwise initialization

[Howard Lovatt via swift-evolution]

Yes you can get close, but:

1. Its weird that you can only do this in an extension.
2. Its not quite the same as the proposal the current member-wise initialiser 
does not make the init arguments optional (the arguments themselves do not have 
defaults), i.e. with your example `let defaultOriginRect = Rect(size: 
Size(width: 5.0, height: 5.0))` fails whereas it would work for the proposal 
(this could also be true if the existing struct memberwise init and the new 
`memberwise init(..)` where changed to provide init argument defaults).
3. Only ‘really' works for structs, the compiler doesn’t write a member-wise 
initialiser for classes (just a default initialiser).
4. Still need the compiler to provide both default and member-wise 
initialisers, whereas this proposal would allow the existing default and 
member-wise initialisers to be deprecated and just the new member-wise 
initialiser would remain which would simplify the language and make it clear 
what was happening (this could also be true if a `memberwise init(..)` where 
added and existing compiler written inits removed).


> On 5 Jan 2016, at 10:16 AM, Matthew Johnson  wrote:
> 
> struct Rect { var origin: Point = Point(), size: Size = Size() }
> extension Rect {
>init(center: Point, size: Size) {
>let originX = center.x - (size.width / 2)
>let originY = center.y - (size.height / 2)
>self.init(origin: Point(x: originX, y: originY), size: size)
>}
> }

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

Re: [swift-evolution] [Draft Proposal] Require `final` on protocol extension members

[Rod Brown via swift-evolution]

Sorry Brent, I obviously didn’t read down to the alternatives section. Stupid 
me.

I think that it is a larger change, but if we’re going to change this, 
shouldn’t we do it right?

From my perspective, a protocol says what “should” happen, whereas a type is 
where it eventually “does” happen. I find it a little backwards to make 
protocol extensions mandatorily final. It blocks out the power of defaulting.  
I definitely agree with you that final in protocol extensions is a great idea, 
though.


> On 5 Jan 2016, at 10:13 AM, Brent Royal-Gordon  wrote:
> 
>> The question then becomes simple: should a type gave the right to replace 
>> the value in the protocol? Should protocol extensions therefore only be 
>> defaults?
>> 
>> I would argue for treating the protocol as a default. If you had an 
>> identical member in the type, use the type rather than the protocol 
>> extension. This allows the most flexibility. That said, I am aware that 
>> means that some optimisations are not possible. I simply think this makes 
>> the most sense from a programming perspective.
> 
> I discuss this in the Alternatives section:
> 
>> ### Dynamically dispatch calls to protocol extension members
>> 
>> This would fix the underlying problem—the confusing behavior—by making 
>> protocol extension members not behave confusingly.
>> 
>> This would likely take a redesign of protocol witnesses to include extension 
>> methods not listed in the original protocol. It's probably not 
>> impossible—class extensions behave this way—but it's a much bigger change 
>> than what I propose, which keeps the current runtime semantics and only adds 
>> compile-time errors and keywords.
>> 
>> Dynamically dispatching to protocol extension members would also change the 
>> performance characteristics of these calls. Even if this change were made, 
>> we might want to allow users to apply `final` to extension methods which 
>> they want to be dispatched statically.
> 
> Basically, I'm not proposing that simply because it's a larger change and 
> would take redesigning that would have to wait until at least Swift 3, and is 
> well beyond my own ability to specify or even evaluate the feasibility of. 
> Plus, as I said in that last paragraph, `final` protocol extension members 
> may be useful even if we do treat extension members as equivalent to 
> defaulted protocol members.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

Re: [swift-evolution] [Draft Proposal] Require `final` on protocol extension members

[Rod Brown via swift-evolution]

It definitely is odd behaviour that needs to be sorted out. The question is, 
how? I think part of this is the confusing position that you put the code into.

If I approached this new to Swift, I would expect the declaration in the type 
to be a replacement for a default in the protocol extension. I would not expect 
protocol to be able to override my type in any way.

Perhaps this shows more that I am a object oriented programmer more than 
protocol oriented, but if I'm declaring it specifically on a type, I would 
expect the type to be the definitive word on this.

The question then becomes simple: should a type gave the right to replace the 
value in the protocol? Should protocol extensions therefore only be defaults?

I would argue for treating the protocol as a default. If you had an identical 
member in the type, use the type rather than the protocol extension. This 
allows the most flexibility. That said, I am aware that means that some 
optimisations are not possible. I simply think this makes the most sense from a 
programming perspective.

- Rod

> On 4 Jan 2016, at 11:28 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> Now that everyone's presumably back from vacation, I figured I'd repost this 
> proposal.
> 
> (If nobody has any comments, how can I get the ball rolling on starting a 
> review?)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> 
> 
> I've been working on this on-and-off for a few weeks, and I've finished 
> drafting a formal proposal. Comments welcome.
> 
> 
> 
> 
> 
> # Require `final` on protocol extension members
> 
> ## Introduction
> 
> Protocol extension members which aren't listed in the protocol itself have an 
> unusual behavior: a conforming type can implement an identically named 
> member, but instances with the protocol's type are always statically 
> dispatched to the protocol's implementation. This can lead to the same 
> instance displaying different behavior when it's cast to a  protocol it 
> conforms to. In effect, the conforming type's member shadows the protocol's, 
> rather than overriding it. This behavior is very surprising to some users.
> 
> The lack of a warning on this is [currently considered a 
> bug](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001861.html),
>  but I think we should go further and cause it to be an error. However, we 
> should also provide an escape hatch which permits conflicts in cases where 
> they're necessary.
> 
> ## Motivation
> 
> Suppose you write a protocol and extension like this:
> 
>protocol Turnable {
>func turning() -> Self
>mutating func turn()
>}
>extension Turnable {
>mutating func turn() {
>self = turning()
>}
>
>func turningRepeatedly(additionalTurns: Int) -> Self {
>var turnedSelf = self
>for _ in 1...additionalTurns {
>turnedSelf.turn()
>}
>return turnedSelf
>}
>}
> 
> Now you want to write a conforming type, `SpimsterWicket`. There are three 
> different rules about whether your type has to, or can, implement its own 
> versions of these methods.
> 
> 1. `turning()` is a “protocol method”: it is listed in the protocol but is 
> not included in the extension. You *must* implement `turning()` to conform to 
> `Turnable`.
> 2. `turn()` is a “defaulted protocol method”: it is listed in the protocol 
> but there is also an implementation of it in the extension. You *may* 
> implement `turn()`; if you don’t, the protocol extension’s implementation 
> will be used.
> 3. `turningRepeatedly(_: Int)` is a “protocol extension method”: it is *not* 
> listed in the protocol, but only in the protocol extension. This is the case 
> we are trying to address.
> 
> Currently, in case 3, Swift permits you to implement your own 
> `turningRepeatedly(_: Int)`. However, your implementation may not be called 
> in every circumstance that you expect. If you call `turningRepeatedly` on a 
> variable of type `SpimsterWicket`, you’ll get `SpimsterWicket`’s 
> implementation of the method; however, if you call `turningRepeatedly` on a 
> variable of type `Turnable`, you’ll get `Turnable`’s implementation of the 
> method.
> 
>var wicket: SpimsterWicket = SpimsterWicket()
>var turnable: Turnable = wicket
>
>wicket.turn()// Calls SpimsterWicket.turn()
>turnable.turn()// Also calls SpimsterWicket.turn()
>
>wicket.turningRepeatedly(5)// Calls 
> SpimsterWicket.turningRepeatedly(_:)
>turnable.turningRepeatedly(5)// Calls Turnable.turningRepeatedly(_:)
> 
> In most parts of Swift, casting an instance or assigning it to a variable of 
> a different type doesn’t change which implementation will be called when you 
> put it 

Re: [swift-evolution] [swift-build-dev] [Proposal] Lock file for Swift Package Manager

[Max Howell via swift-evolution]

> Personally, I often work offline, and currently I'm often working on a 
> project and its dependencies at the same time.
> For those two reasons, *in the current proposal state* #1 would be my 
> preferred choice (with proper warnings).

I think it is reasonable for the build to proceed if there is no network 
connectivity. Just with warnings, since it is possible it will fail/be 
broken/etc.

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

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

Just tried going down this path a bit of creating a library. You can get pretty 
far for the boolean or integer types, but don’t see a way to do a switch like 
solution. Also, a big problem with this approach is there is no way to short 
circuit evaluate the expressions in the list of a variadic function. They will 
all be evaluated, at the call site. One other problem, so we don’t conflict 
with the “else” and “default”, keywords, I had to use “def” or “el” for “else". 

// Simple bool
func calcB()->String {
print(“B calculated")
return "B"
}

// Simple bool
func sel(condition : Bool, @autoclosure _ trueExpr:()->T, @autoclosure _ 
falseExpr:()->T) -> T {
return condition ? trueExpr() : falseExpr()
}

sel(true, "A", calcB())
sel(false, "A", calcB())

// alternative, used "def" for default to not conflict with "else" or “default. 
This version, may not be necessary.
func sel(condition : Bool, @autoclosure _ expr:()->T,  @autoclosure 
el:()->T) -> T {
return condition ? expr() : el()
}

sel(true, "A", el:calcB())
sel(false, "A", el:calcB())

// index approach, note the use of autoclosure does not work on array or array 
of functions. So it will evaluate all expressions at the call site. Unless 
there is some trick I don’t know. 
func sel(selector : Int,/* @autoclosure */ _ exprs: T..., def : T) -> T {
if  selector > exprs.count || selector < 0 {
return def
}
return exprs[selector]
}
sel(1, "A", "B", "C", def:"D")
sel(9, "A", "B", "C", def:"D")
sel(-1, "A", "B", "C", def:"D")



> On Jan 4, 2016, at 12:28 PM, Howard Lovatt  wrote:
> 
> -1 for me. None of it looks or feels like Swift, more like Haskell. I would 
> prefer a library solution for now and remove ?: from the language and add a 
> which into the standard library and see how that goes and if there is need 
> for more.
> 
> Sorry,
> 
> Howard.
> 
>> On 5 Jan 2016, at 7:24 AM, Paul Ossenbruggen via swift-evolution 
>> > wrote:
>> 
>> Any feedback on this? I am rethinking the idea of #( because of the # prior 
>> usage as a preprocessor directive, but like how it stands out and has a 
>> meaning.  If no feedback, does it make sense to update my proposal with 
>> these ideas? Or does this feel like the wrong direction. 
>> 
>> 
>>> On Dec 30, 2015, at 8:52 AM, Paul Ossenbruggen >> > wrote:
>>> 
>>> Some more ideas, this moves away from the notion that we should make it 
>>> look really close to the ternary but keeps all the benefits of the ternary 
>>> and improves upon it. Since I have been suggesting a breaking change, it is 
>>> a good time to rethink it a bit. With this idea a horizontal line 
>>> (double-dash) separates the control value from the choices, the vertical 
>>> line (bar) indicates none of the above. 
>>> 
>>> Rather than use the ?( as I have suggested in the past, I think #( works 
>>> here, where you can think of it as a numerical index. The advantage of this 
>>> is, it stands out better and leaves ? for optionals only. This works well 
>>> with the list form. In the enum case the index is the enum key. I can see 
>>> that this however may be a problem because # is used for preprocessor like 
>>> directives. I am suggesting though just the #( sequence is treated 
>>> differently. Or the ?( is fine with me as well.
>>> 
>>> I have gone through a lot of options, some others I looked at are !( which 
>>> could be read as "match stick” paren, where the word “match” matches a 
>>> case, I am pretty sure that would not be considered any better than ?( 
>>> because it is used for optionals. Another is “witch hat paren” ^( which can 
>>> be read as “which”.  This might create a parse problem with "power of" 
>>> though, which maybe using ^[ (hat square bracket) could resolve that but 
>>> not sure if that would create other problems. Some other choices would be 
>>> &(  and @( but did not choose them because  they don’t have meaning to me 
>>> but they do have the advantage of standing out like the #(. 
>>> 
>>> let fa = #(truth -- 1 | 0) // boolean case. 
>>> let fb = #(pickOne -- "A", "B", "C", "D", "E", "F", "G" | "Z”) // list 
>>> form, pick index, zero based. 
>>> let fc = #(color -- .Red: 0xFF, .Green: 0x00FF00, .Blue: 0xFF | 
>>> 0xFF) // enum form.
>>> let fd = #(color -- .Red:0xFF, 
>>> .Green:  0x00FF00, 
>>> .Blue:   0xFF 
>>> | 0xFF) // enum multiline, default: can be used here if 
>>> preferred.
>>> let fe = #(color -- .Red:0xFF, 
>>> .Green:  0x00FF00, 
>>> .Blue:   0xFF) // if all cases handled, the last bar is 
>>> optional
>>> 
>>> This visually kind of represents what is going on. Horizontal-line directs 
>>> eye to one of the normal choices. Vertical-line says none found stop 
>>> looking and do the otherwise choice. Kind of like a train 

Re: [swift-evolution] [Proposal]: Drastically improve searching API (indexOf(…)) of CollectionType

[T.J. Usiyan via swift-evolution]

The proposed additions to Indexible only require Indices… I don't see how
adding them is such a mistake. If we can gain these behaviors while only
*requiring* that minimum interface… go for it.

TJ

On Mon, Jan 4, 2016 at 3:49 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm not sure about the rest of this, but...
>
> >> 1. A backwards-compatible refactoring of `CollectionType.indices`,
> moving it to `Indexable`.
> >>
> >> 2. A backwards-compatible refactoring of `indexOf(…)` (adding optional
> `range:` and moving it to `Indexable`).
> >>
> >> 3. The addition of `rangeOf(…)`, `countOf(…)` and `isSorted(…)` to
> `Indexable` with a TIME complexity of `O(self.count)`.
> >>
> >> 4. The introduction of a `BinarySearchView` on `Indexable`, allowing
> for fast (`O(log2(self.count))`) searches on `Indexable` via `indexOf(…)`,
> `rangeOf(…)`, `countOf(…)`, `lowerBoundOf(…)`, `upperBoundOf(…)` without
> cluttering `Indexable`'s interface.
>
> I don't think you quite understand what `Indexable` is for.
>
> `Indexable` is a minimal protocol containing the very most basic parts of
> `CollectionType`'s interface. It's used to avoid circular definitions in
> `CollectionType`. The doc comments on it describe it as "almost an
> implementation detail". I don't think it's appropriate to move a whole
> bunch of stuff into `Indexable` when it's supposed to be a minimal protocol.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

So without additional language support, I don’t see a library is workable but 
maybe it can. Maybe we can add variadic function lists? And new capabilities 
that are building blocks for building a switch expression.

> On Jan 4, 2016, at 3:53 PM, Paul Ossenbruggen  wrote:
> 
> Just tried going down this path a bit of creating a library. You can get 
> pretty far for the boolean or integer types, but don’t see a way to do a 
> switch like solution. Also, a big problem with this approach is there is no 
> way to short circuit evaluate the expressions in the list of a variadic 
> function. They will all be evaluated, at the call site. One other problem, so 
> we don’t conflict with the “else” and “default”, keywords, I had to use “def” 
> or “el” for “else". 
> 
> // Simple bool
> func calcB()->String {
> print(“B calculated")
> return "B"
> }
> 
> // Simple bool
> func sel(condition : Bool, @autoclosure _ trueExpr:()->T, @autoclosure _ 
> falseExpr:()->T) -> T {
> return condition ? trueExpr() : falseExpr()
> }
> 
> sel(true, "A", calcB())
> sel(false, "A", calcB())
> 
> // alternative, used "def" for default to not conflict with "else" or 
> “default. This version, may not be necessary.
> func sel(condition : Bool, @autoclosure _ expr:()->T,  @autoclosure 
> el:()->T) -> T {
> return condition ? expr() : el()
> }
> 
> sel(true, "A", el:calcB())
> sel(false, "A", el:calcB())
> 
> // index approach, note the use of autoclosure does not work on array or 
> array of functions. So it will evaluate all expressions at the call site. 
> Unless there is some trick I don’t know. 
> func sel(selector : Int,/* @autoclosure */ _ exprs: T..., def : T) -> T {
> if  selector > exprs.count || selector < 0 {
> return def
> }
> return exprs[selector]
> }
> sel(1, "A", "B", "C", def:"D")
> sel(9, "A", "B", "C", def:"D")
> sel(-1, "A", "B", "C", def:"D")
> 
> 
> 
>> On Jan 4, 2016, at 12:28 PM, Howard Lovatt > > wrote:
>> 
>> -1 for me. None of it looks or feels like Swift, more like Haskell. I would 
>> prefer a library solution for now and remove ?: from the language and add a 
>> which into the standard library and see how that goes and if there is need 
>> for more.
>> 
>> Sorry,
>> 
>> Howard.
>> 
>>> On 5 Jan 2016, at 7:24 AM, Paul Ossenbruggen via swift-evolution 
>>> > wrote:
>>> 
>>> Any feedback on this? I am rethinking the idea of #( because of the # prior 
>>> usage as a preprocessor directive, but like how it stands out and has a 
>>> meaning.  If no feedback, does it make sense to update my proposal with 
>>> these ideas? Or does this feel like the wrong direction. 
>>> 
>>> 
 On Dec 30, 2015, at 8:52 AM, Paul Ossenbruggen > wrote:
 
 Some more ideas, this moves away from the notion that we should make it 
 look really close to the ternary but keeps all the benefits of the ternary 
 and improves upon it. Since I have been suggesting a breaking change, it 
 is a good time to rethink it a bit. With this idea a horizontal line 
 (double-dash) separates the control value from the choices, the vertical 
 line (bar) indicates none of the above. 
 
 Rather than use the ?( as I have suggested in the past, I think #( works 
 here, where you can think of it as a numerical index. The advantage of 
 this is, it stands out better and leaves ? for optionals only. This works 
 well with the list form. In the enum case the index is the enum key. I can 
 see that this however may be a problem because # is used for preprocessor 
 like directives. I am suggesting though just the #( sequence is treated 
 differently. Or the ?( is fine with me as well.
 
 I have gone through a lot of options, some others I looked at are !( which 
 could be read as "match stick” paren, where the word “match” matches a 
 case, I am pretty sure that would not be considered any better than ?( 
 because it is used for optionals. Another is “witch hat paren” ^( which 
 can be read as “which”.  This might create a parse problem with "power of" 
 though, which maybe using ^[ (hat square bracket) could resolve that but 
 not sure if that would create other problems. Some other choices would be 
 &(  and @( but did not choose them because  they don’t have meaning to me 
 but they do have the advantage of standing out like the #(. 
 
 let fa = #(truth -- 1 | 0) // boolean case. 
 let fb = #(pickOne -- "A", "B", "C", "D", "E", "F", "G" | "Z”) // list 
 form, pick index, zero based. 
 let fc = #(color -- .Red: 0xFF, .Green: 0x00FF00, .Blue: 0xFF | 
 0xFF) // enum form.
 let fd = #(color -- .Red:0xFF, 
.Green:  0x00FF00, 
.Blue:   0xFF 
 

Re: [swift-evolution] Trial balloon: Ensure that String always contains valid Unicode

[Paul Cantrell via swift-evolution]

>> But doing lazy checking of strings would end up having to check every string 
>> that comes from ObjC


I don’t think that’s necessarily true. There’s a limited set of places where 
invalid Unicode can creep into an NSString, and so the lazy check could 
probably bypass quite a few common cases — an ASCII string for example. Without 
digging into it, I suspect any NSString created from UTF-8 data can be safely 
bridged, since unpaired surrogate chars can’t make it through UTF-8.

Cheers, P


> On Jan 4, 2016, at 4:43 PM, Kevin Ballard via swift-evolution 
>  wrote:
> 
> That kind of lazy checking of arrays is used pretty rarely (since, as you 
> say, it only occurs with an `as!` expression). But doing lazy checking of 
> strings would end up having to check every string that comes from ObjC 
> (which, in a Swift app that uses Cocoa frameworks, is likely to be most 
> strings the app works with).
>  
> -Kevin Ballard
>  
> On Mon, Jan 4, 2016, at 02:41 PM, Félix Cloutier wrote:
>> There are precedents for lazily checking for validity after bridging. Using 
>> `array as! [T]` on a NSArray without generics  fails lazily if you access an 
>> object that's not a T.
>>  
>> Félix
>>  
>>> Le 4 janv. 2016 à 14:59:47, Dmitri Gribenko via swift-evolution 
>>> > a écrit :
>>>  
>>> On Mon, Jan 4, 2016 at 9:37 PM, Kevin Ballard via swift-evolution 
>>> > wrote:
>>> 
>>> I agree in principle that it would be great if String could enforce that 
>>> it's always valid.
>>>  
>>> But unfortunately, in practice, there's no way to do that without making it 
>>> expensive to bridge from Obj-C. Because, as you've demonstrated, you can 
>>> create NSStrings that contain things that aren't actually valid unicode 
>>> sequences, every single bridge from an NSString to a String would have to 
>>> be checked for validity. Not only that, but it's not clear what the 
>>> behavior would be if an invalid string is found, since these bridges are 
>>> unconditional - would Swift panic? Would it silently replace the invalid 
>>> sequence with U+FFFD? Or something else entirely? But the question doesn't 
>>> really matter, because turning these bridges from O(1) into O(N) would be 
>>> an unacceptable performance penalty anyway.
>>>  
>>> Currently String replaces invalid sequences with U+FFFD lazily during 
>>> access, but there are corner cases related to Objective-C bridging that can 
>>> still leak invalid Unicode.
>>>  
>>> Dmitri
>>>  
>>> -- 
>>> main(i,j){for(i=2;;i++){for(j=2;j>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko >> >*/
>>>  ___
>>> 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] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[plx via swift-evolution]

And of course it’s not like this is taking away functionality, just not adding 
it yet. So sure, +1, this is still forward progress. 

The fact it’s so easy to forget this other use of typealias doesn't really work 
in protocols right now is evidence enough for the proposal. Apologies for the 
double-about face.

> On Jan 4, 2016, at 6:17 PM, Brent Royal-Gordon  wrote:
> 
>> On a re-read I am -1; I like the `associatedtype` keyword but didn’t realize 
>> there was no plan to let `typealias` be used within a protocol to as a 
>> convenience (and to preserve intent, and to improve the development 
>> experience when still figuring out an interface design).
>> 
>> I would prefer the new keyword and also adding/allowing one to add 
>> convenience typealiases within a protocol definition.
> 
> I would love to see convenience typealiases supported in protocols 
> eventually, but I actually think that should wait until after the transition 
> to `associatedtype` is well behind us so we can get people used to the new 
> keyword.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

Re: [swift-evolution] ternary operator ?: suggestion

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jan 4, 2016, at 5:45 PM, Charles Constant  wrote:
> 
> Our ternary-like switch is now in the "commonly_proposed.md" file, which 
> doesn't bode very well. It puzzles me that there isn't more enthusiasm. Are 
> we the only ones who get irritated taking up so much space with a "switch" 
> when all we need to do is transform between two sets of values?

The ternary-like switch expression is not on the list.  Changing or removing 
ternary itself as well as turning if / else and switch into expressions are on 
the list.

I think some potential issues with ternary-like switch may have come up but 
maybe they can be resolved.  If not, I don't think we will see progress in this 
area in the near future.

> 
> I think we need to revamp the proposal somehow to make the idea clearer, 
> because it ought to be pretty compelling.
> 
> • Does anyone here have better "side by side" examples of code before/after? 
> 
> • Can anyone think of a way to revise the (English) language of the proposal 
> to make it shorter and sweeter? 
> 
> Apologies for prescribing instead of doing. My only excuse is that I'm "too 
> busy"
> 
> 
> 
> 
>> On Mon, Jan 4, 2016 at 3:03 PM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>>> On Jan 4, 2016, at 2:37 PM, Paul Ossenbruggen via swift-evolution 
>>>  wrote:
>>> 
>>> Good feedback, I am all for making it feel more like swift. Any ideas would 
>>> be welcome. I will also try to come up with some myself. 
>> 
>> My suggestion is to leave ternary alone and try to come up with a 
>> ternary-like switch expression that is workable.  I think that is likely the 
>> best change possible at this point.
>> 
>>> 
>>> 
 On Jan 4, 2016, at 12:34 PM, Rod Brown  wrote:
 
 For all the proposals I've seen on this topic, I have to say -1.
 
 While I agree with the notions surrounding this operator, I've yet to see 
 a better alternative presented, and none that feel truly Swift.
 
 If someone has a great proposal, though, I look forward to seeing it.
 
 - Rod
 
> On 5 Jan 2016, at 7:28 AM, Howard Lovatt via swift-evolution 
>  wrote:
> 
> -1 for me. None of it looks or feels like Swift, more like Haskell. I 
> would prefer a library solution for now and remove ?: from the language 
> and add a which into the standard library and see how that goes and if 
> there is need for more.
> 
> Sorry,
> 
> Howard.
> 
>> On 5 Jan 2016, at 7:24 AM, Paul Ossenbruggen via swift-evolution 
>>  wrote:
>> 
>> Any feedback on this? I am rethinking the idea of #( because of the # 
>> prior usage as a preprocessor directive, but like how it stands out and 
>> has a meaning.  If no feedback, does it make sense to update my proposal 
>> with these ideas? Or does this feel like the wrong direction. 
>> 
>> 
>>> On Dec 30, 2015, at 8:52 AM, Paul Ossenbruggen  wrote:
>>> 
>>> Some more ideas, this moves away from the notion that we should make it 
>>> look really close to the ternary but keeps all the benefits of the 
>>> ternary and improves upon it. Since I have been suggesting a breaking 
>>> change, it is a good time to rethink it a bit. With this idea a 
>>> horizontal line (double-dash) separates the control value from the 
>>> choices, the vertical line (bar) indicates none of the above. 
>>> 
>>> Rather than use the ?( as I have suggested in the past, I think #( 
>>> works here, where you can think of it as a numerical index. The 
>>> advantage of this is, it stands out better and leaves ? for optionals 
>>> only. This works well with the list form. In the enum case the index is 
>>> the enum key. I can see that this however may be a problem because # is 
>>> used for preprocessor like directives. I am suggesting though just the 
>>> #( sequence is treated differently. Or the ?( is fine with me as well.
>>> 
>>> I have gone through a lot of options, some others I looked at are !( 
>>> which could be read as "match stick” paren, where the word “match” 
>>> matches a case, I am pretty sure that would not be considered any 
>>> better than ?( because it is used for optionals. Another is “witch hat 
>>> paren” ^( which can be read as “which”.  This might create a parse 
>>> problem with "power of" though, which maybe using ^[ (hat square 
>>> bracket) could resolve that but not sure if that would create other 
>>> problems. Some other choices would be &(  and @( but did not choose 
>>> them because  they don’t have meaning to me but they do have the 
>>> advantage of standing out like the #(. 
>>> 
>>> let fa = #(truth -- 1 | 0) // boolean case. 
>>> let fb = #(pickOne -- "A", 

Re: [swift-evolution] [Draft Proposal] Require `final` on protocol extension members

[Goffredo Marocchi via swift-evolution]

I agree with you, if we tackle this and we should then we should aim to the 
right solution if it is reachable. 
I know I am in the minority and it is partially off topic here, but I do feel 
that default method implementations are something that might be put to good 
use, but it is best to try to make sure no unintentional side effects are 
produced too easily. In a way you give out a possibly dangerous tool, you have 
protocols and you pass around objects referenced not by the actual type but by 
the protocol it is represented by to make sure that the receiver cannot make 
any assumption on the actual implementation beyond the abstract API contract 
and default methods do expose that. 

Sent from my iPhone

> On 5 Jan 2016, at 00:11, Rod Brown via swift-evolution 
>  wrote:
> 
> Sorry Brent, I obviously didn’t read down to the alternatives section. Stupid 
> me.
> 
> I think that it is a larger change, but if we’re going to change this, 
> shouldn’t we do it right?
> 
> From my perspective, a protocol says what “should” happen, whereas a type is 
> where it eventually “does” happen. I find it a little backwards to make 
> protocol extensions mandatorily final. It blocks out the power of defaulting. 
>  I definitely agree with you that final in protocol extensions is a great 
> idea, though.
> 
> 
>>> On 5 Jan 2016, at 10:13 AM, Brent Royal-Gordon  
>>> wrote:
>>> 
>>> The question then becomes simple: should a type gave the right to replace 
>>> the value in the protocol? Should protocol extensions therefore only be 
>>> defaults?
>>> 
>>> I would argue for treating the protocol as a default. If you had an 
>>> identical member in the type, use the type rather than the protocol 
>>> extension. This allows the most flexibility. That said, I am aware that 
>>> means that some optimisations are not possible. I simply think this makes 
>>> the most sense from a programming perspective.
>> 
>> I discuss this in the Alternatives section:
>> 
>>> ### Dynamically dispatch calls to protocol extension members
>>> 
>>> This would fix the underlying problem—the confusing behavior—by making 
>>> protocol extension members not behave confusingly.
>>> 
>>> This would likely take a redesign of protocol witnesses to include 
>>> extension methods not listed in the original protocol. It's probably not 
>>> impossible—class extensions behave this way—but it's a much bigger change 
>>> than what I propose, which keeps the current runtime semantics and only 
>>> adds compile-time errors and keywords.
>>> 
>>> Dynamically dispatching to protocol extension members would also change the 
>>> performance characteristics of these calls. Even if this change were made, 
>>> we might want to allow users to apply `final` to extension methods which 
>>> they want to be dispatched statically.
>> 
>> Basically, I'm not proposing that simply because it's a larger change and 
>> would take redesigning that would have to wait until at least Swift 3, and 
>> is well beyond my own ability to specify or even evaluate the feasibility 
>> of. Plus, as I said in that last paragraph, `final` protocol extension 
>> members may be useful even if we do treat extension members as equivalent to 
>> defaulted protocol members.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Proposal] Lock file for Swift Package Manager

[Max Howell via swift-evolution]

>> I think #2 is the correct choice because if the lockfile is present then the 
>> team that works here is stating that they *want* their team to use those 
>> dependencies. And they want everyone on their team to be using the exact 
>> same sources so any bugs reported do not have to take into account any 
>> variation in dependency sources.
> 
> Completely agree — except that according to the proposal, the lockfile is 
> generated *every* time `swift build` is run (assuming a lockfile doesn't 
> already exist). So we can't really treat its presence as indicating some sort 
> of intention. It's going to be there all the time for everyone whether they 
> understand it, want to use it, or not. Unless I'm missing something?
> 
> Actually, if we changed this part of the proposal such that the lockfile 
> would *only* be generated explicitly (in response to `swift build --lock`, 
> for example?), I'd be in agreement with you that vanilla `swift build` should 
> always use the lockfile by default. For, in this case, there would be only 
> two ways a lockfile could exist: 
> 
> 1) you explicitly create it 
> 2) the team/maintainers of the code think it's important 
> 
> In either case, building with the lockfile is clearly the Right Thing to do.
> 
> This feels like a much more fruitful compromise than per-project, per-user 
> overrides… assuming anyone else is on board with forcing lockfile creation to 
> be explicit. Thoughts?

I think it is reasonable to always create it, you don’t *have* to commit it and 
check-it-in.

By always creating it we are suggesting the file is important, and that you 
*should* check it in. Which is right, it is important, and you *should* check 
it in. However you don’t *have* to, and when it comes to development, it is 
important to offer choices.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal]: Drastically improve searching API (indexOf(…)) of CollectionType

[Vincent Esche via swift-evolution]

That was my reasoning behind choosing Indexable and not CollectionType.

Neither the Swift documents, nor the “headers” indicate any semi-privateness of 
Indexable, AFAIK.
(Apart from maybe Base._Element kind of hinting at it, but then again it’s 
Indexable, not _Indexable.)

Anyway, I’d be totally fine with sticking it on CollectionType, if that’s 
preferred.

Vincent

> On 05 Jan 2016, at 00:58, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> The proposed additions to Indexible only require Indices… I don't see how 
> adding them is such a mistake. If we can gain these behaviors while only 
> *requiring* that minimum interface… go for it.
> 
> TJ
> 
> On Mon, Jan 4, 2016 at 3:49 PM, Brent Royal-Gordon via swift-evolution 
> > wrote:
> I'm not sure about the rest of this, but...
> 
> >> 1. A backwards-compatible refactoring of `CollectionType.indices`, moving 
> >> it to `Indexable`.
> >>
> >> 2. A backwards-compatible refactoring of `indexOf(…)` (adding optional 
> >> `range:` and moving it to `Indexable`).
> >>
> >> 3. The addition of `rangeOf(…)`, `countOf(…)` and `isSorted(…)` to 
> >> `Indexable` with a TIME complexity of `O(self.count)`.
> >>
> >> 4. The introduction of a `BinarySearchView` on `Indexable`, allowing for 
> >> fast (`O(log2(self.count))`) searches on `Indexable` via `indexOf(…)`, 
> >> `rangeOf(…)`, `countOf(…)`, `lowerBoundOf(…)`, `upperBoundOf(…)` without 
> >> cluttering `Indexable`'s interface.
> 
> I don't think you quite understand what `Indexable` is for.
> 
> `Indexable` is a minimal protocol containing the very most basic parts of 
> `CollectionType`'s interface. It's used to avoid circular definitions in 
> `CollectionType`. The doc comments on it describe it as "almost an 
> implementation detail". I don't think it's appropriate to move a whole bunch 
> of stuff into `Indexable` when it's supposed to be a minimal protocol.
> 
> --
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[plx via swift-evolution]

On a re-read I am -1; I like the `associatedtype` keyword but didn’t realize 
there was no plan to let `typealias` be used within a protocol to as a 
convenience (and to preserve intent, and to improve the development experience 
when still figuring out an interface design).

I would prefer the new keyword and also adding/allowing one to add convenience 
typealiases within a protocol definition.

I have not followed the discussion closely to know if there are difficult 
technical issues with permitting both `associatedtype` declarations and simple 
convenience `typealias` declarations within a protocol, or if the current 
proposal is simply making the possible-confusion argument; if there are legit 
technical issues then so be it, but if it’s just an 
argument-from-possible-confusion I think the price of clarity is dearer than it 
needs to be here.

> On Jan 3, 2016, at 1:38 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "Replace `typealias` keyword with `associatedtype` for 
> associated type declarations” begins now and runs through Wednesday, January 
> 6th. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md
>  
> 
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
>   Cheers,
>   Doug Gregor
>   Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] ternary operator ?: suggestion

[Matthew Johnson via swift-evolution]

> On Jan 4, 2016, at 2:37 PM, Paul Ossenbruggen via swift-evolution 
>  wrote:
> 
> Good feedback, I am all for making it feel more like swift. Any ideas would 
> be welcome. I will also try to come up with some myself. 

My suggestion is to leave ternary alone and try to come up with a ternary-like 
switch expression that is workable.  I think that is likely the best change 
possible at this point.

> 
> 
>> On Jan 4, 2016, at 12:34 PM, Rod Brown > > wrote:
>> 
>> For all the proposals I've seen on this topic, I have to say -1.
>> 
>> While I agree with the notions surrounding this operator, I've yet to see a 
>> better alternative presented, and none that feel truly Swift.
>> 
>> If someone has a great proposal, though, I look forward to seeing it.
>> 
>> - Rod
>> 
>> On 5 Jan 2016, at 7:28 AM, Howard Lovatt via swift-evolution 
>> > wrote:
>> 
>>> -1 for me. None of it looks or feels like Swift, more like Haskell. I would 
>>> prefer a library solution for now and remove ?: from the language and add a 
>>> which into the standard library and see how that goes and if there is need 
>>> for more.
>>> 
>>> Sorry,
>>> 
>>> Howard.
>>> 
 On 5 Jan 2016, at 7:24 AM, Paul Ossenbruggen via swift-evolution 
 > wrote:
 
 Any feedback on this? I am rethinking the idea of #( because of the # 
 prior usage as a preprocessor directive, but like how it stands out and 
 has a meaning.  If no feedback, does it make sense to update my proposal 
 with these ideas? Or does this feel like the wrong direction. 
 
 
> On Dec 30, 2015, at 8:52 AM, Paul Ossenbruggen  > wrote:
> 
> Some more ideas, this moves away from the notion that we should make it 
> look really close to the ternary but keeps all the benefits of the 
> ternary and improves upon it. Since I have been suggesting a breaking 
> change, it is a good time to rethink it a bit. With this idea a 
> horizontal line (double-dash) separates the control value from the 
> choices, the vertical line (bar) indicates none of the above. 
> 
> Rather than use the ?( as I have suggested in the past, I think #( works 
> here, where you can think of it as a numerical index. The advantage of 
> this is, it stands out better and leaves ? for optionals only. This works 
> well with the list form. In the enum case the index is the enum key. I 
> can see that this however may be a problem because # is used for 
> preprocessor like directives. I am suggesting though just the #( sequence 
> is treated differently. Or the ?( is fine with me as well.
> 
> I have gone through a lot of options, some others I looked at are !( 
> which could be read as "match stick” paren, where the word “match” 
> matches a case, I am pretty sure that would not be considered any better 
> than ?( because it is used for optionals. Another is “witch hat paren” ^( 
> which can be read as “which”.  This might create a parse problem with 
> "power of" though, which maybe using ^[ (hat square bracket) could 
> resolve that but not sure if that would create other problems. Some other 
> choices would be &(  and @( but did not choose them because  they don’t 
> have meaning to me but they do have the advantage of standing out like 
> the #(. 
> 
> let fa = #(truth -- 1 | 0) // boolean case. 
> let fb = #(pickOne -- "A", "B", "C", "D", "E", "F", "G" | "Z”) // list 
> form, pick index, zero based. 
> let fc = #(color -- .Red: 0xFF, .Green: 0x00FF00, .Blue: 0xFF | 
> 0xFF) // enum form.
> let fd = #(color -- .Red:0xFF, 
>   .Green:  0x00FF00, 
>   .Blue:   0xFF 
>   | 0xFF) // enum multiline, default: can be used here if 
> preferred.
> let fe = #(color -- .Red:0xFF, 
>   .Green:  0x00FF00, 
>   .Blue:   0xFF) // if all cases handled, the last bar is 
> optional
> 
> This visually kind of represents what is going on. Horizontal-line 
> directs eye to one of the normal choices. Vertical-line says none found 
> stop looking and do the otherwise choice. Kind of like a train switch. 
> 
> The strong feedback was that a replacement has to be usable in places 
> where a ternary could be used. So it needs to work on a single line (and 
> multiline) and needs to be compact. By having a compact, “else" that is 
> possible on a single line. 
> 
> Comparisons to ternary and other approaches:
> • It is very concise like ternary and can fit in places that a ternary 
> does.
> • The horizontal line serves to 

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Brent Royal-Gordon via swift-evolution]

> On a re-read I am -1; I like the `associatedtype` keyword but didn’t realize 
> there was no plan to let `typealias` be used within a protocol to as a 
> convenience (and to preserve intent, and to improve the development 
> experience when still figuring out an interface design).
> 
> I would prefer the new keyword and also adding/allowing one to add 
> convenience typealiases within a protocol definition.

I would love to see convenience typealiases supported in protocols eventually, 
but I actually think that should wait until after the transition to 
`associatedtype` is well behind us so we can get people used to the new keyword.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Proposal]: Drastically improve searching API (indexOf(…)) of CollectionType

[Vincent Esche via swift-evolution]

There are a couple of things I’m not 100% happy with/sure about:

1.
I don’t like how it’s
“Of(element:range:)” but 
“Of(range:predicate:)”.
The reason I went for “Of(range:predicate:)” was to go with 
the standard pattern of putting closures last and thus allowing for trailing 
closure syntax.

The current order allows for this:
“Of(0..10)  { $0.name == “Foobar" }”
which I like syntax-wise.
It however makes it look like one was looking for a range ("indexOf(0..10, 
…)”), not the predicate.

While the alternative requires this:
“Of(predicate: { $0.name == “Foobar" }, range: 0..10)”

I’m actually leaning towards the latter now. Dang!

2.
I’m unsure about the name of “lensView”. I first went with “transform”, then 
with “mappingFunction”, but found that neither of those made it clear that the 
closure should provide a specific view into the element.  Both “transform" and 
“mappingFunction” imply the transformation from one data type to another. It’s 
not about transforming. It’s about accessing.
Thus looked for names of similar patterns and found “keypaths” (kind of) in 
ObjC and lenses in Haskell. To people familiar with functional programming the 
name should be clear. The closure passed to “lensView” is basically the getter 
part of a functional lens.
Anyway, I’m not too attached to the name and more than open to suggestions.

3.
“BinarySearchView.init(base:validateAgainst:)” currently asserts. This should 
probably be split into two init functions. One assuming the base to be sorted 
(“BinarySearchView.init(base:)”, O(1)). And one allowing for a check, returning 
nil on failure (“BinarySearchView.init?(base:validateAgainst:)”, 
O(self.count)). Or should at least throw an error, instead of panicking.

Note: I made some minor documentation changes/fixes.
See https://gist.github.com/regexident/2b7531bd748f57679671 
 for up-to-date 
RFC/source code (vs. Markdown-dump at bottom of OP).

- Vincent

> On 04 Jan 2016, at 16:13, Vincent Esche  
> wrote:
> 
> After having had this code laying around on my Mac since 6/26/15 (waiting for 
> Swift to go open source)
> I figured it’s about damn time I submit the actual RFC for it. So without 
> further ado…
> 
> One of the areas where Swift’s stdlib is still quite lacking is searching.
> Which is a shame as searching (along with indexing) might be among
> the most important tasks of computer science/software development.
> One might not need fast collection searches for writing a banal fart or 
> flashlight app,
> but almost every other app is likely to benefit from having a proper 
> searching API.
> 
> So I’d like to fix that.
> 
> Attached you find a full RFC along with the full and functional source code 
> to make it happen.
> 
> I’d love to hear your opinion on this and will be more than happy to answer 
> questions.
> 
> Rendered Version + Full Implementation: 
> https://gist.github.com/regexident/2b7531bd748f57679671 
> 
> (The code is tested using Quick/Nimble. Tests would thus have to be ported to 
> Swift’s XCTest.)
> 
> - Vincent
> 
>> Markdown-dump for
>> 
>> # Improved Collection Search
>> 
>> * Proposal: 
>> [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md
>>  
>> )
>> * Author(s): [Vincent Esche](https://github.com/regexident 
>> )
>> * Status: **Review**
>> * Review manager: TBD
>> 
>> ## Introduction
>> 
>> This RFC proposes an extension to the currently rather limited and linear 
>> searching API of `CollectionType`, that is `indexOf(element:)` and 
>> `indexOf(predicate:)`.
>> It proposes the backwards-compatible refactoring of those existing methods 
>> as well as the introduction of a view-based ensemble of methods for 
>> efficient binary-search.
>> 
>> Swift-evolution thread: [link to the discussion thread for that 
>> proposal](https://lists.swift.org/pipermail/swift-evolution 
>> )
>> 
>> ## Motivation
>> 
>> Indexing of and searching in data is a big deal in software development. As 
>> such it is crucial to have capable means of doing so in a language that 
>> aspires to be a highly performant programming language.
>> 
>> Swift's current API for searching is basically limited to these two methods 
>> on `CollectionType`:
>> 
>> > ```swift
>> > func indexOf(element: Self.Generator.Element) -> Self.Index?
>> > ```
>> > Returns the first index where value appears in self or nil if value is not 
>> > found.
>> >
>> > **Complexity**: `O(self.count)`.
>> 
>> and:
>> 
>> > ```swift
>> > func indexOf(@noescape predicate: (Self.Generator.Element) throws -> Bool) 
>> > rethrows -> Self.Index?
>> > ```
>> > Returns the first index where predicate returns true for the corresponding 
>> > value, or nil if such 

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

I can work on making the proposal shorter if that will help.  Any suggestions, 
for what could be made better. I am trying to be detailed but maybe that is 
making it too long. 

I am also not sure why this is not getting people excited. This seems like a 
clear win to me just being able to use  auto type inference when initializing 
it compared to switch statements is huge. I feel like I have tried to address 
most of the objections and what I am suggesting is quite a bit better than 
ternary, but with any solution there will be something that involves a trade 
off, these are problems with ternary as well. 

• terse but hard to understand.
• more descriptive but longer. 

These are conflicting problems and you can’t solve both but there is nothing so 
magical about the ternary that I can see. The problems I see with ternary:

• hard to see beginning and end **
• not immediately obvious what it does
• can’t be searched on the web **
• only supports boolean and can’t support more than two outcomes. ** 
• does not support switch like capabilities **

Good aspects of ternary:
• Terse **
• Fits in small places can be formatted multiline or single line. **
• guarantees the return type is compatible. **
• it is well known by C like language users
• it does not interrupt the control flow like an if statement does. So the code 
is linear. **
• you are guaranteed a result. **
• Automatically will infer type when binding a name. ** 
• reduces duplicated code. ** 
• quick conversions are possible. **  

All the items with ** stars next to them are addressed with the proposal others 
are no worse than ternary. 

And it adds some things:
• Adds switch expressions
• Adds using a zero based index to execute an expression. 
• Lets you easily see begin and end of the expression
• Different but better
• Supports more than two outcomes. 

Downsides:
• breaking change (I think there is value in a unified approach to doing 
expressions like this, we could leave ternary alone and adapt the rest of the 
proposal though, this has the downside that there are two ways of doing 
booleans though). 
• not as immediately as familiar as ternary (but similar enough that anyone who 
knows about ternary will quickly adapt). 

> On Jan 4, 2016, at 3:45 PM, Charles Constant  wrote:
> 
> Our ternary-like switch is now in the "commonly_proposed.md 
> " file, which doesn't bode very well. It 
> puzzles me that there isn't more enthusiasm. Are we the only ones who get 
> irritated taking up so much space with a "switch" when all we need to do is 
> transform between two sets of values?
> 
> I think we need to revamp the proposal somehow to make the idea clearer, 
> because it ought to be pretty compelling.
> 
> • Does anyone here have better "side by side" examples of code before/after? 
> 
> • Can anyone think of a way to revise the (English) language of the proposal 
> to make it shorter and sweeter? 
> 
> Apologies for prescribing instead of doing. My only excuse is that I'm "too 
> busy"
> 
> 
> 
> 
> On Mon, Jan 4, 2016 at 3:03 PM, Matthew Johnson via swift-evolution 
> > wrote:
> 
>> On Jan 4, 2016, at 2:37 PM, Paul Ossenbruggen via swift-evolution 
>> > wrote:
>> 
>> Good feedback, I am all for making it feel more like swift. Any ideas would 
>> be welcome. I will also try to come up with some myself. 
> 
> My suggestion is to leave ternary alone and try to come up with a 
> ternary-like switch expression that is workable.  I think that is likely the 
> best change possible at this point.
> 
>> 
>> 
>>> On Jan 4, 2016, at 12:34 PM, Rod Brown >> > wrote:
>>> 
>>> For all the proposals I've seen on this topic, I have to say -1.
>>> 
>>> While I agree with the notions surrounding this operator, I've yet to see a 
>>> better alternative presented, and none that feel truly Swift.
>>> 
>>> If someone has a great proposal, though, I look forward to seeing it.
>>> 
>>> - Rod
>>> 
>>> On 5 Jan 2016, at 7:28 AM, Howard Lovatt via swift-evolution 
>>> > wrote:
>>> 
 -1 for me. None of it looks or feels like Swift, more like Haskell. I 
 would prefer a library solution for now and remove ?: from the language 
 and add a which into the standard library and see how that goes and if 
 there is need for more.
 
 Sorry,
 
 Howard.
 
> On 5 Jan 2016, at 7:24 AM, Paul Ossenbruggen via swift-evolution 
> > wrote:
> 
> Any feedback on this? I am rethinking the idea of #( because of the # 
> prior usage as a preprocessor directive, but like how it stands out and 
> has a meaning.  If no feedback, does it make sense to update my proposal 
> with 

Re: [swift-evolution] Changing postfix "self" to something clearer like "type"

[Brandon Knope via swift-evolution]

I have been sitting on a response to this for a while for a few reasons.
1. I didn’t see much interest generated in proceeding with a proposal
2. I have been trying very *hard* to get “SomeType.self” as “SomeType itself, 
rather than an instance of it” into my head.

My problem is it still does not seem 100% obvious and looks somewhat awkward at 
first glance.

I mean it’s obvious when the type name is SomeType so you *know* it’s a type. 
If the type is Mood and you see Mood.self this doesn’t seem as obvious to me.

There has to be a swifter way to do this, but I am not quite sure I’ve found it 
yet

Brandon

> On Dec 15, 2015, at 1:24 PM, Jordan Rose  wrote:
> 
> ".self" was chosen for a few reasons:
> 
> - The obvious choice was ".class", given precedent in Objective-C and Java, 
> but not all types are classes.
> - 'type' is a very common property name, so we have tried very hard to avoid 
> taking it as a general keyword.
> - 'type' also always implies going up a level. "obj.dynamicType" gives you 
> back the type of 'obj', so wouldn't "SomeClass.type" give you back the 
> metaclass 
> ?
>  (Alternately, "SomeType.staticType' not being the same as 
> 'SomeType.dynamicType" seems weird.)
> - 'self' is already a keyword.
> - ".self" actually works in Objective-C as well.
> - ".self" currently also applies to instances, doing exactly what you think 
> it does. This is nearly useless. In theory you could use it to unwrap one 
> level of optionality ("doubleOpt?.self") but that doesn't actually work today.
> 
> I read "SomeType.self" as "SomeType itself, rather than an instance of it (or 
> associated type)".
> 
> (And before someone brings it up, we chose not to just allow "SomeType" on 
> its own because "let x = SomeType" is a likely typo for "let x: SomeType".)
> 
> I think coming up with a clearer name is possible here, but there's plenty to 
> consider. Still, certainly a reasonable thing to bring up.
> 
> Best,
> Jordan
> 
>> On Dec 15, 2015, at 8:42 , Brandon Knope via swift-evolution 
>> > wrote:
>> 
>> Doh! staticType is the obvious choice!
>> 
>> I agree that adding more keywords can be bad, but in this case I think the 
>> clarity outweighs any downside:
>> 
>> SomeType.staticType
>> SomeType.self 
>> 
>> To me (and I'm sure many others) one is vastly more obvious and easier to 
>> understand. 
>> 
>> I still don't really understand what SomeType.self is trying to convey upon 
>> first glance
>> 
>> Brandon 
>> 
>> Sent from my iPad
>> 
>> On Dec 15, 2015, at 11:34 AM, Dennis Lysenko > > wrote:
>> 
>>> +1. Side effects can be eliminated through code migration if a suitable 
>>> property name is chosen. Perhaps `staticType` to continue in the vein of 
>>> `dynamicType`? 
>>> 
>>> Main detractor is that creating more keywords isn't necessarily a good 
>>> thing.
>>> 
>>> On Tue, Dec 15, 2015 at 11:19 AM Brandon Knope via swift-evolution 
>>> > wrote:
>>> One area of swift that is really not clear to me is when you want to use 
>>> the type of a class, struct, enum, etc as a value. 
>>> 
>>> Metatyping is explained here: 
>>> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/doc/uid/TP40014097-CH31-XID_1022
>>>  
>>> 
>>> 
>>> Example: 
>>> let metatype: SomeClass.Type = SomeClass.self
>>> 
>>> Is there a reason why this isn't SomeClass.type? Everywhere in the document 
>>> this is explained as returning the type yet it's using a postfix self to 
>>> access the type. 
>>> 
>>> I propose changing the postfix self to something more obvious like "type"
>>> 
>>> Going back to the example:
>>> let metatype: SomeClass.Type = SomeClass.type
>>> 
>>> Several reasons why I think this is better:
>>> 1. Postfix self is not obvious as an option as you never see a postfix self 
>>> anywhere else 
>>> 2. "self" does not clearly explain that the type is being returned 
>>> 3. ObjC programmers are familiar with accessing the class type by sending 
>>> the "class" method to the class type. In this case it needs to work on 
>>> structs and enums, so a "type" method would make more sense. 
>>> 4. Instances have a dynamicType method. For consistency, classes, structs, 
>>> etc., should have a type method
>>> 
>>> Any other suggestions would be welcome. 
>>> 
>>> Brandon 
>>> 
>>> Sent from my iPad
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> 

Re: [swift-evolution] [Draft Proposal] Require `final` on protocol extension members

[Brent Royal-Gordon via swift-evolution]

> Didn't we already have a very long discussion about all of this?

We did, which ended with you and I clearly in fundamental disagreement, while 
others appeared to think it was a good idea. I'm now putting forth a more 
specific version of that proposal, one that I think is almost ready for review.

> It's confusing, it's overloading the term `final` in a way that doesn't seem 
> to make sense (`final` means you can't subclass or override, but there's 
> nothing in this proposal that affects either subclassing _or_ method 
> overriding)

`final` is currently restricted to the context of a class, yes. But I think 
it's a clean extension of the concept to use it to mark protocol extension 
methods that can't be overridden. Hence why I provide this re-definition of the 
meaning of `final`:

`final` declares that subtypes of this type must use this specific 
implementation of the member, and cannot substitute their own specialized 
implementation. Attempting to do so causes an error.

(Technically it's true that no protocol extension member can be overridden. But 
the distinction between defaulted protocol members and protocol extension 
members is very subtle—they are both written in protocol extensions and look 
identical unless you go back to the protocol definition to check what's 
there—and I think it needs to be called out in the text of the code.)

> and it means protocol extensions that you aren't even aware of from other 
> modules can cause your otherwise-legal type to start throwing errors.


You can only get a conflict from something that's visible to your code. For 
instance, an `internal` protocol extension in another module can't cause a 
conflict—only public APIs can cause conflicts through imports. And it's 
important that they do, because it's hard to know that you didn't think the 
conflicting member was a defaulted protocol requirement you could override.

> Making this kind of change only makes any sense at all if you assume that, 
> every single time someone implements a method that happens to look the same 
> as a method provided by a protocol extension, they're trying to override that 
> protocol extension method. But since protocol extension methods cannot be 
> overridden (merely shadowed), that assumption doesn't make a lot of sense.

I realize that this doesn't confuse you, but it seems to confuse everyone else. 
The core team seems to think so too, because they consider the lack of a 
warning about it to be a bug that can be fixed without going through the 
evolution process. (And I believe there's a thread currently in swift-dev where 
someone is working on that warning.)

> and I think forcing people to brand their legitimate functions with a 
> negative-sounding term "incoherent" is also basically subtly punishing 
> people. I mean, who wants to write code that is publicly branded as being 
> "incoherent" code?


"Incoherent" is a very opinionated keyword. But I think it's also a descriptive 
one, which captures in a single word why you may not want to use it. I'm open 
to alternatives, including less judgmental alternatives.

> Also, even after reading this proposal, it's still not obvious to me how the 
> @incoherent attribute works. The rest is a little confusing, but this 
> attribute is very confusing all by itself.

`@incoherent` basically says "I know what I'm doing, so don't emit errors about 
conflicts between these two types; just give me the Swift 2.1 behavior". I'm 
not sure why you think the current behavior is not confusing, but 
`@incoherent`'s behavior is very confusing.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Testing Assertions

[Tony Parker via swift-evolution]

Hi Mohamed,

I agree it’s very difficult to test assertions in XCTest today. This approach 
looks interesting, but I’m not sure how it’s possible to implement within 
XCTest’s current architecture. Do you have any idea how this would be 
implemented? 

- Tony

> On Dec 31, 2015, at 1:35 AM, Mohamed Ebrahim Afifi via swift-evolution 
>  wrote:
> 
> Right now, we cannot easily test failed assertions (assert, assertionFailure, 
> precondition, preconditionFailure, fatalError) in our own code without some 
> hacks in the code under test. Like this example 
> https://github.com/mohamede1945/AssertionsTestingExample 
> 
> 
> So, my suggestion is to add for XCTest something very similar to 
> expectCrashLater that is defined here 
> https://github.com/apple/swift/blob/9b15d03b73b9e8a6dbd3f71b5c78660a359e8e26/stdlib/private/StdlibUnittest/StdlibUnittest.swift.gyb
>  
> 
> and used in tests like this example 
> https://github.com/apple/swift/blob/master/validation-test/stdlib/Assert.swift
>  
> 
> 
> What do you think?
> 
> Best Regards,
> Mohamed Afifi
>  ___
> 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 question: Foundation and Standard Library

[Tony Parker via swift-evolution]

Not that I need to say this, but I’ll chime in anyway with a big +1 to what 
Chris said. =)

Fortunately, the current code owners for swift-corelibs-foundation are the same 
people that work on Foundation for all of our other platforms. That means we’re 
in a great position to make Foundation great in Swift everywhere. As Chris 
said, we have a giant task of getting the fundamentals up and running without 
Objective-C, so that is our primary goal for Swift 3. However, we are 
interested in all kinds of improvements in the long term.

Thanks,
- Tony

> On Jan 1, 2016, at 10:32 PM, Rod Brown via swift-evolution 
>  wrote:
> 
> Brilliant. Makes sense and seems to be a best-of-both-worlds approach.
> 
> - Rod
> 
> On 2 Jan 2016, at 3:16 PM, Chris Lattner  wrote:
> 
 On Jan 1, 2016, at 3:32 PM, Rod Brown  wrote:
 Thanks Chris.  I want to figure out what the guiding principles are before 
 I blow any further proposal-capital. This gives me a good place to start 
 chewing on some thoughts.  In particular, I'm considering two scenarios.
 
 First, are things that seem unnaturally split between both places, such as 
 "joinWithSeparator" (stdlib, seq type) and "componentsSeparatedByString" 
 (fnd, NSString). The latter super non-Swifty but could easily evolve to be 
 componentsSeparatedBySequence and rangeOfSequence. (We had some nifty 
 attempts at this last night on #swift-lang in terms of trying to do this 
 with reasonable speed.)
>>> 
>>> I find this a very good point and points to something interesting with 
>>> Swift Foundation.
>>> 
>>> Is it more important to maintain design closely similar to Objective-C 
>>> foundation, or to push for a more "swift" design philosophy that may indeed 
>>> push away from Objective C foundation?
>> 
>> Our goal is to pull the two together, so that Foundation ultimately feels 
>> 100% Swift native.  This is one major reason that we’re doing 
>> corelibs-foundation the way we are in the first place, to force the design 
>> discussions to happen.
>> 
>> We plan to do this through a combination of improving how Swift imports 
>> Objective-C APIs (something that made a lot of progress in Swift 2, and 
>> should make at least some more progress in Swift 3) as well as by adding 
>> “more swifty” interfaces manually where it makes sense (e.g. through 
>> overlays).  This is something you should discuss on a case by case basis 
>> with the corelibs folks, because there is no one blanket answer.
>> 
>>> We are essentially outlining some of the foundational (no pun intended) 
>>> elements of Swift, and a clean, coherent design makes sense. That said, I 
>>> suspect branching away from Objective-C Foundation may create confusion for 
>>> developers who write both for Apple Platforms and for servers - "Am I using 
>>> Swift Foundation, or Objective-C Foundation?”
>> 
>> This would be a pretty big problem, defeating the goal of supporting 
>> cross-platform development with Swift.
>> 
>> -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] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Félix Cloutier via swift-evolution]

For the folks who don't mix Swift and Objective-C that much, extensions on 
@objc classes are exposed to the Objective-C runtime, so there is a discrepancy 
here. I'm not passionate about the outcome, just dropping the info.

Félix

> Le 4 janv. 2016 à 23:32:25, Douglas Gregor via swift-evolution 
>  a écrit :
> 
> Hi all,
> 
> We currently have a bit of a surprise when one extends an @objc protocol:
> 
> @objc protocol P { }
> 
> extension P {
>   func bar() { }
> }
> 
> class C : NSObject { }
> 
> let c = C()
> print(c.respondsToSelector("bar")) // prints "false"
> 
> because the members of the extension are not exposed to the Objective-C 
> runtime. 
> 
> There is no direct way to implement Objective-C entry points for protocol 
> extensions. One would effectively have to install a category on every 
> Objective-C root class [*] with the default implementation or somehow 
> intercept all of the operations that might involve that selector. 
> 
> Alternately, and more simply, we could require @nonobjc on members of @objc 
> protocol extensions, as an explicit indicator that the member is not exposed 
> to Objective-C. It’ll eliminate surprise and, should we ever find both the 
> mechanism and motivation to make default implementations of @objc protocol 
> extension members work, we could easily remove the restriction at that time.
> 
>   - Doug
> 
> [*] Assuming you can enumerate them, although NSObject and the hidden 
> SwiftObject cover the 99%. Even so, that it’s correct either, because the 
> root class itself might default such a method, and the category version would 
> conflict with it, so...
> 
> ___
> 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] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Douglas Gregor via swift-evolution]

> On Jan 4, 2016, at 8:58 PM, John Joyce  wrote:
> 
> Would it not be possible to do the relative analog of Objective-C nullability 
> macro sandwiches in Swift?
> And then allowing exceptions within the file to be called out explicitly with 
> @nonobjc or @objc ?
> @begin_assume_nonobjc
> @end_assume_nonobjc
> @begin_assume_objc
> @begin_assume_objc

Ick :)

If we need to annotate several things at once, doing it an extension 
granularity is good enough, because there’s essentially no cost to merging or 
breaking apart extensions as needed.

- Doug

>> On Jan 5, 2016, at 1:54 PM, Kevin Lundberg via swift-evolution 
>> > wrote:
>> 
>> I like this idea, but I would imagine that for an extension with many 
>> functions in it, requiring @nonobjc on each one would get tedious very fast. 
>> Could it be required (or at least allowed in addition to per-method 
>> annotations) at the extension level?:
>>  
>>  @objc protocol P {}
>>  
>>  @nonobjc extension P {
>>  func foo() { }
>>  func bar() { }
>>  func baz() { }
>>  func blah() { } 
>>  // etc...
>>  }
>> 
>> I don’t know if this would have specific implementation ramifications over 
>> only doing this on each method, if extensions cannot already be modified 
>> with attributes. I can’t think of a case where I’ve seen annotations added 
>> to protocol extensions, or any other extensions for that matter.
>> 
>> 
>>> On Jan 4, 2016, at 11:32 PM, Douglas Gregor via swift-evolution 
>>> > wrote:
>>> 
>>> Hi all,
>>> 
>>> We currently have a bit of a surprise when one extends an @objc protocol:
>>> 
>>> @objc protocol P { }
>>> 
>>> extension P {
>>>   func bar() { }
>>> }
>>> 
>>> class C : NSObject { }
>>> 
>>> let c = C()
>>> print(c.respondsToSelector("bar")) // prints "false"
>>> 
>>> because the members of the extension are not exposed to the Objective-C 
>>> runtime. 
>>> 
>>> There is no direct way to implement Objective-C entry points for protocol 
>>> extensions. One would effectively have to install a category on every 
>>> Objective-C root class [*] with the default implementation or somehow 
>>> intercept all of the operations that might involve that selector. 
>>> 
>>> Alternately, and more simply, we could require @nonobjc on members of @objc 
>>> protocol extensions, as an explicit indicator that the member is not 
>>> exposed to Objective-C. It’ll eliminate surprise and, should we ever find 
>>> both the mechanism and motivation to make default implementations of @objc 
>>> protocol extension members work, we could easily remove the restriction at 
>>> that time.
>>> 
>>> - Doug
>>> 
>>> [*] Assuming you can enumerate them, although NSObject and the hidden 
>>> SwiftObject cover the 99%. Even so, that it’s correct either, because the 
>>> root class itself might default such a method, and the category version 
>>> would conflict with it, so...
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>>  ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 

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

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

[Matthew Johnson via swift-evolution]

> On Jan 4, 2016, at 5:48 PM, Howard Lovatt  wrote:
> 
> Yes you can get close, but:
> 
> 1. Its weird that you can only do this in an extension.

This is the way the current implicit initializer works.  It is not synthesized 
if you define any initializers in the body of the type.  There are good reasons 
it works this way and the current proposal does not change those rules.

> 2. Its not quite the same as the proposal the current member-wise initialiser 
> does not make the init arguments optional (the arguments themselves do not 
> have defaults), i.e. with your example `let defaultOriginRect = Rect(size: 
> Size(width: 5.0, height: 5.0))` fails whereas it would work for the proposal 
> (this could also be true if the existing struct memberwise init and the new 
> `memberwise init(..)` where changed to provide init argument defaults).

The implicit memberwise initializer currently in the language does not provide 
defaults for parameters.  This proposal changes that behavior and provides 
defaults if the the member is a `var` and has an initial value.  

Unfortunately I was not able to find a solution to allow synthesized parameters 
for `let` members to have default values.  This is because the current 
semantics for `let` members do not allow the member to be initialized to 
anything other than the initial value if one is provided.  I am hoping a 
solution to this will be identified in the future and have suggested one 
possible mechanism `@default` in the future enhancements section.

> 3. Only ‘really' works for structs, the compiler doesn’t write a member-wise 
> initialiser for classes (just a default initializer).

That is true about the current behavior of the language but is not true with 
regards to the current proposal.

> 4. Still need the compiler to provide both default and member-wise 
> initialisers, whereas this proposal would allow the existing default and 
> member-wise initialisers to be deprecated and just the new member-wise 
> initialiser would remain which would simplify the language and make it clear 
> what was happening (this could also be true if a `memberwise init(..)` where 
> added and existing compiler written inits removed).

This proposal does not change anything with regard to the default initializer.

> 
> 
>> On 5 Jan 2016, at 10:16 AM, Matthew Johnson > > wrote:
>> 
>> struct Rect { var origin: Point = Point(), size: Size = Size() }
>> extension Rect {
>>init(center: Point, size: Size) {
>>let originX = center.x - (size.width / 2)
>>let originY = center.y - (size.height / 2)
>>self.init(origin: Point(x: originX, y: originY), size: size)
>>}
>> }
> 

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

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Kevin Lundberg via swift-evolution]

I like this idea, but I would imagine that for an extension with many functions 
in it, requiring @nonobjc on each one would get tedious very fast. Could it be 
required (or at least allowed in addition to per-method annotations) at the 
extension level?:

@objc protocol P {}

@nonobjc extension P {
func foo() { }
func bar() { }
func baz() { }
func blah() { } 
// etc...
}

I don’t know if this would have specific implementation ramifications over only 
doing this on each method, if extensions cannot already be modified with 
attributes. I can’t think of a case where I’ve seen annotations added to 
protocol extensions, or any other extensions for that matter.


> On Jan 4, 2016, at 11:32 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> We currently have a bit of a surprise when one extends an @objc protocol:
> 
> @objc protocol P { }
> 
> extension P {
>   func bar() { }
> }
> 
> class C : NSObject { }
> 
> let c = C()
> print(c.respondsToSelector("bar")) // prints "false"
> 
> because the members of the extension are not exposed to the Objective-C 
> runtime. 
> 
> There is no direct way to implement Objective-C entry points for protocol 
> extensions. One would effectively have to install a category on every 
> Objective-C root class [*] with the default implementation or somehow 
> intercept all of the operations that might involve that selector. 
> 
> Alternately, and more simply, we could require @nonobjc on members of @objc 
> protocol extensions, as an explicit indicator that the member is not exposed 
> to Objective-C. It’ll eliminate surprise and, should we ever find both the 
> mechanism and motivation to make default implementations of @objc protocol 
> extension members work, we could easily remove the restriction at that time.
> 
>   - Doug
> 
> [*] Assuming you can enumerate them, although NSObject and the hidden 
> SwiftObject cover the 99%. Even so, that it’s correct either, because the 
> root class itself might default such a method, and the category version would 
> conflict with it, so...
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Douglas Gregor via swift-evolution]

> On Jan 4, 2016, at 2:49 PM, plx via swift-evolution 
>  wrote:
> 
> On a re-read I am -1; I like the `associatedtype` keyword but didn’t realize 
> there was no plan to let `typealias` be used within a protocol to as a 
> convenience (and to preserve intent, and to improve the development 
> experience when still figuring out an interface design).
> 
> I would prefer the new keyword and also adding/allowing one to add 
> convenience typealiases within a protocol definition.

You can evaluate the proposal however you wish, but I don’t think it makes 
sense to vote against a proposal because it is missing some additional feature 
*unless* the lack of that additional feature makes the proposal effectively 
useless. I don’t think that’s the case here: changing ‘typealias’ to 
‘associatedtype’ can easily be viewed as an improvement on its own, which then 
opens the door to additional features (real typealiases in protocols or 
protocol extensions).

- Doug

> 
>> On Jan 3, 2016, at 1:38 AM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "Replace `typealias` keyword with `associatedtype` for 
>> associated type declarations” begins now and runs through Wednesday, January 
>> 6th. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md
>>  
>> 
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>>  * What is your evaluation of the proposal?
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  * Does this proposal fit well with the feel and direction of Swift?
>>  * If you have you used other languages or libraries with a similar 
>> feature, how do you feel that this proposal compares to those?
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>>  https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> 
>>  Cheers,
>>  Doug Gregor
>>  Review Manager
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal]: Drastically improve searching API (indexOf(…)) of CollectionType

[Donnacha Oisín Kidney via swift-evolution]

Unless I’m confused, all of the “ranged” overloads can already be achieved by 
composing ranged subscripts with the indexOf, etc., methods:

let ar = [0, 1, 2, 3, 4, 5]
let ind = ar[3...5].indexOf { n in n % 2 == 0 }
ar[ind!] // 4

> On 5 Jan 2016, at 01:00, Vincent Esche via swift-evolution 
>  wrote:
> 
> There are a couple of things I’m not 100% happy with/sure about:
> 
> 1.
> I don’t like how it’s
> “Of(element:range:)” but 
> “Of(range:predicate:)”.
> The reason I went for “Of(range:predicate:)” was to go 
> with the standard pattern of putting closures last and thus allowing for 
> trailing closure syntax.
> 
> The current order allows for this:
> “Of(0..10)  { $0.name == “Foobar" }”
> which I like syntax-wise.
> It however makes it look like one was looking for a range ("indexOf(0..10, 
> …)”), not the predicate.
> 
> While the alternative requires this:
> “Of(predicate: { $0.name == “Foobar" }, range: 0..10)”
> 
> I’m actually leaning towards the latter now. Dang!
> 
> 2.
> I’m unsure about the name of “lensView”. I first went with “transform”, then 
> with “mappingFunction”, but found that neither of those made it clear that 
> the closure should provide a specific view into the element.  Both 
> “transform" and “mappingFunction” imply the transformation from one data type 
> to another. It’s not about transforming. It’s about accessing.
> Thus looked for names of similar patterns and found “keypaths” (kind of) in 
> ObjC and lenses in Haskell. To people familiar with functional programming 
> the name should be clear. The closure passed to “lensView” is basically the 
> getter part of a functional lens.
> Anyway, I’m not too attached to the name and more than open to suggestions.
> 
> 3.
> “BinarySearchView.init(base:validateAgainst:)” currently asserts. This should 
> probably be split into two init functions. One assuming the base to be sorted 
> (“BinarySearchView.init(base:)”, O(1)). And one allowing for a check, 
> returning nil on failure (“BinarySearchView.init?(base:validateAgainst:)”, 
> O(self.count)). Or should at least throw an error, instead of panicking.
> 
> Note: I made some minor documentation changes/fixes.
> See https://gist.github.com/regexident/2b7531bd748f57679671 
>  for up-to-date 
> RFC/source code (vs. Markdown-dump at bottom of OP).
> 
> - Vincent
> 
>> On 04 Jan 2016, at 16:13, Vincent Esche > > wrote:
>> 
>> After having had this code laying around on my Mac since 6/26/15 (waiting 
>> for Swift to go open source)
>> I figured it’s about damn time I submit the actual RFC for it. So without 
>> further ado…
>> 
>> One of the areas where Swift’s stdlib is still quite lacking is searching.
>> Which is a shame as searching (along with indexing) might be among
>> the most important tasks of computer science/software development.
>> One might not need fast collection searches for writing a banal fart or 
>> flashlight app,
>> but almost every other app is likely to benefit from having a proper 
>> searching API.
>> 
>> So I’d like to fix that.
>> 
>> Attached you find a full RFC along with the full and functional source code 
>> to make it happen.
>> 
>> I’d love to hear your opinion on this and will be more than happy to answer 
>> questions.
>> 
>> Rendered Version + Full Implementation: 
>> https://gist.github.com/regexident/2b7531bd748f57679671 
>> 
>> (The code is tested using Quick/Nimble. Tests would thus have to be ported 
>> to Swift’s XCTest.)
>> 
>> - Vincent
>> 
>>> Markdown-dump for
>>> 
>>> # Improved Collection Search
>>> 
>>> * Proposal: 
>>> [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md
>>>  
>>> )
>>> * Author(s): [Vincent Esche](https://github.com/regexident 
>>> )
>>> * Status: **Review**
>>> * Review manager: TBD
>>> 
>>> ## Introduction
>>> 
>>> This RFC proposes an extension to the currently rather limited and linear 
>>> searching API of `CollectionType`, that is `indexOf(element:)` and 
>>> `indexOf(predicate:)`.
>>> It proposes the backwards-compatible refactoring of those existing methods 
>>> as well as the introduction of a view-based ensemble of methods for 
>>> efficient binary-search.
>>> 
>>> Swift-evolution thread: [link to the discussion thread for that 
>>> proposal](https://lists.swift.org/pipermail/swift-evolution 
>>> )
>>> 
>>> ## Motivation
>>> 
>>> Indexing of and searching in data is a big deal in software development. As 
>>> such it is crucial to have capable means of doing so in a language that 
>>> aspires to be a highly performant programming language.
>>> 
>>> Swift's current API for searching is basically limited 

[swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Douglas Gregor via swift-evolution]

Hi all,

We currently have a bit of a surprise when one extends an @objc protocol:

@objc protocol P { }

extension P {
  func bar() { }
}

class C : NSObject { }

let c = C()
print(c.respondsToSelector("bar")) // prints "false"

because the members of the extension are not exposed to the Objective-C 
runtime. 

There is no direct way to implement Objective-C entry points for protocol 
extensions. One would effectively have to install a category on every 
Objective-C root class [*] with the default implementation or somehow intercept 
all of the operations that might involve that selector. 

Alternately, and more simply, we could require @nonobjc on members of @objc 
protocol extensions, as an explicit indicator that the member is not exposed to 
Objective-C. It’ll eliminate surprise and, should we ever find both the 
mechanism and motivation to make default implementations of @objc protocol 
extension members work, we could easily remove the restriction at that time.

- Doug

[*] Assuming you can enumerate them, although NSObject and the hidden 
SwiftObject cover the 99%. Even so, that it’s correct either, because the root 
class itself might default such a method, and the category version would 
conflict with it, so...___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[John Joyce via swift-evolution]

Would it not be possible to do the relative analog of Objective-C nullability 
macro sandwiches in Swift?
And then allowing exceptions within the file to be called out explicitly with 
@nonobjc or @objc ?
@begin_assume_nonobjc
@end_assume_nonobjc
@begin_assume_objc
@begin_assume_objc
> On Jan 5, 2016, at 1:54 PM, Kevin Lundberg via swift-evolution 
>  wrote:
> 
> I like this idea, but I would imagine that for an extension with many 
> functions in it, requiring @nonobjc on each one would get tedious very fast. 
> Could it be required (or at least allowed in addition to per-method 
> annotations) at the extension level?:
>   
>   @objc protocol P {}
>   
>   @nonobjc extension P {
>   func foo() { }
>   func bar() { }
>   func baz() { }
>   func blah() { } 
>   // etc...
>   }
> 
> I don’t know if this would have specific implementation ramifications over 
> only doing this on each method, if extensions cannot already be modified with 
> attributes. I can’t think of a case where I’ve seen annotations added to 
> protocol extensions, or any other extensions for that matter.
> 
> 
>> On Jan 4, 2016, at 11:32 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Hi all,
>> 
>> We currently have a bit of a surprise when one extends an @objc protocol:
>> 
>> @objc protocol P { }
>> 
>> extension P {
>>   func bar() { }
>> }
>> 
>> class C : NSObject { }
>> 
>> let c = C()
>> print(c.respondsToSelector("bar")) // prints "false"
>> 
>> because the members of the extension are not exposed to the Objective-C 
>> runtime. 
>> 
>> There is no direct way to implement Objective-C entry points for protocol 
>> extensions. One would effectively have to install a category on every 
>> Objective-C root class [*] with the default implementation or somehow 
>> intercept all of the operations that might involve that selector. 
>> 
>> Alternately, and more simply, we could require @nonobjc on members of @objc 
>> protocol extensions, as an explicit indicator that the member is not exposed 
>> to Objective-C. It’ll eliminate surprise and, should we ever find both the 
>> mechanism and motivation to make default implementations of @objc protocol 
>> extension members work, we could easily remove the restriction at that time.
>> 
>>  - Doug
>> 
>> [*] Assuming you can enumerate them, although NSObject and the hidden 
>> SwiftObject cover the 99%. Even so, that it’s correct either, because the 
>> root class itself might default such a method, and the category version 
>> would conflict with it, so...
>> 
>> ___
>> 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] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Douglas Gregor via swift-evolution]

> On Jan 4, 2016, at 8:49 PM, Félix Cloutier  wrote:
> 
> For the folks who don't mix Swift and Objective-C that much, extensions on 
> @objc classes are exposed to the Objective-C runtime, so there is a 
> discrepancy here. I'm not passionate about the outcome, just dropping the 
> info.

Right. I think this is the reason that developers expect members of @objc 
protocol extensions to show up in Objective-C, because it automatically happens 
for extensions of @objc classes. (We’ve received a number of bug reports about 
this)

- Doug

> 
> Félix
> 
>> Le 4 janv. 2016 à 23:32:25, Douglas Gregor via swift-evolution 
>> > a écrit :
>> 
>> Hi all,
>> 
>> We currently have a bit of a surprise when one extends an @objc protocol:
>> 
>> @objc protocol P { }
>> 
>> extension P {
>>   func bar() { }
>> }
>> 
>> class C : NSObject { }
>> 
>> let c = C()
>> print(c.respondsToSelector("bar")) // prints "false"
>> 
>> because the members of the extension are not exposed to the Objective-C 
>> runtime. 
>> 
>> There is no direct way to implement Objective-C entry points for protocol 
>> extensions. One would effectively have to install a category on every 
>> Objective-C root class [*] with the default implementation or somehow 
>> intercept all of the operations that might involve that selector. 
>> 
>> Alternately, and more simply, we could require @nonobjc on members of @objc 
>> protocol extensions, as an explicit indicator that the member is not exposed 
>> to Objective-C. It’ll eliminate surprise and, should we ever find both the 
>> mechanism and motivation to make default implementations of @objc protocol 
>> extension members work, we could easily remove the restriction at that time.
>> 
>>  - Doug
>> 
>> [*] Assuming you can enumerate them, although NSObject and the hidden 
>> SwiftObject cover the 99%. Even so, that it’s correct either, because the 
>> root class itself might default such a method, and the category version 
>> would conflict with it, so...
>> 
>> ___
>> 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] Better syntax for deferred?

[John McCall via swift-evolution]

> On Jan 4, 2016, at 12:41 PM, Howard Lovatt via swift-evolution 
>  wrote:
> I don’t think it is worth changing from defer to the more traditional try 
> finally block, both have pros and cons. Just work with what we have. You can 
> always, as a matter of style, put a single defer block at the end of scope 
> instead of multiple defers throughout the block.

For what it’s worth, the error-handling rationale discusses the trade-offs of 
the defer syntax.  I think we’re very happy with the current syntax.

John.

> 
> 
>> On 5 Jan 2016, at 1:17 AM, Jeremy Pereira via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On 2 Jan 2016, at 16:49, Maury Markowitz via swift-evolution 
>>> > wrote:
>>> 
 On Jan 2, 2016, at 9:38 AM, Nicky Gerritsen > wrote:
 
 Defer is used to make code *always* run, even if the function terminates 
 early. Imagine:
>>> 
>>> Which is precisely why I called it 'always'. So in your example:
>>> 
>>>   func doSomethingWith(x: Int) {
>>> print(“1”)
>>> defer { print(“2") }
>>> if x > 3 { defer { print(“yay”); return }
>>> print(“3”)
>>>   }
>>> 
>>> I would say:
>>> 
>>>   func doSomethingWith(x: Int) {
>>> print(“1”)
>>> print(“3”)
>>>   always {
>>>   print(“2")
>>>   if x > 3 { print(“yay”) }
>>>   }
>>>   }
>>> 
>>> This is functionally identical, but both the syntax and program flow are 
>>> greatly improved.
>> 
>> No your example is not functionally identical to Nicky’s (notwithstanding 
>> the missing closing brace in the original). “defer" defers the closure to 
>> the end of the current scope. In this instance , that is the end of the if 
>> block. The “yay” must come before the “2” because the if scope exits before 
>> the function scope. Also, in the following:
>> 
>> func doSomethingWith(x: Int) {
>>print("1")
>>defer { print("2") }
>>if x > 3 { defer { print("yay") } }
>>print("3")
>> }
>> 
>> doSomethingWith(4)
>> 
>> “yay” comes before “3” for the same reason.
>> 
>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] [Proposal]: support disable to trailing closure syntax

[QQ Mail via swift-evolution]

Hi, All: 
trailing closure is good for most cases, but sometimes it is also make 
code unclear, for example: 

UIView.animateWithDuration(0.3, animations: { () -> Void in
// animation code here
}) { (Bool) -> Void in
// completion code here
}

the label been removed and the code also not aligned well. 
I would like to write like this: 

UIView.animateWithDuration(0.3,

animations: { () -> Void in
// animation code here
},
completion: { Bool -> Void in
// completion code here
}
)

It is possible, just every time you have to write it manually. It’s a little 
wast.
So I have a thought, since we already know this function is not well suit for 
trailing 
closure, can we add a attribute to disable it, for example: 

extension UIView {

@disable_trailing_closure
public static func animateWithDuration(duration:NSTimeInterval, 
animations:()->Void, completion:()->Void) {
// implementations ...
}
}

I also found another one have issue for this too. link: 
http://www.natashatherobot.com/swift-trailing-closure-syntax/ 

what do you think?

Best Regards

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

[swift-evolution] [Draft Proposal] Require `final` on protocol extension members

[Brent Royal-Gordon via swift-evolution]

Now that everyone's presumably back from vacation, I figured I'd repost this 
proposal.

(If nobody has any comments, how can I get the ball rolling on starting a 
review?)

-- 
Brent Royal-Gordon
Architechies



I've been working on this on-and-off for a few weeks, and I've finished 
drafting a formal proposal. Comments welcome.





# Require `final` on protocol extension members

## Introduction

Protocol extension members which aren't listed in the protocol itself have an 
unusual behavior: a conforming type can implement an identically named member, 
but instances with the protocol's type are always statically dispatched to the 
protocol's implementation. This can lead to the same instance displaying 
different behavior when it's cast to a  protocol it conforms to. In effect, the 
conforming type's member shadows the protocol's, rather than overriding it. 
This behavior is very surprising to some users.

The lack of a warning on this is [currently considered a 
bug](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001861.html),
 but I think we should go further and cause it to be an error. However, we 
should also provide an escape hatch which permits conflicts in cases where 
they're necessary.

## Motivation

Suppose you write a protocol and extension like this:

protocol Turnable {
func turning() -> Self
mutating func turn()
}
extension Turnable {
mutating func turn() {
self = turning()
}

func turningRepeatedly(additionalTurns: Int) -> Self {
var turnedSelf = self
for _ in 1...additionalTurns {
turnedSelf.turn()
}
return turnedSelf
}
}

Now you want to write a conforming type, `SpimsterWicket`. There are three 
different rules about whether your type has to, or can, implement its own 
versions of these methods.

1. `turning()` is a “protocol method”: it is listed in the protocol but is not 
included in the extension. You *must* implement `turning()` to conform to 
`Turnable`.
2. `turn()` is a “defaulted protocol method”: it is listed in the protocol but 
there is also an implementation of it in the extension. You *may* implement 
`turn()`; if you don’t, the protocol extension’s implementation will be used.
3. `turningRepeatedly(_: Int)` is a “protocol extension method”: it is *not* 
listed in the protocol, but only in the protocol extension. This is the case we 
are trying to address.

Currently, in case 3, Swift permits you to implement your own 
`turningRepeatedly(_: Int)`. However, your implementation may not be called in 
every circumstance that you expect. If you call `turningRepeatedly` on a 
variable of type `SpimsterWicket`, you’ll get `SpimsterWicket`’s implementation 
of the method; however, if you call `turningRepeatedly` on a variable of type 
`Turnable`, you’ll get `Turnable`’s implementation of the method.

var wicket: SpimsterWicket = SpimsterWicket()
var turnable: Turnable = wicket

wicket.turn()   // Calls 
SpimsterWicket.turn()
turnable.turn() // Also calls 
SpimsterWicket.turn()

wicket.turningRepeatedly(5) // Calls 
SpimsterWicket.turningRepeatedly(_:)
turnable.turningRepeatedly(5)   // Calls Turnable.turningRepeatedly(_:)

In most parts of Swift, casting an instance or assigning it to a variable of a 
different type doesn’t change which implementation will be called when you put 
it on the left-hand side of a dot. (I’m leaving aside Objective-C bridging, 
like `Int` to `NSNumber`, which is really a different operation being performed 
with the same syntax.) If you put a `UIControl` into a variable of type 
`UIView`, and then call `touchesBegan()` on that variable, Swift will still 
call `UIControl.touchesBegan()`. The same is true of defaulted protocol 
methods—if you call `turn()` on `turnable`, you’ll get `SpimsterWicket.turn()`.

But this is not true of protocol extension methods. There, the static type of 
the variable—the type known at compile time, the type that the variable is 
labeled with—is used. Thus, calling `turningRepeatedly(_:)` on `wicket` gets 
you `SpimsterWicket`’s implementation, but calling it on `turnable`—even though 
it's merely the same instance casted to a different type—gets you `Turnable`’s 
implementation.

This creates what I call an “incoherent” dispatch, and it occurs nowhere else 
in Swift. In most places in Swift, method dispatch is either based on the 
runtime type (reference types, normal protocol members), or the design of the 
language ensures there’s no difference between dispatching on the compile-time 
type and the runtime type (value 

[swift-evolution] Then Support

[James Campbell via swift-evolution]

I was wondering if this should be part of the stdlib

https://cocoapods.org/pods/Then

-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Matthew Johnson via swift-evolution]

> On Jan 3, 2016, at 10:44 PM, Matthew Johnson  wrote:
> 
> 
>> On Jan 3, 2016, at 9:14 PM, Drew Crawford > > wrote:
>> 
>> Sure, here's the start of the thread: 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html
>>  
>> 
> Thanks.  Joe was basically saying is that associated types would be 
> automatically bound to the existential for their constraints, or Any if there 
> are no constraints.  
> 
> He didn’t specifically mention anything about Self, but I suppose Self 
> requirements could also be automatically bound to Any if the existential type 
> doesn’t specify anything more specific, although I’m not sure I would like 
> that behavior.
> 
> Self is what would apply in the case of:
> 
>> func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // error!
>>   if first < second {
>> return -1
>>   }
>>   //...
>> }
> If Self were automatically bound to Any what would this do?  Would it compile 
> and invoke a `<` operator that takes two Any parameters?  That doesn’t seem 
> to make sense to me.  It certainly wouldn’t guarantee you get the correct 
> behavior if first and second were both Int for example.

I gave this some further thought last night and realized what would happen here 
is pretty clear.  I hadn’t considered existentials where associated types 
aren’t bound to concrete types before so it just took a few minutes to work 
through.

Existentials reference a witness table pointing to an actual implementations of 
the protocol requirements.  Actual implementations require parameters of 
concrete types.  This means that you must know what that concrete type is and 
supply a value of that type in order to actually call the member.  The 
implication of this is that members which require parameters of an associated 
type that is not bound to a concrete type will not be available on that 
existential.  

In this example, `<` requires two arguments of type Self.  However, the 
`Comparable` existential, if allowed, would have Self bound to `Any`, not a 
concrete type.  Therefore `<` would not be available and you would receive a 
compiler error on that line.  It would be different than the current error and 
on a different line of code but it would still fail to compile.

With return types, you do not necessarily need to know the concrete type 
returned by the implementation.  Swift could theoretically box the result 
itself into an existential and return that to the caller.  I do not know 
whether this is the actual design that will be implemented or not.

If I any of the above details are incorrect I hope Joe or someone else will 
correct me.  :)

Matthew

> 
> 
>> 
>> 
>>> On Jan 3, 2016, at 9:10 PM, Matthew Johnson >> > wrote:
>>> 
>>> 
 On Jan 3, 2016, at 9:08 PM, Drew Crawford > wrote:
 
> Existentials for protocols with Self and / or associated type 
> requirements would require bindings for Self and / or the associated 
> type(s).  At least when you use a member that contains Self and / or an 
> associated type in its signature.  So the previous example will always 
> fail to compile. 
 
 Not true.  Joe Groff:
>>> 
>>> Can you point me to the source?  I would like more context around these 
>>> comments.
>>> 
 
> This seems like it would be addressed just by allowing Factory to be used 
> as a dynamic type, with its Product type generalized to Any. We'll be set 
> up to support that with some runtime work to store associated types in 
> protocol witness tables (which is also necessary to fix cyclic 
> conformances, one of our Swift 3 goals).
 
 
> Yeah, when generalizing a protocol type, we ought to be able to either 
> generalize the associated types to their upper bounds, for use cases like 
> yours, or constrain them to specific types, for the AnyGenerator kind 
> of case.
>>> 
>> 
> 

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

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

This is what is on the Commonly Rejected Changes section: 
Replace ?: Ternary Operator 
:
 Definitely magical, but it serves a very important use-case for terse 
selection of different values. Proposals for alternatives have been intensely 
discussed, but none have been "better enough" for it to make sense to diverge 
from the precedent established by the C family of languages.

if/else and switch as expressions 
: 
These are conceptually interesting things to support, but many of the problems 
solved by making these into expressions are already solved in Swift in other 
ways. Making them expressions introduces significant tradeoffs, and on balance, 
we haven't found a design that is clearly better than what we have so far.

Please detail what the trade offs are in making them expressions. What are the 
other ways that Swift currently supports this?

- Paul


> On Jan 4, 2016, at 4:42 PM, Paul Ossenbruggen  wrote:
> 
> I can work on making the proposal shorter if that will help.  Any 
> suggestions, for what could be made better. I am trying to be detailed but 
> maybe that is making it too long. 
> 
> I am also not sure why this is not getting people excited. This seems like a 
> clear win to me just being able to use  auto type inference when initializing 
> it compared to switch statements is huge. I feel like I have tried to address 
> most of the objections and what I am suggesting is quite a bit better than 
> ternary, but with any solution there will be something that involves a trade 
> off, these are problems with ternary as well. 
> 
> • terse but hard to understand.
> • more descriptive but longer. 
> 
> These are conflicting problems and you can’t solve both but there is nothing 
> so magical about the ternary that I can see. The problems I see with ternary:
> 
> • hard to see beginning and end **
> • not immediately obvious what it does
> • can’t be searched on the web **
> • only supports boolean and can’t support more than two outcomes. ** 
> • does not support switch like capabilities **
> 
> Good aspects of ternary:
> • Terse **
> • Fits in small places can be formatted multiline or single line. **
> • guarantees the return type is compatible. **
> • it is well known by C like language users
> • it does not interrupt the control flow like an if statement does. So the 
> code is linear. **
> • you are guaranteed a result. **
> • Automatically will infer type when binding a name. ** 
> • reduces duplicated code. ** 
> • quick conversions are possible. **  
> 
> All the items with ** stars next to them are addressed with the proposal 
> others are no worse than ternary. 
> 
> And it adds some things:
> • Adds switch expressions
> • Adds using a zero based index to execute an expression. 
> • Lets you easily see begin and end of the expression
> • Different but better
> • Supports more than two outcomes. 
> 
> Downsides:
> • breaking change (I think there is value in a unified approach to doing 
> expressions like this, we could leave ternary alone and adapt the rest of the 
> proposal though, this has the downside that there are two ways of doing 
> booleans though). 
> • not as immediately as familiar as ternary (but similar enough that anyone 
> who knows about ternary will quickly adapt). 
> 
>> On Jan 4, 2016, at 3:45 PM, Charles Constant > > wrote:
>> 
>> Our ternary-like switch is now in the "commonly_proposed.md 
>> " file, which doesn't bode very well. It 
>> puzzles me that there isn't more enthusiasm. Are we the only ones who get 
>> irritated taking up so much space with a "switch" when all we need to do is 
>> transform between two sets of values?
>> 
>> I think we need to revamp the proposal somehow to make the idea clearer, 
>> because it ought to be pretty compelling.
>> 
>> • Does anyone here have better "side by side" examples of code before/after? 
>> 
>> • Can anyone think of a way to revise the (English) language of the proposal 
>> to make it shorter and sweeter? 
>> 
>> Apologies for prescribing instead of doing. My only excuse is that I'm "too 
>> busy"
>> 
>> 
>> 
>> 
>> On Mon, Jan 4, 2016 at 3:03 PM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>>> On Jan 4, 2016, at 2:37 PM, Paul Ossenbruggen via swift-evolution 
>>> > wrote:
>>> 
>>> Good feedback, I am all for making it feel more like swift. Any ideas would 
>>> be welcome. I will also try to come up with some myself. 
>> 
>> My suggestion is to leave ternary alone and try to come up with a 
>> ternary-like switch expression that is workable.  I think that is likely the 
>> best change possible at this point.
>> 
>>> 
>>> 

Re: [swift-evolution] ternary operator ?: suggestion

[Charles Constant via swift-evolution]

My best guesses here, since I didn't write and don't entirely agree...

*> Please detail what the trade offs are*

Other than more complexity, I think this refers to making the "switch"
statement do two slightly different things. Of course, if we call it
something else, like "match" or "which" then it stops being an issue.

*> What are the other ways that Swift currently supports this?*

As far as I can see, the closest we get are...

a) The existing "switch" statement, or if else statement (preceded with
a statement to declare the variable. yuck). I think this is verbose enough
to qualify as "confusing"

b) Creating an anonymous dict, and immediately accessing it (which
means the keys need to be Hashable). This isn't very flexible

c) Creating a special init or function, to map one enum, to another.
This  is also verbose, and not flexible, and moves the code away from where
it used (even if you never reuse the mapping).

d) Chaining a bunch of conditions in a ternary... Horrible.

Anyone know of any better alternatives? It feels like I'm missing something.









On Mon, Jan 4, 2016 at 10:34 PM, Paul Ossenbruggen  wrote:

> This is what is on the Commonly Rejected Changes section:
>
>-
>
>Replace ?: Ternary Operator
>
> :
>Definitely magical, but it serves a very important use-case for terse
>selection of different values. Proposals for alternatives have been
>intensely discussed, but none have been "better enough" for it to make
>sense to diverge from the precedent established by the C family of
>languages.
>-
>
>if/else and switch as expressions
>
> :
>These are conceptually interesting things to support, but many of the
>problems solved by making these into expressions are already solved in
>Swift in other ways. Making them expressions introduces significant
>tradeoffs, and on balance, we haven't found a design that is clearly better
>than what we have so far.
>
> Please detail what the trade offs are in making them expressions. What are
> the other ways that Swift currently supports this?
>
> - Paul
>
>
> On Jan 4, 2016, at 4:42 PM, Paul Ossenbruggen  wrote:
>
> I can work on making the proposal shorter if that will help.  Any
> suggestions, for what could be made better. I am trying to be detailed but
> maybe that is making it too long.
>
> I am also not sure why this is not getting people excited. This seems like
> a clear win to me just being able to use  auto type inference when
> initializing it compared to switch statements is huge. I feel like I have
> tried to address most of the objections and what I am suggesting is quite a
> bit better than ternary, but with any solution there will be something that
> involves a trade off, these are problems with ternary as well.
>
> • terse but hard to understand.
> • more descriptive but longer.
>
> These are conflicting problems and you can’t solve both but there is
> nothing so magical about the ternary that I can see. The problems I see
> with ternary:
>
> • hard to see beginning and end **
> • not immediately obvious what it does
> • can’t be searched on the web **
> • only supports boolean and can’t support more than two outcomes. **
> • does not support switch like capabilities **
>
> Good aspects of ternary:
> • Terse **
> • Fits in small places can be formatted multiline or single line. **
> • guarantees the return type is compatible. **
> • it is well known by C like language users
> • it does not interrupt the control flow like an if statement does. So the
> code is linear. **
> • you are guaranteed a result. **
> • Automatically will infer type when binding a name. **
> • reduces duplicated code. **
> • quick conversions are possible. **
>
> All the items with ** stars next to them are addressed with the proposal
> others are no worse than ternary.
>
> And it adds some things:
> • Adds switch expressions
> • Adds using a zero based index to execute an expression.
> • Lets you easily see begin and end of the expression
> • Different but better
> • Supports more than two outcomes.
>
> Downsides:
> • breaking change (I think there is value in a unified approach to doing
> expressions like this, we could leave ternary alone and adapt the rest of
> the proposal though, this has the downside that there are two ways of doing
> booleans though).
> • not as immediately as familiar as ternary (but similar enough that
> anyone who knows about ternary will quickly adapt).
>
> On Jan 4, 2016, at 3:45 PM, Charles Constant 
> wrote:
>
> Our ternary-like switch is now in the "commonly_proposed.md" file, which
> doesn't bode very well. It puzzles me that there isn't more enthusiasm. Are
> we the only ones who get irritated taking up so much space with a "switch"

Re: [swift-evolution] Failable Initializer Suggestion

[Thorsten Seitz via swift-evolution]

+1 for keeping failable initializers. Error handling should be reserved for 
errors and not be used for control flow or logic.

-Thorsten 

> Am 27.12.2015 um 18:11 schrieb Chris Lattner via swift-evolution 
> :
> 
>> On Dec 27, 2015, at 5:22 AM, Manfred Lau via swift-evolution 
>>  wrote:
>> I just found that the design of failable initializer is redundant in Swift 
>> 2. Because native error handling already has been introduced in Swift 2, and 
>> failable initializer indeed could be achieved by following codes:
> 
> I’d be opposed to removing failable initializers.  Failable inits introduce a 
> symmetry into the language for initializers, which make them possible to do 
> (almost) all of what you can do with a normal method.  This capability is key 
> for them to be able to replace “factory” static methods, which allows Swift 
> to offer a consistent initialization pattern for clients of types.
> 
> If we forced people to use error handling for anything that could return nil, 
> then things like String to Int conversions would most likely not use 
> initialization syntax.
> 
> Besides that, over use of error handling waters it down and makes it less 
> valuable in itself.  For more information on this, please see the design 
> discussion for error handling:
> https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst
> 
> -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] [Proposal Draft] Flexible memberwise initialization

[Howard Lovatt via swift-evolution]

I was guessing that the current proposal does not change anything re.
default and current member wise initializers and so in addition to
suggesting Scala syntax I was also suggesting the transformation shown, or
its equivalent. The advantage of having a member wise init that has default
arguments and argument labels are considerable:

1. Allows lets as well as vars
2. Allows partial custom initialization
3. Eliminates need for other mechanisms, i.e. default and existing member
wise initialization

These facilities could be added to `memberwise init(...)` as well. In
particular, if a member wise init was present then an initialized property
could have a label, e.g.:

 class C {
 let example name: Type = initial
 memberwise init(...)
 }

Would become the equivalent of:

 class C {
 let name: Type
 init(example name: Type = initial) {
 self.name = name
 }
  }

The Scala syntax is just a shorter alternative, ideally there be a
discussion of the pros and cons of the two syntax that included the
possibility of the wider set of objectives as outlined in the numbered
points above.

On Tuesday, 5 January 2016, Matthew Johnson  wrote:

>
> On Jan 4, 2016, at 5:48 PM, Howard Lovatt  > wrote:
>
> Yes you can get close, but:
>
> 1. Its weird that you can only do this in an extension.
>
>
> This is the way the current implicit initializer works.  It is not
> synthesized if you define any initializers in the body of the type.  There
> are good reasons it works this way and the current proposal does not change
> those rules.
>
> 2. Its not quite the same as the proposal the current member-wise
> initialiser does not make the init arguments optional (the arguments
> themselves do not have defaults), i.e. with your example `let
> defaultOriginRect = Rect(size: Size(width: 5.0, height: 5.0))` fails
> whereas it would work for the proposal (this could also be true if the
> existing struct memberwise init and the new `memberwise init(..)` where
> changed to provide init argument defaults).
>
>
> The implicit memberwise initializer currently in the language does not
> provide defaults for parameters.  This proposal changes that behavior and
> provides defaults if the the member is a `var` and has an initial value.
>
> Unfortunately I was not able to find a solution to allow synthesized
> parameters for `let` members to have default values.  This is because the
> current semantics for `let` members do not allow the member to be
> initialized to anything other than the initial value if one is provided.  I
> am hoping a solution to this will be identified in the future and have
> suggested one possible mechanism `@default` in the future enhancements
> section.
>
> 3. Only ‘really' works for structs, the compiler doesn’t write a
> member-wise initialiser for classes (just a default initializer).
>
>
> That is true about the current behavior of the language but is not true
> with regards to the current proposal.
>
> 4. Still need the compiler to provide both default and member-wise
> initialisers, whereas this proposal would allow the existing default and
> member-wise initialisers to be deprecated and just the new member-wise
> initialiser would remain which would simplify the language and make it
> clear what was happening (this could also be true if a `memberwise
> init(..)` where added and existing compiler written inits removed).
>
>
> This proposal does not change anything with regard to the default
> initializer.
>
>
>
> On 5 Jan 2016, at 10:16 AM, Matthew Johnson  > wrote:
>
> struct Rect { var origin: Point = Point(), size: Size = Size() }
> extension Rect {
>init(center: Point, size: Size) {
>
>let originX = center.x - (size.width / 2)
>
>let originY = center.y - (size.height / 2)
>
>self.init(origin: Point(x: originX, y: originY), size: size)
>
>}
> }
>
>
>
>

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

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

[David Owens II via swift-evolution]

The @available() and if #available constructs are not sufficient as they fall 
under the same limitations that your proposal addresses: they require that the 
non-valid branch not be parsed. For example, an API that has changes with a new 
language feature, such as variadic generic arguments, would not be able to be 
defined.

If we look at the grammar, I don’t see why the grammar for 
“availability-argument” couldn’t look like this:

availability-argument: (platform-name | language-name | package-name) 
version.
GRAMMAR OF AN AVAILABILITY CONDITION

 <>availability-condition → #available­(­availability-arguments 
­)­
 <>availability-arguments → availability-argument 
­
  availability-argument 
­,­availability-arguments
 
­
 <>availability-argument → platform-name 
­platform-version
 
­
 <>availability-argument → *­
 <>platform-name → iOS­  iOSApplicationExtension­
 <>platform-name → OSX­  OSXApplicationExtension­
 <>platform-name → watchOS­
 <>platform-version → decimal-digits 
­
 <>platform-version → decimal-digits 
­.­decimal-digits
 
­
 <>platform-version → decimal-digits 
­.­decimal-digits
 
­.­decimal-digits
 
­
I’d further argue that the version argument properly adhere to the semver spec: 
http://semver.org.

The above change, in addition to the change for the if #available statement to 
not parse the unavailable path would seem to provide the solution you want to 
have in addition to the solution that many package developers could use as well.

The nice thing is that this could be done in stages:

1. Add support for the language condition and change #available to not parse 
the non-valid paths
2. Add support for package names
3. Add support for proper semver versioning.

The only breaking change is #1. When/if semver was supported, the version could 
still take the decimal digits while adding semver support.

-David

> On Jan 4, 2016, at 4:02 PM, David Farler  wrote:
> 
> We already have @- and #-prefixed availability-like constructs, so I would 
> prefer something more specific to the task – I wouldn't want to dilute the 
> meaning of a package name argument by supplying it with the magic package 
> "swift", for example. Changes to the language can be highly disruptive to all 
> Swift code, so that's why I think it warrants its own build configuration. 
> 
> David
> 
>> On Dec 20, 2015, at 10:45 PM, David Owens II via swift-evolution 
>> > wrote:
>> 
>> If we are going to support something like this, I’d rather see it be 
>> something everyone could leverage as there are many use cases for this 
>> feature:
>> 
>> #if available("package-name", "1.2.*")
>> #endif
>> 
>> Then at least everyone can opt-in to using it for availability checks. This 
>> should of course tie into the Swift Package Manager and use proper semver 
>> syntax (might as well use node’s example: https://docs.npmjs.com/misc/semver 
>> ).
>> 
>> Another solution would be to simply factor out the code into 

Re: [swift-evolution] Proposal: named invariants for variable declarations

[Árpád Goretity via swift-evolution]

This suspiciously starts to resemble a mixture of dependent types and explicit 
contracts (something like the Midori variant of C#).

By the way, while we are at it: if the compiler supports this kind of feature, 
we could (and should) statically check most of the constraints. Accordingly, in 
your example, f(-3) would be a compiler error (the two pure invariants applied 
to the constant argument would both trivially constant-fold to false).

Sent from my iPhone

> On 04 Jan 2016, at 21:33, Howard Lovatt  wrote:
> 
> Alternatively the Properties Behaviour syntax proposal could be applied to 
> any declaration, assuming that it is accepted. 
> 
> 
>> On 5 Jan 2016, at 4:18 AM, Amir Michail via swift-evolution 
>>  wrote:
>> 
>> Examples:
>> 
>> invariant vectorIndex(v:Int) { return 0..<3 ~= v }
>> 
>> var i:Int,vectorIndex: = 2
>> i = 3 // run-time error
>> 
>> invariant positive(v:Int) { return v > 0 }
>> invariant odd(v:Int) { return v % 2 == 1 }
>> 
>> var x:Int, positive, odd = 5
>> 
>> x = 2 // run-time error
>> 
>> func f(z:Int, positive, odd) {
>> …
>> }
>> 
>> f(-3) // run-time error
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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]: support disable to trailing closure syntax

[Vincent Esche via swift-evolution]

This should not be a keyword. Neither should it be part of the language.
Auto-completion (assuming you’re talking about that) is not a language feature.
It’s a feature of your editor/IDE. And thus it should be a default/setting 
therein if at all.

Similarly Xcode tends to auto-complete "() -> ()”-closures as { () -> Void in … 
}.
The “() -> Void in” not necessary in 99/100 cases. Still it shouldn’t have a 
language keyword.
Instead Xcode should be smart enough to omit the “… -> Void in” or at least the 
“ -> …”-part.
But again, this is a feature of your editor/IDE, not your language.

Thus I would recommend you to file a radar on it for Xcode to change its 
default auto-completion behavior. ;)

> On 04 Jan 2016, at 13:45, QQ Mail via swift-evolution 
>  wrote:
> 
> Hi, All: 
>   trailing closure is good for most cases, but sometimes it is also make 
> code unclear, for example: 
>   
> UIView.animateWithDuration(0.3, animations: { () -> Void in
> // animation code here
> }) { (Bool) -> Void in
> // completion code here
> }
> 
> the label been removed and the code also not aligned well. 
> I would like to write like this: 
> 
> UIView.animateWithDuration(0.3,
> 
> animations: { () -> Void in
> // animation code here
> },
> completion: { Bool -> Void in
> // completion code here
> }
> )
> 
> It is possible, just every time you have to write it manually. It’s a little 
> wast.
> So I have a thought, since we already know this function is not well suit for 
> trailing 
> closure, can we add a attribute to disable it, for example: 
> 
> extension UIView {
> 
> @disable_trailing_closure
> public static func animateWithDuration(duration:NSTimeInterval, 
> animations:()->Void, completion:()->Void) {
> // implementations ...
> }
> }
> 
> I also found another one have issue for this too. link: 
> http://www.natashatherobot.com/swift-trailing-closure-syntax/ 
> 
> what do you think?
> 
> Best Regards
> 
> ChenYungui
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Jo Albright via swift-evolution]

- What is your evaluation of the proposal?

+1 : I am all for the idea of not using the same word for different 
functionalities. I don’t see any upside to keeping it the way it is.

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

Description of Swift includes “Swift is designed to make writing and 
maintaining correct programs easier for the developer”… if the desire is to 
make the language easy to understand and learn, then this is a very important 
change as it removes confusion.

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

100%

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

I have not come across this type of feature before.

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

I read all of the reviews and proposal thoroughly.

---

Really excited to see how many people come out to give their opinions on 
proposals. Hope my words are helpful.

Jo Albright

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

Re: [swift-evolution] Empower String type with regular expression

[Vincent Esche via swift-evolution]

There is actually a Rust crate doing exactly that: 
https://github.com/jneem/regex-dfa
Rust however has powerful compile-time macros, enabling this, which Swift 
doesn’t (yet?).

> On 04 Jan 2016, at 02:53, Austin Zheng via swift-evolution 
>  wrote:
> 
> +1 on first-class regex support/pattern matching on regex patterns.
> 
> There was a thread a while ago discussing compile-time code generation, and 
> if I recall correctly one of the stated use cases was 'compiling'/'building' 
> (don't know the real terminology) regex literals at compile-time. Is there a 
> bigger overall vision for this sort of feature, or would it be better to just 
> focus on better regex support?
> 
> Best,
> Austin
> 
> On Sun, Jan 3, 2016 at 1:35 PM, Chris Lattner via swift-evolution 
> > wrote:
>> On Jan 1, 2016, at 4:44 PM, John Joyce via swift-evolution 
>> > wrote:
>>> It is also probably worth burning first-class language support for regexes. 
>>>  This would allow specifying variable captures inline in the pattern, would 
>>> allow flexible syntax for defining regexes, support powerful extensions to 
>>> the base regex model (e.g. Perl 6 style), and would provide better 
>>> compile-time checking and error recovery for mistakes.
>>> 
>>> -Chris
>> I know this is an old thread already, but this sure would be one of the 
>> major breakout pieces of functionality.
>> If Swift had native regular expressions, without all the noise you see in 
>> the Objective-C API that exposes ICU regular expressions, the adoption rate 
>> would be huge.
>> If they were *truly* native, as in somebody sat down and built an NFA (or 
>> one of the fancier approaches that mixes with DFA) state machine, Swift's 
>> best-in-class Unicode support would and could result in amazing things.
>> It'd boost the scripting use of Swift tremendously and seal the deal as a 
>> server side language.
> 
> Totally agreed.  switch on a string with a bunch of regexes being matched 
> should turn into a parallel state machine, just like a lexer :-)
> 
> -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 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal]: Drastically improve searching API (indexOf(…)) of CollectionType

[Vincent Esche via swift-evolution]

After having had this code laying around on my Mac since 6/26/15 (waiting for 
Swift to go open source)
I figured it’s about damn time I submit the actual RFC for it. So without 
further ado…

One of the areas where Swift’s stdlib is still quite lacking is searching.
Which is a shame as searching (along with indexing) might be among
the most important tasks of computer science/software development.
One might not need fast collection searches for writing a banal fart or 
flashlight app,
but almost every other app is likely to benefit from having a proper searching 
API.

So I’d like to fix that.

Attached you find a full RFC along with the full and functional source code to 
make it happen.

I’d love to hear your opinion on this and will be more than happy to answer 
questions.

Rendered Version + Full Implementation: 
https://gist.github.com/regexident/2b7531bd748f57679671 

(The code is tested using Quick/Nimble. Tests would thus have to be ported to 
Swift’s XCTest.)

- Vincent

> Markdown-dump for
> 
> # Improved Collection Search
> 
> * Proposal: 
> [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md)
> * Author(s): [Vincent Esche](https://github.com/regexident)
> * Status: **Review**
> * Review manager: TBD
> 
> ## Introduction
> 
> This RFC proposes an extension to the currently rather limited and linear 
> searching API of `CollectionType`, that is `indexOf(element:)` and 
> `indexOf(predicate:)`.
> It proposes the backwards-compatible refactoring of those existing methods as 
> well as the introduction of a view-based ensemble of methods for efficient 
> binary-search.
> 
> Swift-evolution thread: [link to the discussion thread for that 
> proposal](https://lists.swift.org/pipermail/swift-evolution)
> 
> ## Motivation
> 
> Indexing of and searching in data is a big deal in software development. As 
> such it is crucial to have capable means of doing so in a language that 
> aspires to be a highly performant programming language.
> 
> Swift's current API for searching is basically limited to these two methods 
> on `CollectionType`:
> 
> > ```swift
> > func indexOf(element: Self.Generator.Element) -> Self.Index?
> > ```
> > Returns the first index where value appears in self or nil if value is not 
> > found.
> >
> > **Complexity**: `O(self.count)`.
> 
> and:
> 
> > ```swift
> > func indexOf(@noescape predicate: (Self.Generator.Element) throws -> Bool) 
> > rethrows -> Self.Index?
> > ```
> > Returns the first index where predicate returns true for the corresponding 
> > value, or nil if such value is not found.
> > 
> > **Complexity**: `O(self.count)`.
> 
> The author sees a couple of issue with these two methods:
> 
> 1. They do not provide an option for restricting the "haystack" to a certain 
> `range` of `self`.
> 2. They do not provide a fast (`O(log2(self.count))`) path for sorted 
> collections.
> 3. They should not be limited to `CollectionType` but instead be moved to 
> `Indexable`.
> 
> In many situations it is desirable to perform fast searches on sorted 
> collections instead of having to fall back to naïve linear searches.
> 
> Further more while a single `index` might be the most common subject of 
> interest, there are many scenarios where a `range` or `count` of matches are 
> of more use.
> 
> And anyone who is writing a custom ordered collection type will eventually 
> want to find the insertion index for a given element and will thus end up 
> writing some variant of `lowerBoundOf(…)` or `upperBoundOf(…)` (upon which 
> all the other methods can be implemented, actually).
> 
> ## Proposed solution
> 
> The author proposes:
> 
> 1. A backwards-compatible refactoring of `CollectionType.indices`, moving it 
> to `Indexable`.
> 
> 2. A backwards-compatible refactoring of `indexOf(…)` (adding optional 
> `range:` and moving it to `Indexable`).
> 
> 3. The addition of `rangeOf(…)`, `countOf(…)` and `isSorted(…)` to 
> `Indexable` with a TIME complexity of `O(self.count)`.
> 
> 4. The introduction of a `BinarySearchView` on `Indexable`, allowing for fast 
> (`O(log2(self.count))`) searches on `Indexable` via `indexOf(…)`, 
> `rangeOf(…)`, `countOf(…)`, `lowerBoundOf(…)`, `upperBoundOf(…)` without 
> cluttering `Indexable`'s interface.
> 
> ## Detailed design
> 
> ### `CollectionType.indices`:
> 
> The author proposes the relocation of `.indices` from `CollectionType` to 
> `Indexable`:
> 
> ```swift
> extension Indexable {
> /// Return the range of valid index values.
> ///
> /// The result's `endIndex` is the same as that of `self`.  Because
> /// `Range` is half-open, iterating the values of the result produces
> /// all valid subscript arguments for `self`, omitting its `endIndex`.
> public var indices: Range { get }
> }
> ```
> 
> After all all it does is provide a convenience method for generating a Range 
> from its `startIndex` and `endIndex`. There is no need for 

Re: [swift-evolution] Then Support

[James Campbell via swift-evolution]

Cheers Erica. I'll try this again but do it properly this time ;)

On Mon, Jan 4, 2016 at 3:24 PM, Erica Sadun  wrote:

> This idea probably deserves more attention than it's going to get with
> this pitch for two reasons:
>
> First, the Swift-Evolution list is heavily trafficked and you've given no
> context in either your subject line or your message about what "then" is
> and why it would be valuable to the Swift programming language. It is a
> Cocoapod that introduces "syntactic sugar for Swift initializers", that is
> extended initialization steps to support Cocoa set-up beyond the
> Apple-supplied inits. This is the same $0-delimited approach that has
> evolved spontaneously from a variety of developers.
>
> Second, similar ideas have already been pitched and discussed on-list
> under the topics of method cascading, extended initialization, and so
> forth. You can search the Swift Evolution Archies on
>
>
>- Google (use site:https://lists.swift.org/pipermail/swift-evolution/ in
>your search, e.g.
>
> https://www.google.com/?gws_rd=ssl#q=cascad+site:https:%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F
>
> 
>) or
>- gmane (e.g.
>
> http://search.gmane.org/?query=cascad==gmane.comp.lang.swift.evolution=relevance=and=Zcascad=Gcomp.lang.swift.evolution---A
>)
>
>
> A proposal on adding Dart-like cascades with Swifter-syntax stalled. Old
> proposal here: https://gist.github.com/erica/eb32feb22ba99629285a Bug
> report here: https://bugs.swift.org/browse/SR-160
>
> The topic appears to be a popular one and well liked. I understand its
> best timeframe for discussion will be in about a year as it is unlikely to
> be addressed in Swift 3.0, although you should probably ask an Apple team
> member rather than a general bystander like myself.
>
> Best regards, -- Erica
>
>
> On Jan 4, 2016, at 6:58 AM, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I was wondering if this should be part of the stdlib
>
> https://cocoapods.org/pods/Then
>
> --
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Sune Foldager via swift-evolution]

> 
>   * What is your evaluation of the proposal?

+1, although I don’t like the name because it’s two normally non-compoundable 
words, compounded into one. A combination that would be more natural is 
something like “typeassociate” although that sounds quite silly to me. I 
suppose maybe just “associated”.

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

Yes, it has seemed to confuse people on several occasions.


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

Yes, I believe so.


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

I haven’t.


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

I followed the discussion closely and, while it doesn’t confuse me personally, 
I have seen several mails and forum posts from people it does.

/Sune

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

[swift-evolution] Proposal: named invariants for variable declarations

[Amir Michail via swift-evolution]

Examples:

invariant vectorIndex(v:Int) { return 0..<3 ~= v }

var i:Int,vectorIndex: = 2
i = 3 // run-time error

invariant positive(v:Int) { return v > 0 }
invariant odd(v:Int) { return v % 2 == 1 }

var x:Int, positive, odd = 5

x = 2 // run-time error

func f(z:Int, positive, odd) {
…
}

f(-3) // run-time error






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

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

[Alex Migicovsky via swift-evolution]

I think instead of an attribute I’d prefer rules that allow trailing closures 
at call sites. The most straightforward solution would be to only allow using 
trailing closures at the call site if the invoked function has a single closure 
that’s the last parameter. I think the only unfortunate aspect of that is it’s 
an implicit rule which makes it harder for new devs to learn (and experienced 
devs to remember!).

- Alex

> On Jan 4, 2016, at 4:45 AM, QQ Mail via swift-evolution 
>  wrote:
> 
> Hi, All: 
>   trailing closure is good for most cases, but sometimes it is also make 
> code unclear, for example: 
>   
> UIView.animateWithDuration(0.3, animations: { () -> Void in
> // animation code here
> }) { (Bool) -> Void in
> // completion code here
> }
> 
> the label been removed and the code also not aligned well. 
> I would like to write like this: 
> 
> UIView.animateWithDuration(0.3,
> 
> animations: { () -> Void in
> // animation code here
> },
> completion: { Bool -> Void in
> // completion code here
> }
> )
> 
> It is possible, just every time you have to write it manually. It’s a little 
> wast.
> So I have a thought, since we already know this function is not well suit for 
> trailing 
> closure, can we add a attribute to disable it, for example: 
> 
> extension UIView {
> 
> @disable_trailing_closure
> public static func animateWithDuration(duration:NSTimeInterval, 
> animations:()->Void, completion:()->Void) {
> // implementations ...
> }
> }
> 
> I also found another one have issue for this too. link: 
> http://www.natashatherobot.com/swift-trailing-closure-syntax/ 
> 
> what do you think?
> 
> Best Regards
> 
> ChenYungui
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Matt Whiteside via swift-evolution]

> On Jan 2, 2016, at 22:38, Douglas Gregor via swift-evolution 
>  wrote:
>   * What is your evaluation of the proposal?
 
Taking an example from the swift source to compare an alternative, `type`, we 
have

public protocol _CollectionWrapperType : _SequenceWrapperType {
associatedtype Base : CollectionType
associatedtype Index : ForwardIndexType = Self.Base.Index
}

vs

public protocol _CollectionWrapperType : _SequenceWrapperType {
type Base : CollectionType
type Index : ForwardIndexType = Self.Base.Index
}

I think the version with `associatedtype` is a bit verbose, but that doesn’t 
seem like a big problem.  It might read a little more clearly as well.  I 
wouldn’t be unhappy with either of these alternatives, but `associatedtype` 
seems like a good choice.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
Yes.  I think it `typealias` should be used only as the swift equivalent of a C 
typedef.

>   * Does this proposal fit well with the feel and direction of Swift?
Yes, because we want to improve readability and understandability.

>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
I haven’t used another language with this feature.

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

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
>   Cheers,
>   Doug Gregor
>   Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Douglas Gregor via swift-evolution]

> On Jan 4, 2016, at 6:24 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> 
>> On Jan 3, 2016, at 10:44 PM, Matthew Johnson > > wrote:
>> 
>> 
>>> On Jan 3, 2016, at 9:14 PM, Drew Crawford >> > wrote:
>>> 
>>> Sure, here's the start of the thread: 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html
>>>  
>>> 
>> Thanks.  Joe was basically saying is that associated types would be 
>> automatically bound to the existential for their constraints, or Any if 
>> there are no constraints.  
>> 
>> He didn’t specifically mention anything about Self, but I suppose Self 
>> requirements could also be automatically bound to Any if the existential 
>> type doesn’t specify anything more specific, although I’m not sure I would 
>> like that behavior.
>> 
>> Self is what would apply in the case of:
>> 
>>> func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // error!
>>>   if first < second {
>>> return -1
>>>   }
>>>   //...
>>> }
>> If Self were automatically bound to Any what would this do?  Would it 
>> compile and invoke a `<` operator that takes two Any parameters?  That 
>> doesn’t seem to make sense to me.  It certainly wouldn’t guarantee you get 
>> the correct behavior if first and second were both Int for example.
> 
> I gave this some further thought last night and realized what would happen 
> here is pretty clear.  I hadn’t considered existentials where associated 
> types aren’t bound to concrete types before so it just took a few minutes to 
> work through.
> 
> Existentials reference a witness table pointing to an actual implementations 
> of the protocol requirements.  Actual implementations require parameters of 
> concrete types.  This means that you must know what that concrete type is and 
> supply a value of that type in order to actually call the member.  The 
> implication of this is that members which require parameters of an associated 
> type that is not bound to a concrete type will not be available on that 
> existential.  

There is a concrete type, which is known dynamically to the existential value, 
but you would need a way to name that type to (e.g.) cast down to it before you 
could use the member. That’s why the open..as operation I mentioned allows one 
to use these members: it gives a way to name the type. It actually helps to 
think of any operation on existentials as implicitly using open..as, because it 
makes the semantics far more explicit. (The compiler does this internally as 
well)

> In this example, `<` requires two arguments of type Self.  However, the 
> `Comparable` existential, if allowed, would have Self bound to `Any`, not a 
> concrete type.  Therefore `<` would not be available and you would receive a 
> compiler error on that line.  It would be different than the current error 
> and on a different line of code but it would still fail to compile.
> 
> With return types, you do not necessarily need to know the concrete type 
> returned by the implementation.  Swift could theoretically box the result 
> itself into an existential and return that to the caller.  I do not know 
> whether this is the actual design that will be implemented or not.

It’s a reasonable direction that we’ve discussed in passing but never committed 
to.

- Doug

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

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Matthew Johnson via swift-evolution]

> On Jan 4, 2016, at 11:43 AM, Douglas Gregor  wrote:
> 
>> 
>> On Jan 4, 2016, at 6:24 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Jan 3, 2016, at 10:44 PM, Matthew Johnson >> > wrote:
>>> 
>>> 
 On Jan 3, 2016, at 9:14 PM, Drew Crawford > wrote:
 
 Sure, here's the start of the thread: 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html
  
 
>>> Thanks.  Joe was basically saying is that associated types would be 
>>> automatically bound to the existential for their constraints, or Any if 
>>> there are no constraints.  
>>> 
>>> He didn’t specifically mention anything about Self, but I suppose Self 
>>> requirements could also be automatically bound to Any if the existential 
>>> type doesn’t specify anything more specific, although I’m not sure I would 
>>> like that behavior.
>>> 
>>> Self is what would apply in the case of:
>>> 
 func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // 
 error!
   if first < second {
 return -1
   }
   //...
 }
>>> If Self were automatically bound to Any what would this do?  Would it 
>>> compile and invoke a `<` operator that takes two Any parameters?  That 
>>> doesn’t seem to make sense to me.  It certainly wouldn’t guarantee you get 
>>> the correct behavior if first and second were both Int for example.
>> 
>> I gave this some further thought last night and realized what would happen 
>> here is pretty clear.  I hadn’t considered existentials where associated 
>> types aren’t bound to concrete types before so it just took a few minutes to 
>> work through.
>> 
>> Existentials reference a witness table pointing to an actual implementations 
>> of the protocol requirements.  Actual implementations require parameters of 
>> concrete types.  This means that you must know what that concrete type is 
>> and supply a value of that type in order to actually call the member.  The 
>> implication of this is that members which require parameters of an 
>> associated type that is not bound to a concrete type will not be available 
>> on that existential.  
> 
> There is a concrete type, which is known dynamically to the existential 
> value, but you would need a way to name that type to (e.g.) cast down to it 
> before you could use the member. That’s why the open..as operation I 
> mentioned allows one to use these members: it gives a way to name the type. 
> It actually helps to think of any operation on existentials as implicitly 
> using open..as, because it makes the semantics far more explicit. (The 
> compiler does this internally as well)

Casting down makes sense and of course you could use the member after that.  
But why do we need a special cast operation “open” to do this?  Is there a 
reason we couldn’t just cast down with the usual operators like we can with 
`Any`?

> 
>> In this example, `<` requires two arguments of type Self.  However, the 
>> `Comparable` existential, if allowed, would have Self bound to `Any`, not a 
>> concrete type.  Therefore `<` would not be available and you would receive a 
>> compiler error on that line.  It would be different than the current error 
>> and on a different line of code but it would still fail to compile.
>> 
>> With return types, you do not necessarily need to know the concrete type 
>> returned by the implementation.  Swift could theoretically box the result 
>> itself into an existential and return that to the caller.  I do not know 
>> whether this is the actual design that will be implemented or not.
> 
> It’s a reasonable direction that we’ve discussed in passing but never 
> committed to.
> 
>   - Doug

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

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Matthew Johnson via swift-evolution]

> On Jan 4, 2016, at 11:56 AM, Douglas Gregor  wrote:
> 
>> 
>> On Jan 4, 2016, at 9:54 AM, Matthew Johnson > > wrote:
>> 
>>> 
>>> On Jan 4, 2016, at 11:43 AM, Douglas Gregor >> > wrote:
>>> 
 
 On Jan 4, 2016, at 6:24 AM, Matthew Johnson via swift-evolution 
 > wrote:
 
> 
> On Jan 3, 2016, at 10:44 PM, Matthew Johnson  > wrote:
> 
> 
>> On Jan 3, 2016, at 9:14 PM, Drew Crawford > > wrote:
>> 
>> Sure, here's the start of the thread: 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html
>>  
>> 
> Thanks.  Joe was basically saying is that associated types would be 
> automatically bound to the existential for their constraints, or Any if 
> there are no constraints.  
> 
> He didn’t specifically mention anything about Self, but I suppose Self 
> requirements could also be automatically bound to Any if the existential 
> type doesn’t specify anything more specific, although I’m not sure I 
> would like that behavior.
> 
> Self is what would apply in the case of:
> 
>> func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // 
>> error!
>>   if first < second {
>> return -1
>>   }
>>   //...
>> }
> If Self were automatically bound to Any what would this do?  Would it 
> compile and invoke a `<` operator that takes two Any parameters?  That 
> doesn’t seem to make sense to me.  It certainly wouldn’t guarantee you 
> get the correct behavior if first and second were both Int for example.
 
 I gave this some further thought last night and realized what would happen 
 here is pretty clear.  I hadn’t considered existentials where associated 
 types aren’t bound to concrete types before so it just took a few minutes 
 to work through.
 
 Existentials reference a witness table pointing to an actual 
 implementations of the protocol requirements.  Actual implementations 
 require parameters of concrete types.  This means that you must know what 
 that concrete type is and supply a value of that type in order to actually 
 call the member.  The implication of this is that members which require 
 parameters of an associated type that is not bound to a concrete type will 
 not be available on that existential.  
>>> 
>>> There is a concrete type, which is known dynamically to the existential 
>>> value, but you would need a way to name that type to (e.g.) cast down to it 
>>> before you could use the member. That’s why the open..as operation I 
>>> mentioned allows one to use these members: it gives a way to name the type. 
>>> It actually helps to think of any operation on existentials as implicitly 
>>> using open..as, because it makes the semantics far more explicit. (The 
>>> compiler does this internally as well)
>> 
>> Casting down makes sense and of course you could use the member after that.  
>> But why do we need a special cast operation “open” to do this?  Is there a 
>> reason we couldn’t just cast down with the usual operators like we can with 
>> `Any`?
> 
> How are you going to name the type you’re casting to?

Ok, I see now.  I missed that you’re introducing a type variable in the open 
operation.  :)  I mistook T for an arbitrary but concrete type.

> 
>   - Doug

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

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

[Michel Fortin via swift-evolution]

Le 4 janv. 2016 à 7:45, QQ Mail via swift-evolution  
a écrit :
> I would like to write like this: 
> 
> UIView.animateWithDuration(0.3,
> 
> animations: { () -> Void in
> // animation code here
> },
> completion: { Bool -> Void in
> // completion code here
> }
> )

Maybe, instead of disallowing trailing closures, we could allow consecutive 
closures to be expressed like that:

UIView.animateWithDuration(0.3) {
// animation code here
} completion { success in
// completion code here
}

-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Douglas Gregor via swift-evolution]

> On Jan 4, 2016, at 9:54 AM, Matthew Johnson  wrote:
> 
>> 
>> On Jan 4, 2016, at 11:43 AM, Douglas Gregor > > wrote:
>> 
>>> 
>>> On Jan 4, 2016, at 6:24 AM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
 
 On Jan 3, 2016, at 10:44 PM, Matthew Johnson > wrote:
 
 
> On Jan 3, 2016, at 9:14 PM, Drew Crawford  > wrote:
> 
> Sure, here's the start of the thread: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html
>  
> 
 Thanks.  Joe was basically saying is that associated types would be 
 automatically bound to the existential for their constraints, or Any if 
 there are no constraints.  
 
 He didn’t specifically mention anything about Self, but I suppose Self 
 requirements could also be automatically bound to Any if the existential 
 type doesn’t specify anything more specific, although I’m not sure I would 
 like that behavior.
 
 Self is what would apply in the case of:
 
> func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // 
> error!
>   if first < second {
> return -1
>   }
>   //...
> }
 If Self were automatically bound to Any what would this do?  Would it 
 compile and invoke a `<` operator that takes two Any parameters?  That 
 doesn’t seem to make sense to me.  It certainly wouldn’t guarantee you get 
 the correct behavior if first and second were both Int for example.
>>> 
>>> I gave this some further thought last night and realized what would happen 
>>> here is pretty clear.  I hadn’t considered existentials where associated 
>>> types aren’t bound to concrete types before so it just took a few minutes 
>>> to work through.
>>> 
>>> Existentials reference a witness table pointing to an actual 
>>> implementations of the protocol requirements.  Actual implementations 
>>> require parameters of concrete types.  This means that you must know what 
>>> that concrete type is and supply a value of that type in order to actually 
>>> call the member.  The implication of this is that members which require 
>>> parameters of an associated type that is not bound to a concrete type will 
>>> not be available on that existential.  
>> 
>> There is a concrete type, which is known dynamically to the existential 
>> value, but you would need a way to name that type to (e.g.) cast down to it 
>> before you could use the member. That’s why the open..as operation I 
>> mentioned allows one to use these members: it gives a way to name the type. 
>> It actually helps to think of any operation on existentials as implicitly 
>> using open..as, because it makes the semantics far more explicit. (The 
>> compiler does this internally as well)
> 
> Casting down makes sense and of course you could use the member after that.  
> But why do we need a special cast operation “open” to do this?  Is there a 
> reason we couldn’t just cast down with the usual operators like we can with 
> `Any`?

How are you going to name the type you’re casting to?

- Doug


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

[swift-evolution] use standard syntax instead of "do" and "repeat"

[Andrew Duncan via swift-evolution]

>> 
>>  func recognizeHandler() throws {
>>try {
>>accept(.on)// .on is an enum tag for the token for the ‘on’ 
>> keyword.
>>recognizeName()
>>recognizeFormalParamSeq()
>>accept(.newline)
>>recognizeCommandSeq()
>>accept(.end)
>>recognizeName()// Later Visitor pass checks that names match. 
>>accept(.newline)
>>}
>>  }
> 
> 
> Indeed.  Also, FWIW, I’d argue that maybe the root problem here is that this 
> code should not be using Swift’s error handling constructs in the first 
> place.  An enum (or other approach) may be more appropriate.  Swift’s error 
> handling design is intentionally driven by the idea that you shouldn’t use it 
> if “everything throws” - in this situation, the sugar benefits of error 
> handling are intentionally outweighed by the weight of the try keywords 
> everywhere.  This is meant to force the balance over to using more manual 
> techniques.
> 
> -Chris

Quite so. That is what prompted an earlier topic about guarding on Optionals:

 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004217.html

In fact, I did go with a construct like

   let r = returnsSucceedOrFailEnum()
   guard case let .Succeed(node) = r else { return r }  // Back down the call 
stack.
   // Safe to use node; r now irrelevant but in scope.

Alas, my LOC soared. More code, more bugs.

Apart from considerations of propriety, are there performance up/downsides to 
either approach?

- AMD

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

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Douglas Gregor via swift-evolution]

> On Jan 3, 2016, at 4:19 PM, David Waite  wrote:
> 
> This would be wonderful - is it something that could happen in the Swift 3 
> timeframe?

I hesitate to say “yes” here. I think it fits with the goals of Swift 3, but my 
main concern is that there isn’t enough engineering bandwidth to implement it 
for Swift 3.

> Is it something that myself or someone else could work on a formal proposal 
> for?

Yes, absolutely. This is a case where I think it’s useful to design what we 
want, even if we cannot fit the implementation into the Swift 3 schedule. It’s 
also a case where the compiler has a lot of the pieces already implemented 
(with some runtime bits landing soon), so the implementation should not be 
*that* hard and will likely not require architectural changes.

- Doug

> 
> -DW
> 
>> On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
>>> > wrote:
>>> 
>>> Introduction of interfaces will clean up the current blend of static and 
>>> dynamic protocols, and solve at least three popular issues.
>>> Please see:
>>> https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
>>>  
>>> 
>> I am *completely* against this proposal.
>> 
>> Fundamentally, you're trying to address the limitation that protocols with 
>> Self or associated type requirements can't be existential. But it's just a 
>> limitation that isn't (conceptually) that hard to fix: the primary operation 
>> you need to work with an existing of such a protocol is to "open" a value of 
>> existential type, giving a name to the dynamic type it stores. Let's invent 
>> one:
>> 
>>   func eq(x: Equatable, y: Equatable) -> Bool {
>> // give the name T to the dynamic type stored in xT
>> let xT = open x as T
>> // is y also storing a T?
>> guard let yT = y as? T else { return false }
>> // check whether the Ts are equal
>> return xT == yT
>>   }
>> 
>> Ignore the syntax: semantically, we've gone from a "dynamic" existential 
>> thing back to something more "static", just by giving a name to the type. 
>> Swift generics aren't really even static in any sense: what the do is give 
>> names to the types of values so one can establish relationships among 
>> different values. "open..as" would do that for existentials. 
>> 
>> Note that ether Swift compilers AST and SIL both have "open existential" 
>> operations that do this internally. They have no spelling in Swift code, but 
>> they are useful to describe operations on existentials. At present, they 
>> cannot be formed when the existential involves a protocol with Self or 
>> associated type requirements, but that's a limitation that isn't hard to 
>> address. 
>> 
>> As for your concerns about knowing when one can dynamically override and 
>> when one cannot...  There are issues here that need to be addressed. They 
>> aren't significant enough to warrant such a drastic change, and may not even 
>> require language changes at all. 
>> 
>>  - Doug
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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

Re: [swift-evolution] Empower String type with regular expression

[Trent Nadeau via swift-evolution]

Also https://github.com/rust-lang-nursery/regex, which is the process of
possibly being standardized either in the Rust stdlib or as a fully
supported crate (library). That crate is based on
https://github.com/google/re2 that is written in C++. Both could be used
for implementation ideas.

On Mon, Jan 4, 2016 at 9:52 AM, Vincent Esche via swift-evolution <
swift-evolution@swift.org> wrote:

> There is actually a Rust crate doing exactly that:
> https://github.com/jneem/regex-dfa
> Rust however has powerful compile-time macros, enabling this, which Swift
> doesn’t (yet?).
>
> On 04 Jan 2016, at 02:53, Austin Zheng via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> +1 on first-class regex support/pattern matching on regex patterns.
>
> There was a thread a while ago discussing compile-time code generation,
> and if I recall correctly one of the stated use cases was
> 'compiling'/'building' (don't know the real terminology) regex literals at
> compile-time. Is there a bigger overall vision for this sort of feature, or
> would it be better to just focus on better regex support?
>
> Best,
> Austin
>
> On Sun, Jan 3, 2016 at 1:35 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Jan 1, 2016, at 4:44 PM, John Joyce via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> It is also probably worth burning first-class language support for regexes.  
>> This would allow specifying variable captures inline in the pattern, would 
>> allow flexible syntax for defining regexes, support powerful extensions to 
>> the base regex model (e.g. Perl 6 style), and would provide better 
>> compile-time checking and error recovery for mistakes.
>>
>> -Chris
>>
>> I know this is an old thread already, but this sure would be one of the
>> major breakout pieces of functionality.
>> If Swift had native regular expressions, without all the noise you see in
>> the Objective-C API that exposes ICU regular expressions, the adoption rate
>> would be huge.
>> If they were *truly* native, as in somebody sat down and built an NFA (or
>> one of the fancier approaches that mixes with DFA) state machine, Swift's
>> best-in-class Unicode support would and could result in amazing things.
>> It'd boost the scripting use of Swift tremendously and seal the deal as a
>> server side language.
>>
>>
>> Totally agreed.  switch on a string with a bunch of regexes being matched
>> should turn into a parallel state machine, just like a lexer :-)
>>
>> -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
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


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