Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

2016-06-12 Thread L. Mihalkovic via swift-evolution
Regards (From mobile) > On Jun 11, 2016, at 11:43 PM, Thorsten Seitz wrote: > > > >> Am 11.06.2016 um 15:08 schrieb L. Mihalkovic : >> >> >>> On Jun 11, 2016, at 2:05 PM, Thorsten Seitz wrote: >>> >>> Am 11.06.2016 um 12:38 schrieb L. Mihalkovic : > On Jun 11,

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

2016-06-12 Thread L Mihalkovic via swift-evolution
> On Jun 12, 2016, at 6:05 AM, Alexander Momchilov > wrote: > > Aren't macros totally different? > > Anyways, weren't macros rejected? I thought Swift was trying to avoid having > the hefty reliance of preprocessor macros that C did. Sorry I was not referring to C-style macros (i.e. preproc)

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

2016-06-12 Thread L Mihalkovic via swift-evolution
> On Jun 11, 2016, at 11:45 PM, Xiaodi Wu wrote: > > > > On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz > wrote: > > > Am 11.06.2016 um 22:29 schrieb L. Mihalkovic >: > >> >> >> On Jun 11, 2016, at 9:53 PM, Thorsten Seitz

Re: [swift-evolution] [Discussion] Type hierarchy translation consistency

