Re: [swift-evolution] Proposal: CollectionType.cycle property for an infinite sequence

+1. Stream support is long overdue. ~Robert Widmann 2015/12/28 2:20、Kevin Ballard via swift-evolution のメッセージ: > ## Introduction > > Add a new property `cycle` to CollectionType that returns an infinite > SequenceType that yields the elements of the collection in a loop. > > ## Motivation >

[swift-evolution] Proposal: CollectionType.cycle property for an infinite sequence

## Introduction Add a new property `cycle` to CollectionType that returns an infinite SequenceType that yields the elements of the collection in a loop. ## Motivation It's sometimes useful to be able to have an infinite sequence. For example, `CollectionOfOne(x).cycle` could be used to have an

Re: [swift-evolution] [Pitch] Guarding on enum values

> Am 28.12.2015 um 02:31 schrieb Kevin Ballard via swift-evolution > : > > You actually can do simple let-bindings in if-let and guard-let via the `case > let` syntax: > > guard case let r = returnsResult(), case let .Succeed(m) = r else { ... } > > Although the problem with this is `r` stil

Re: [swift-evolution] [Idea] Add an (Index, Element) sequence to CollectionType

> What you're asking for can already be done with `zip(col.indices, col)`. And > in my experience the need for this sort of thing is rare enough that there's > no need to have a dedicated property for it in the stdlib. The few times that > I've needed this sort of thing, I've always just said >

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

Commentary inline below. FKL > On Dec 27, 2015, at 8:40 PM, Douglas Gregor wrote: > > >> On Dec 27, 2015, at 12:27 AM, Frederick Kellison-Linn via swift-evolution >> wrote: >> >> Given that someView.insertSubview(_:at:) can be correctly parsed, I would >> strongly lean towards the no-backt

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> Am 28.12.2015 um 01:15 schrieb Chris Lattner via swift-evolution > : > > (just a strawman, intentionally ugly syntax): > >foo.#bar Much prettier than backticks IMHO. -Thorsten ___ swift-evolution mailing list swift-evolution@swift.org https:/

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

> So “try” instead of “do”. If there is no catch, then just use braces without > a keyword for a block. > > And use do-while instead of repeat-while. Do you also propose no longer marking calls to throwing functions with `try`? Have you read the "Error-Handling Rationale" document in the Swift

Re: [swift-evolution] Lambda function syntax

Just reread my reply and found it a bit unclear, so I'm trying to fix that below :-) > Am 28.12.2015 um 07:08 schrieb Thorsten Seitz via swift-evolution > : > > > Am 27.12.2015 um 23:24 schrieb Brent Royal-Gordon via swift-evolution > : > >>> In this mail I’m answering several statements mad

Re: [swift-evolution] Lambda function syntax

By almost everybody that's actually posted to this thread. That's a hugely important distinction. Personally, I like "in". -Kevin Ballard On Sun, Dec 27, 2015, at 02:56 PM, Alexander Regueiro via swift-evolution wrote: > It’s been agreed by almost everyone that “in” is at the very least a poor

Re: [swift-evolution] Lambda function syntax

Am 27.12.2015 um 23:24 schrieb Brent Royal-Gordon via swift-evolution : >> In this mail I’m answering several statements made in this thread by >> different people, not only Brent’s mail from which I just picked the >> following snippet: >> >>> let names = people.map => person { person.name }

Re: [swift-evolution] [Idea] Add an (Index, Element) sequence to CollectionType

What you're asking for can already be done with `zip(col.indices, col)`. And in my experience the need for this sort of thing is rare enough that there's no need to have a dedicated property for it in the stdlib. The few times that I've needed this sort of thing, I've always just said for index in

Re: [swift-evolution] User Defined Annotations

It can’t hurt to work on a proof of concept, but I think it’s worth exploring the space of possible designs before jumping too far into an implementation. I have some code that adds an “annotation” declaration and adds a new attribute kind for custom annotations, though it still needs some work

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 27, 2015, at 12:27 AM, Frederick Kellison-Linn via swift-evolution > wrote: > > Given that someView.insertSubview(_:at:) can be correctly parsed, I would > strongly lean towards the no-backtick alternative mentioned at the end. I > feel as though the backticks end up looking very clu

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 27, 2015, at 4:27 PM, John McCall wrote: > >> On Dec 27, 2015, at 4:15 PM, Chris Lattner wrote: >> >> On Dec 27, 2015, at 4:09 PM, John McCall wrote: I’m a fan of good error recovery, but I don’t think it is a major concern here for two reasons: 1) The most comm

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