2016-06-12 Thread Adrian Zubarev via swift-evolution
Just looked up the current implementation of this: extension String { /// The index type for subscripting a string. public typealias Index = CharacterView.Index /// A type used to represent the number of steps between two `String.Index` /// values, where one value is reachable from the ot

Re: [swift-evolution] [Discussion] Type hierarchy translation consistency

2016-06-12 Thread Dmitri Gribenko via swift-evolution
On Sun, Jun 12, 2016 at 3:33 AM, Adrian Zubarev via swift-evolution wrote: > Just looked up the current implementation of this: > > extension String { > /// The index type for subscripting a string. > public typealias Index = CharacterView.Index > > /// A type used to represent the number of

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

2016-06-12 Thread Haravikk via swift-evolution
> On 12 Jun 2016, at 09:47, L Mihalkovic via swift-evolution > wrote: > > >> On Jun 12, 2016, at 6:05 AM, Alexander Momchilov >> mailto:alexandermomchi...@gmail.com>> wrote: >> >> Aren't macros totally different? >> >> Anyways, weren't macros rejected? I thought Swift was trying to avoid ha

[swift-evolution] [Draft] Tuple-Based Compound Optional Binding

2016-06-12 Thread Brent Royal-Gordon via swift-evolution
When I suggested this syntax in the acceptance thread for SE-0099, Chris said it should be written up as a proposal. I'm sure this will get lost in the WWDC shuffle, but here goes. Tuple-Based Compound Optional Binding Proposal: TBD Author: Brent Royal-Gordon Status:

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

2016-06-12 Thread Pyry Jahkola via swift-evolution
> On 12 Jun 2016, at 14:46, Brent Royal-Gordon via swift-evolution > wrote: > > guard let (a, b, c) = (opt1, opt2, opt3) else { ... } You mention `guard case` in the motivation, but I think for the uninitiated reader it would be fair to point out that the following example already works equi

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

2016-06-12 Thread plx via swift-evolution
> On Jun 10, 2016, at 12:59 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jun 10, 2016 at 12:30 PM, let var go > wrote: > I respect that anti-goal, but I think being over-rigid about limiting > developers' choice of expression is also an anti-goal. > > To

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

2016-06-12 Thread Антон Жилин via swift-evolution
I've prepared a proper draft: https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/-generic-protocols.md - Anton 2016-06-10 17:18 GMT+03:00 Brent Royal-Gordon : > > FWIW they're marked as 'unlikely' here: > https://github.com/apple/swift/blob/master/docs/GenericsManife

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

2016-06-12 Thread Brandon Knope via swift-evolution
Well now you have me intrigued. I must read more about Linq now Brandon Sent from my iPad > On Jun 12, 2016, at 6:02 AM, L Mihalkovic via swift-evolution > wrote: > > >> On Jun 11, 2016, at 11:45 PM, Xiaodi Wu wrote: >> >> >> >> On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz wrote: >>>

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

2016-06-12 Thread Adrian Zubarev via swift-evolution
What is the status for this idea? I can’t find the proposal for this. :( --  Adrian Zubarev Sent with Airmail ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-06-12 Thread Thorsten Seitz via swift-evolution
> Am 12.06.2016 um 12:02 schrieb L Mihalkovic : > > >> On Jun 11, 2016, at 11:45 PM, Xiaodi Wu > > wrote: >> >> >> >> On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz > > wrote: >> >> >> Am 11.06.2016 um 22:29 schrieb L. Mihalkovic >

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

2016-06-12 Thread Thorsten Seitz via swift-evolution
> Am 12.06.2016 um 00:16 schrieb Xiaodi Wu : > > On Sat, Jun 11, 2016 at 5:07 PM, Thorsten Seitz > wrote: > > > Am 11.06.2016 um 23:52 schrieb Xiaodi Wu >: > >> On Sat, Jun 11, 2016 at 3:31 PM, Thorsten Seitz >

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

2016-06-12 Thread Thorsten Seitz via swift-evolution
Looks good to me! -Thorsten > Am 12.06.2016 um 15:01 schrieb Антон Жилин via swift-evolution > : > > I've prepared a proper draft: > > https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/-generic-protocols.md > >

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

2016-06-12 Thread L. Mihalkovic via swift-evolution
> On Jun 12, 2016, at 3:21 PM, Thorsten Seitz wrote: > > >>> Am 12.06.2016 um 12:02 schrieb L Mihalkovic : >>> >>> >>> On Jun 11, 2016, at 11:45 PM, Xiaodi Wu wrote: >>> >>> >>> >>> On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz wrote: > Am 11.06.2016 um 22:29 schrieb L.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

2016-06-12 Thread L. Mihalkovic via swift-evolution
> On Jun 12, 2016, at 4:05 PM, Thorsten Seitz wrote: > > >> Am 12.06.2016 um 09:21 schrieb L. Mihalkovic : >> >> >> >> >> Regards >> (From mobile) >> On Jun 11, 2016, at 11:43 PM, Thorsten Seitz wrote: >> >>> >>> Am 11.06.2016 um 15:08 schrieb L. Mihalkovic :

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

2016-06-12 Thread L Mihalkovic via swift-evolution
> On Jun 12, 2016, at 4:05 PM, Thorsten Seitz wrote: > >> >> Am 12.06.2016 um 09:21 schrieb L. Mihalkovic > >: >> >> >> >> >> Regards >> (From mobile) >> On Jun 11, 2016, at 11:43 PM, Thorsten Seitz > > wrote: >> >>> >>> >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

2016-06-12 Thread Thorsten Seitz via swift-evolution
> Am 12.06.2016 um 17:40 schrieb L Mihalkovic : > >> >> On Jun 12, 2016, at 4:05 PM, Thorsten Seitz > > wrote: >> >>> >>> Am 12.06.2016 um 09:21 schrieb L. Mihalkovic >> >: >>> >>> >>> >>> >>> Regards >>> (From mobile) >>> On

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

2016-06-12 Thread Brent Royal-Gordon via swift-evolution
>> guard let (a, b, c) = (opt1, opt2, opt3) else { ... } > > You mention `guard case` in the motivation, but I think for the uninitiated > reader it would be fair to point out that the following example already works > equivalently, with only a few extra characters: > > guard case let (a?, b?,

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

2016-06-12 Thread Xiaodi Wu via swift-evolution
On Sun, Jun 12, 2016 at 6:46 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > When I suggested this syntax in the acceptance thread for SE-0099, Chris > said it should be written up as a proposal. I'm sure this will get lost in > the WWDC shuffle, but here goes. > T

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

2016-06-12 Thread Xiaodi Wu via swift-evolution
On Sun, Jun 12, 2016 at 8:01 AM, Антон Жилин wrote: > I've prepared a proper draft: > > > https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/-generic-protocols.md > > When you propose this: Syntax in protocol extensions protocol MyComparable { func < (left: Self, ri

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

2016-06-12 Thread Антон Жилин via swift-evolution
Yes, everything that works on generic types should work for generic protocols. I'll add that. What won't work is declaring that MyComparable : Comparable iff T == Self. The same won't work for current non-generic protocols as well. Although that feature is highly requested, it is discussed in a

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

2016-06-12 Thread L. Mihalkovic via swift-evolution
It takes reaching the last section of the proposal to understand that there is not real issue, that it does not add any functionality, and that it basically amount to stylistic preference for something. It might be more informative to start with that rather than leave it until the end. > On Jun

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

2016-06-12 Thread Dan Appel via swift-evolution
Awesome that you guys started this! I've been meaning to pitch it for a while. Couple notes: - in the motivation, you're conforming to SequenceType while defining a From protocol (just a typo I think) - the proposal should mention Brent's comments since it doesn't have a rebuttal to the "unlikely"

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

2016-06-12 Thread Adrian Zubarev via swift-evolution
If there is no proposal yet, I could write one. We should sketch out what we should consider for nested protocols. I’d love to see this feature in Swift 3. :) Should this be allowed? I’m not sure what and what not we’ll see of generics in Swift 3. // A.P1 class A { protocol P1: clas

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

2016-06-12 Thread Антон Жилин via swift-evolution
Copy of link to the proposal: https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/-generic-protocols.md Inline: 2016-06-12 21:51 GMT+03:00 Dan Appel : > Awesome that you guys started this! I've been meaning to pitch it for a > while. Couple notes: > > - in the motivati

[swift-evolution] updated documentation with each snapshot?

2016-06-12 Thread Dave Yost via swift-evolution
Sure would be nice if each snapshot would include updated language and library documentation. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-06-12 Thread Dan Appel via swift-evolution
>if our protocol conforms to a protocol with associated type requirements, then we still can't conform to our protocol multiple times. I don't think so: protocol A { associatedtype TypeA } protocol B: A { func convert(from: TypeB) -> TypeA } struct C: A { typealias TypeA = St

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

2016-06-12 Thread David Sweeris via swift-evolution
+1 Sent from my iPhone > On Jun 12, 2016, at 08:01, Антон Жилин via swift-evolution > wrote: > > I've prepared a proper draft: > > https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/-generic-protocols.md > > - Anton > > 2016-06-10 17:18 GMT+03:00 Brent Royal-Gord

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

2016-06-12 Thread Антон Жилин via swift-evolution
Right. If associated type has the same value for both conformances, then everything should be fine. Fixed that example. - Anton 2016-06-13 0:15 GMT+03:00 Dan Appel : > >if our protocol conforms to a protocol with associated type requirements, > then we still can't conform to our protocol multipl

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

2016-06-12 Thread Xiaodi Wu via swift-evolution
On Sun, Jun 12, 2016 at 7:10 AM, plx via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 10, 2016, at 12:59 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Fri, Jun 10, 2016 at 12:30 PM, let var go wrote: > >> I respect that anti-goal, but I think bei

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

2016-06-12 Thread Xiaodi Wu via swift-evolution
On Sun, Jun 12, 2016 at 8:28 AM, Thorsten Seitz wrote: > > Am 12.06.2016 um 00:16 schrieb Xiaodi Wu : > > On Sat, Jun 11, 2016 at 5:07 PM, Thorsten Seitz > wrote: > >> >> >> Am 11.06.2016 um 23:52 schrieb Xiaodi Wu : >> >> On Sat, Jun 11, 2016 at 3:31 PM, Thorsten Seitz >> wrote: >> >>> >>> >>>

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

2016-06-12 Thread Xiaodi Wu via swift-evolution
On Sun, Jun 12, 2016 at 9:23 AM, L. Mihalkovic wrote: > > On Jun 12, 2016, at 3:21 PM, Thorsten Seitz wrote: > > > Am 12.06.2016 um 12:02 schrieb L Mihalkovic >: > > > On Jun 11, 2016, at 11:45 PM, Xiaodi Wu wrote: > > > > On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz > wrote: > >> >> >> Am

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

2016-06-12 Thread Brent Royal-Gordon via swift-evolution
> It takes reaching the last section of the proposal to understand that there > is not real issue, that it does not add any functionality, and that it > basically amount to stylistic preference for something. It might be more > informative to start with that rather than leave it until the end.

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

2016-06-12 Thread plx via swift-evolution
This proposal should specify if the tuple is evaluated “eagerly” or as an “early-exit”. That is, if we write `if let (foo,bar,baz) = (_foo(), _bar(), _baz())`, and _bar() -> nil, will `_baz()` have been evaluated, or not? I’d use this feature either way, but the proposal should have a clear st

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

2016-06-12 Thread Xiaodi Wu via swift-evolution
What's the behavior currently with `if case let (foo?, bar?, baz?)...`? On Sun, Jun 12, 2016 at 19:53 plx via swift-evolution < swift-evolution@swift.org> wrote: > This proposal should specify if the tuple is evaluated “eagerly” or as an > “early-exit”. > > That is, if we write `if let (foo,bar,ba

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

2016-06-12 Thread plx via swift-evolution
> > First, notice how your comment is related to the `where` clause but is > actually sitting on top of the loop itself. Second, one of these two tests > visits every element while the other doesn't, and it took me three reads > before I could see that because I literally couldn't find the `whe

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

2016-06-12 Thread Dave Abrahams via swift-evolution
on Fri Jun 10 2016, Thorsten Seitz wrote: >> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution >> : >> >> >>> Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution >>> : >>> > >>> >>> on Wed Jun 08 2016, Jordan Rose wrote: >>> > On Jun 8, 2016, at 13:16, Da

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

2016-06-12 Thread Dave Abrahams via swift-evolution
on Sun Jun 12 2016, L Mihalkovic wrote: > My understanding is that dave is the type system designer. That would be a misunderstanding. I am a contributor, but other people take the lead on the type system. -- Dave ___ swift-evolution mailing list s

Re: [swift-evolution] Remove nil and NilLiteralConvertible

2016-06-12 Thread E. Maloney via swift-evolution
> On Jun 8, 2016, at 4:59 PM, Brandon Knope via swift-evolution > wrote: > > Is it really an implementation detail? It is very leaky if it is one because > it is highly exposed to everyone. It’s only as leaky as you want it to be. We have two shipping apps with large codebases using Swift, a

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

2016-06-12 Thread Charlie Monroe via swift-evolution
> And to follow-up to myself once again, I went to my "Cool 3rd Party Swift > Repos" folder and did the same search. Among the 15 repos in that folder, a > joint search returned about 650 hits on for-in (again with some false > positives) and not a single for-in-while use. > > -- E Not to unde

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

2016-06-12 Thread Charlie Monroe via swift-evolution
> On Jun 11, 2016, at 5:18 AM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jun 10, 2016 at 9:55 PM, Jonathan Hull via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > I really love this idea. My mental model of it is that it is exactly like > ‘defer’, except it works on t

Re: [swift-evolution] Nil coalescing operator precedence

2016-06-12 Thread Charlie Monroe via swift-evolution
+1 on this. > On Jun 12, 2016, at 8:01 AM, Andrey Fidrya via swift-evolution > wrote: > > Nil coalescing operator has very low precedence and it's very easy to forget > the parentheses. > It's tempting to write something like this: > > let result = v1 ?? 0 + v2 ?? 0 > > Which will resolve to

Re: [swift-evolution] [Pitch] Make `default` function parameter values more transparent

2016-06-12 Thread Charlie Monroe via swift-evolution
> On Jun 11, 2016, at 3:35 PM, Adrian Zubarev via swift-evolution > wrote: > > I just installed the current Swift 3 snapshot to play around with it (last > from may crashed my Xcode all the time). > > I wanted to re-build a small project with (currently implemented) Swift 3 > changes. Basica

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

2016-06-12 Thread Jose Cheyo Jimenez via swift-evolution
--1 I think it would be a waste of the community's time to do a formal review when only two people are in favor of this removal. 'for in where' is so useful especially since we don't have for;;; loops anymore. I'd say leave this alone; the majority doesn't want this changed. > On Jun 10, 2