I think it would be of great value to post both here and at the bug itself. Thanks! -- E, looking forward to it > On Dec 27, 2015, at 8:22 PM, Taras Zakharko > wrote: > > Ah, thank you for pointing this out! I think I would suggest a change or two > to your proposal, but I need to flesh them

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 27, 2015, at 4:54 PM, Wallacy wrote: > How to differentiate these functions? Doug talked about this some in his proposal. John. > > class A{ > func someFunc(a: Int) -> Int{ > return 0; > } > func someFunc(a: Int) -> Double{ > return 0; > } > func so

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

Ah, thank you for pointing this out! I think I would suggest a change or two to your proposal, but I need to flesh them out first. Is it possible to leave comments on the bug site? BTW, why was it delegated to the bug report system in the first place? > On 28 Dec 2015, at 02:28, Erica Sadun v

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

Same is true for the implicit self, and yet we’ve seen how people react to making self explicit. There are many places in contemporary Apple programming where this could be of great utility. For instance, I miss a lexical scope construction every time I work with Metal. > On 28 Dec 2015, at 0

Re: [swift-evolution] [Pitch] Guarding on enum values

You actually can do simple let-bindings in if-let and guard-let via the `case let` syntax: guard case let r = returnsResult(), case let .Succeed(m) = r else { ... } Although the problem with this is `r` still isn't visible inside of the else block, because it's part of the guard statement and n

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

The most common use-case for this is with Cocoa classes, which are not set up for fluent implementation. A preliminary proposal (which I am not updating since the matter was referred to the bug report system) is here: https://gist.github.com/erica/6794d48d917e2084d6ed Hopefully it explains the

Re: [swift-evolution] [Pitch] Guarding on enum values

On Wed, Dec 23, 2015, at 03:35 PM, Joe Groff via swift-evolution wrote: > A slight generalization would be to allow for an arbitrary pattern in the > `else` clause: > > guard case let .Succeed(m) = returnsResult() else case let .Failure(r) { >return r > } > > with the requirement that th

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

-1 doesn't seem worth adding it is not a lot of trouble to type `obj.` at the start of every line. Also if an API is intended to be used like that its methods would return `self` and it would be used in a FLUENT style. Sent from my iPad > On 28 Dec 2015, at 9:00 AM, Erica Sadun via swift-evolu

Re: [swift-evolution] Lambda function syntax

Sorry, i misread you mail. Em dom, 27 de dez de 2015 às 23:20, Developer escreveu: > Oh my, no. I don't intend Swift to become the λ calculus, I was merely > making an analogy (and a joke, 3 replies ago). In the same way that λ is > the simplest set of rules embodying the powerful construct ab

Re: [swift-evolution] Lambda function syntax

Oh my, no. I don't intend Swift to become the λ calculus, I was merely making an analogy (and a joke, 3 replies ago). In the same way that λ is the simplest set of rules embodying the powerful construct abstraction is, Swift's syntax for it is probably the simplest and best we can get given th

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

*"if you add a `someFunc` overload taking a different parameter name but the same types the above code becomes ambiguous."* Yes, I know, I forgot this example. Ironically that was the intent, but I do not choose good examples. I was just exploring the idea of having to display the full signature

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

Le 27 déc. 2015 à 19:54, Wallacy via swift-evolution a écrit : > Even with backticks would not be possible. > > You may need to reference the method signature altogether. > > var someA = A() > let fn1 = someA.#someFunc(a: Int) -> Int > let fn2 = someA.#someFunc(a: Int) -> Double > let fn3 = so

Re: [swift-evolution] Lambda function syntax

So how do you expect me to type "naturally" the character λ? Not all keyboards are equal, are different languages around the world, with different keyboard layouts. However in all I can type "in" but not this symbol that can only reproduce by copying and pasting. Em dom, 27 de dez de 2015 às 21:

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

How to differentiate these functions? class A{ func someFunc(a: Int) -> Int{ return 0; } func someFunc(a: Int) -> Double{ return 0; } func someFunc(a: Double) -> Int{ return 0; } func someFunc(a: Double) -> Double{ return 0; } func

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 27, 2015, at 4:15 PM, Chris Lattner wrote: > > On Dec 27, 2015, at 4:09 PM, John McCall wrote: >>> I’m a fan of good error recovery, but I don’t think it is a major concern >>> here for two reasons: >>> >>> 1) The most common case in a method will lack a label, and "thing.foo(_: “ >>

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

On Dec 27, 2015, at 4:09 PM, John McCall wrote: >> I’m a fan of good error recovery, but I don’t think it is a major concern >> here for two reasons: >> >> 1) The most common case in a method will lack a label, and "thing.foo(_: “ >> and “thing.foo(:” are both unambiguously a curried reference.

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 27, 2015, at 4:02 PM, Chris Lattner via swift-evolution > wrote: > On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >>> can be correctly parsed as a reference to insertSubview(_:at:). However, it >>> breaks down at the margins, e.g

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution wrote: >> can be correctly parsed as a reference to insertSubview(_:at:). However, it >> breaks down at the margins, e.g., with getter/setter references or >> no-argument functions: >> >> extension Optional { >> func get() -> T { re

Re: [swift-evolution] Lambda function syntax

Notation is not an arbitrary construct, and the choice of how to represent a λ-abstraction isn’t either. When Church designed the calculus, he chose just 3 simple constructs: variables, abstractions, and applications, to be the entirety of the language. Readability in the system is derived fro

Re: [swift-evolution] Lambda function syntax

Yes, please do. It is perfectly fine to disagree on technical points, but please do so with respect. -Chris > On Dec 27, 2015, at 3:44 PM, Austin Zheng via swift-evolution > wrote: > > Please treat your fellow contributors with respect and equanimity. > > Best, > Austin > >> On Dec 27, 201

Re: [swift-evolution] Lambda function syntax

Please treat your fellow contributors with respect and equanimity. Best, Austin > On Dec 27, 2015, at 3:38 PM, Alexander Regueiro via swift-evolution > wrote: > > Then you clear know nothing of the history of computer science. I repeat, the > original syntax of the lambda calculus, to which y

Re: [swift-evolution] Lambda function syntax

Then you clear know nothing of the history of computer science. I repeat, the original syntax of the lambda calculus, to which you were referring, was *not* designed for readability. Its purpose was entirely different. This is only the start of the differences – there really isn’t anything to be

Re: [swift-evolution] Lambda function syntax

Now, now, that's no way to talk about a century's worth of computing research. Since you have yet to respond to my original point, I'll expound: I see Swift's choice of "in" in context of other programming languages that admit anonymous inner scopes with little fuss. Those tend to come from the

Re: [swift-evolution] Lambda function syntax

The lambda calculus is a mathematical tool. It’s not designed for readability. Your point is invalid. > On 27 Dec 2015, at 23:03, Developer wrote: > > With a proper λ, that's the point. The lambda calculus doesn't focus on the > delimiter between the binder and the body because it isn't the i

Re: [swift-evolution] Lambda function syntax

With a proper λ, that's the point. The lambda calculus doesn't focus on the delimiter between the binder and the body because it isn't the important part of an abstraction, the rest is. I would argue a programming language shouldn't either. What is to be gained by having more syntax around a

Re: [swift-evolution] Lambda function syntax

It’s been agreed by almost everyone that “in” is at the very least a poor delimiter. It’s barely noticeable. > On 27 Dec 2015, at 22:54, Developer wrote: > > Hell, we have Unicode support, why not λ (U+03BB)? Seriously though, for a > C-like language I have to agree that Swift's approach is o

Re: [swift-evolution] Lambda function syntax

Hell, we have Unicode support, why not λ (U+03BB)? Seriously though, for a C-like language I have to agree that Swift's approach is one of the best. I can't think of a way of improving it that wouldn't immediately clash with the style and syntax of the language. Sure you could change a few ke

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution > wrote: >> Getters and setters can be written using dotted syntax within the back-ticks: >> >> let specificTitle = button.`currentTitle.get` // has type () -> String? >> let otherTitle = UIButton.`currentTitle.get` // has type (UIBu

Re: [swift-evolution] Epic: Typesafe calculations

> On Dec 27, 2015, at 2:56 AM, Tino Heth <2...@gmx.de> wrote: > > >> There’s some unfortunate extra boilerplate here, which could be better >> handled with newtype support in the language, but when compiled with >> optimizations the resulting code is nearly identical to using plain Ints. > >

Re: [swift-evolution] Lambda function syntax

> In this mail I’m answering several statements made in this thread by > different people, not only Brent’s mail from which I just picked the > following snippet: > >> let names = people.map => person { person.name } > > For me that is more difficult to read than > > let names = people.m

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

I believe this has popped up on-list a few times. Search for method cascades: cascading site:https://lists.swift.org/pipermail/swift-evolution/ https://www.google.com/?gws_rd=ssl#q=cascading+site:https:%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F Other search terms include dart, initia

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

Hi, Please find my comment in body: BR, Radek Smogura > On 27 Dec 2015, at 22:08, Taras Zakharko wrote: > > >> On 27 Dec 2015, at 21:55, Mosab Elagha > > wrote: >> >> Agreed, this seems like a great idea. Looks like it would also allow for a >> lot of customizat

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

> On 27 Dec 2015, at 21:55, Mosab Elagha wrote: > > Agreed, this seems like a great idea. Looks like it would also allow for a > lot of customization - for example out of one "template" object. > > Would the object have to already be initialized or could you initialize it > from this? IMO it

Re: [swift-evolution] Proposal for Package Manager Testing Infrastruture

My apologies for the delay on this – this has been waiting on me to accept the pull request and schedule the formal review. Apple is on holiday shutdown at the moment so things are moving slowly right now. I will accept the PR soon and expect to schedule the review for the first week of January.

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

Agreed, this seems like a great idea. Looks like it would also allow for a lot of customization - for example out of one "template" object. Would the object have to already be initialized or could you initialize it from this? IMO it would have to already be initialized or else it might lead to con

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

I would add to what Joe mentioned above the fact that the concept of "selector" may not mean a whole lot to developers who are first introduced to Swift without any prior Obj-C or Cocoa experience. Thinking of them as functions I believe avoids introducing complexity in the form of additional conce

Re: [swift-evolution] Beef up Imports

The 'except' change is interesting, but it's still a context switch that can wind up confusing people. I think that's partly why Agda has the 'renaming' operation separate in the first place. ~Robert Widmann 2015/12/27 10:30、T.J. Usiyan via swift-evolution のメッセージ: > import Foo using (bar, B

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

Some more things to consider: - Our naming conventions encourage the first parameter to most methods to be unlabeled, so unlabeled parameters come up a lot. I don't think there's a grammatical requirement for an identifier before each colon; maybe we can leave out the underscore and use `foo(:b

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

Hi, That’s a great idea! Kind regards, Radek > On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution > wrote: > > Quite often, one needs to perform a number of operations on a single object > (e.g. call up a bunch of configuration or action methods). This proposal is > to extend the

[swift-evolution] [Proposal] Lexical scope statement (with .. do)

Quite often, one needs to perform a number of operations on a single object (e.g. call up a bunch of configuration or action methods). This proposal is to extend the ‘do' statement with an explicit lexical scope feature. For instance, this piece of code object.do_something() object.do_someth

Re: [swift-evolution] swift-evolution Digest, Vol 1, Issue 237

I think that throwing out our effort is bed idea. Waiting for reflection system may cause that implementation of attributes will be impossible - both of those things should be done together! Maybe it would be good to work on agile, iterative bases? What do you think about defining for MVP - par

Re: [swift-evolution] Proposal: Expose getter/setters in the same way as regular methods

> On Dec 27, 2015, at 4:23 AM, Tino Heth <2...@gmx.de> wrote: > >> >> Of course, if you’re worried about the performance costs associated with >> that extra method call, you might want to include a keyword, such as >> “observable”, and only generate the method call(s) if that keyword is on the

Re: [swift-evolution] swift-evolution Digest, Vol 1, Issue 237

Well, it seems that we will have to wait for the reflection mechanism to be in place. Best El 26/12/2015, a las 20:25, Akiva Leffert mailto:aleff...@gmail.com>> escribió: I started off a thread about this a while back: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution > wrote: > > Hi all, > > Here’s a proposal draft to allow one to name any function in Swift. In > effect, it’s continuing the discussion of retrieving getters and setters as > functions started by Michael Henson here: > >

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

> On Dec 26, 2015, at 11:48 PM, Douglas Gregor via swift-evolution > wrote: > > Hi all, > > Currently, producing an Objective-C selector in Swift is an error-prone > operation. One effectively just writes a string literal and uses it in a > context where an ObjectiveC.Selector is expected: >

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

Great idea, but why make it a free function instead of a Selector initializer? let sel1 = Selector(UIView.`insertSubview(_:at:)`) let sel2 = Selector(UIView.`frame.get`) Of course if there were such a thing as GeneralizedFunctionNameLiteralConvertible, we could get a “free” conversion to

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

> On Dec 26, 2015, at 11:31 PM, Chris Lattner wrote: > > On Dec 25, 2015, at 12:04 PM, Matthew Johnson > wrote: Discussion on a couple of topics continues inline below as well. >>> >>> Great, comments below: >> >> Thanks for continuing the discussion. I ha

Re: [swift-evolution] Failable Initializer Suggestion

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’

Re: [swift-evolution] [Pitch] Guarding on enum values

The problem is that currently the if-let and guard-let syntax is reserved for unwrapping optionals and therefore cannot be used (at least not unambiguously) for simple let-bindings as well, which is required here. My example therefore needs the following change (sorry, I did not make this expli

Re: [swift-evolution] Failable Initializer Suggestion

> How do you guys think of that? Makes sense. Failable init has its roots in Objective-C, throws is a better fit for Swift — but it is not trivial to change all Cocoa class to throw instead of returning nil (at least in theory — most likely many classes don't have that many reasons for a possib

Re: [swift-evolution] Beef up Imports

> T.J. Usiyan wrote: > > import Foo using (bar, Baz, qux, waldo as fred) // a "whitelist import" > import Foo hiding (bar, Baz, qux, waldo as fred) // a "blacklist import" > > Is nice but `hiding… (waldo as fred)` is confusing. Am I hiding waldo? You're right That's also what Robert pointed ou

Re: [swift-evolution] Beef up Imports

*import* Foo *using* (bar, Baz, qux, waldo *as* fred) // a "whitelist import" *import* Foo *hiding* (bar, Baz, qux, waldo *as* fred) // a "blacklist import" Is nice but `hiding… (waldo as fred)` is confusing. Am I hiding waldo? It is also strange to look in that list for things that I am hiding

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

So “try” instead of “do”. If there is no catch, then just use braces without a keyword for a block. And use do-while instead of repeat-while. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evo

Re: [swift-evolution] Beef up Imports

> On 27 Dec 2015, at 07:12, Developer via swift-evolution > wrote: > > Therefore, I propose the introduction of 3 agda-esque operations for imports > to replace the usual `import {func|typealias|struct|class|enum|etc.}` syntax: > > • import Foo using (bar, Baz, qux, corge, …) > • i

[swift-evolution] Failable Initializer Suggestion

Hello. 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: class AClass { init() throws {

Re: [swift-evolution] Epic: Typesafe calculations

> There’s some unfortunate extra boilerplate here, which could be better > handled with newtype support in the language, but when compiled with > optimizations the resulting code is nearly identical to using plain Ints. Cool — have you checked the generated assembler for this conclusion? But I

Re: [swift-evolution] Epic: Typesafe calculations

> There seem to me to be multiple ways to solve this problem - a newtype(esque) > keyword, struct subtyping, or forwarding as Matthew is suggesting Imho it would make sense to start a topic about inheritance for structs — of cause there a good theories why this isn't possible, but subtyping on

Re: [swift-evolution] Proposal: Expose getter/setters in the same way as regular methods

> Of course, if you’re worried about the performance costs associated with that > extra method call, you might want to include a keyword, such as “observable”, > and only generate the method call(s) if that keyword is on the property. I strongly agree that Swift should have/keep a possibility to

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

I have to agree with Frederick that the two-backticks example looks horrible ;-). I guess the # way worjs better in that case. I’m not entirely sure about his second remark: if we require that references to functions without arguments are written without parenthesis, don’t we then have some inc

Re: [swift-evolution] Proposal: Expose getter/setters in the same way as regular methods

> On Dec 13, 2015, at 6:49 PM, Marc Knaup via swift-evolution > wrote: > > Also it's unlikely that all mutable properties will support observation > automatically. That would require the optimizer to keep using dynamic > dispatch for all of them which will hurt performance. Not really. All th

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

Given that someView.insertSubview(_:at:) can be correctly parsed, I would strongly lean towards the no-backtick alternative mentioned at the end. I feel as though the backticks end up looking very cluttered (particularly when you get into the double-nested backticks), and it seems cleaner to be

[swift-evolution] [Idea] Add an (Index, Element) sequence to CollectionType

-- Introduction There should be a property on CollectionType that returns a sequence of (Index, Element) tuples. Currently enumerate() is often used instead, but it is not well suited to the task and can lead to bugs. -- Motivation Using enumerate() instead of an (Index, Element) sequence has

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

This is a neat idea. Here are some of my thoughts after initial readthrough: - For symmetry with Obj-C code, how about using "@selector", such as @selector(UIView.`insertSubview(_:at:)`) ? - Or, why bother with a new expression? Could the compiler just do this automatically when it encounters an