Re: [swift-evolution] sortBy, minElementBy and maxElementBy methods

Why add all those algorithms when you can write this func byComparing(getComparisonKey: (T)->U) -> (T, T) -> Bool { return { getComparisonKey($0) < getComparisonKey($1) } } peoples.sort(byComparing { $0.name }) ? -Dave > On Dec 30, 2015, at 10:38 PM, Susan Cheng via swift-evolution > wrote

Re: [swift-evolution] Remove forEach?

-Dave > On Dec 30, 2015, at 8:48 PM, Kevin Ballard via swift-evolution > wrote: > > Swift didn't use to have forEach(). It was added fairly late, and I suspect > (though I don't actually know) that it was done so to appease people who kept > abusing map() for the same function, as well as th

Re: [swift-evolution] sortBy, minElementBy and maxElementBy methods

+1, although I wonder if the method names should be distinct (such as minElementBy, sortBy, etc.) On Wed, Dec 30, 2015 at 10:38 PM, Susan Cheng via swift-evolution < swift-evolution@swift.org> wrote: > > Consider the follows: > > > struct Person { > > > > var name: String > > var age: Int

[swift-evolution] missing proposal about missing @noescape of 'SequenceType.flatMap'

Hi, I found the thread about missing attribute @noescape of 'SequenceType.flatMap' but it doesn't have a proposal in swift-evolution: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001025.html Susan ___ swift-evolution mailing li

[swift-evolution] sortBy, minElementBy and maxElementBy methods

Consider the follows: struct Person { var name: String var age: Int } let peoples = [Person(name: "Hawk", age: 24), Person(name: "Andrew", age: 23 )] let youngest = peoples.minElement { $0.age < $1.age } print(youngest?.name) it's silly that we always have to write the code l

Re: [swift-evolution] [Proposal] Protocols on Steroids

As Félix said this is a lot of stuff to cram into one proposal, so much so that I admit I haven't even read it. But skimming it very briefly I found the two following suggestions: > 1. Allow covariant generic argument types with a runtime check that > it is of the correct type ... > 1. Arr

Re: [swift-evolution] Remove forEach?

Swift didn't use to have forEach(). It was added fairly late, and I suspect (though I don't actually know) that it was done so to appease people who kept abusing map() for the same function, as well as the die- hard everything-must-be-functional crowd. Personally, I'd rather we didn't have it beca

[swift-evolution] Proposal: Allow @available(*, unavailable) methods to block resolving to an inherited protocol method

Right now, providing a method marked with @available(*, unavailable) doesn't actually prevent anyone from calling that method if the type in question inherits the same method from any protocol. Instead the unavailable method is ignored. This is in contrast with overriding a method from your supe

Re: [swift-evolution] About the PermutationGenerator

We have plenty of examples of GeneratorTypes that also conform to SequenceType. There's no harm in it, and it saves having to declare a separate type that consists solely of a generate() method that returns the generator. In fact, the stdlib automatically derives the generate() method for any Gener

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 29, 2015, at 5:44 PM, Dave Abrahams via swift-evolution > wrote: > > >> On Dec 29, 2015, at 12:06 PM, Kevin Ballard via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I briefly skimmed your proposal, so I apologize if you already addressed >> this, but it occurs

Re: [swift-evolution] Closure Syntax

> For clarity's sake, there's really two syntactic issues that I think would be > good to address. The first, which I think is the far bigger problem, which is > that right now a list of params with closures is very hard to read. For > example, this requires mental effort to decode whether this

Re: [swift-evolution] Keeping unused values around until containing scope exits?

> On Dec 30, 2015, at 5:38 PM, Kevin Ballard via swift-evolution > wrote: > > I strongly recommend either making the context get explicitly used in the > subsequent animations (e.g. `context.animation(...)` instead of just > `animation(...)`) or giving it an explicit scope (e.g. > `withAnima

[swift-evolution] About the PermutationGenerator

PermutationGenerator confuses me that it's confirm to both of SequenceType and GeneratorType. Should it replace by PermutationSequence and PermutationGenerator? Also, we should have a PermutationCollection because we can: public struct PermutationCollection : CollectionType { public type

Re: [swift-evolution] Proposal: Add SequenceType.first

+1. I doubt anyone would really complain, just had to point it out. > On Dec 30, 2015, at 5:00 PM, Kevin Ballard wrote: > > On Wed, Dec 30, 2015, at 04:39 PM, Daniel Duan wrote: >> Here it is >> https://github.com/apple/swift/blob/master/stdlib/public/core/CollectionAlgorithms.swift.gyb#L26 >>

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

Good point. Not sure if that's replaceable via a protocol or if that Api is just not suited for swift. There is a proposal somewhere to be able to reference swift methods via back ticks a sort of selector for swift so maybe in this case we would use that. Sent from my iPhone > On 30 Dec 2015,

Re: [swift-evolution] Proposal: Add SequenceType.first

On Wed, Dec 30, 2015, at 04:39 PM, Daniel Duan wrote: > Here it is  > https://github.com/apple/swift/blob/master/stdlib/public/core/CollectionAlgorithms.swift.gyb#L26 > >> On Dec 30, 2015, at 4:27 PM, Kevin Ballard wrote: >> >> We already don't have a .last on CollectionType and nobody's been >> c

Re: [swift-evolution] Remove forEach?

I don’t see the benefit of taking a simple declarative expression (map, flatMap, filter) and turning it into a complicated imperative/iterative loop. You already have the ability to iterate through a set and do whatever you want to do with with whatever logic you want to use using. I would hav

Re: [swift-evolution] Proposal: Add SequenceType.first

Here it is https://github.com/apple/swift/blob/master/stdlib/public/core/CollectionAlgorithms.swift.gyb#L26 > On Dec 30, 2015, at 4:27 PM, Kevin Ballard wrote: > > We already don't have a .last

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

+1 Sent from my iPad > On Dec 30, 2015, at 6:56 PM, Matthew Johnson wrote: > > >> On Dec 30, 2015, at 11:33 AM, Patrick Gili >> wrote: >> >> Just finished reading your write-up. It sounds similar to the Forwardable >> module supported by the Ruby standard library >> (http://ruby-doc.org/

Re: [swift-evolution] Keeping unused values around until containing scope exits?

I strongly recommend either making the context get explicitly used in the subsequent animations (e.g. `context.animation(...)` instead of just `animation(...)`) or giving it an explicit scope (e.g. `withAnimationContext(speed: 1.0, bounciness: 1.0) { ... }`). Having the presence of a stack valu

Re: [swift-evolution] Proposal: Add function SequenceType.find()

Good thought, but I doubt such a method would pull its own weight. -Kevin Ballard On Wed, Dec 30, 2015, at 04:24 PM, Nevin Brackett-Rozinsky wrote: > Is it worth considering a version that returns a tuple of (index, > element) ? > > Nevin > > > On Tue, Dec 29, 2015 at 9:40 PM, Keith Smiley via sw

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

If we need some way to say "this local variable should extend to the end of the scope", the most obvious (to me) way to do that is to introduce an attribute that you can add to the variable declaration. This would be similar to Obj-C's __attribute__((objc_precise_lifetime)), although not quite as w

Re: [swift-evolution] Proposal: Add SequenceType.first

We already don't have a .last on CollectionType and nobody's been complaining about that. Besides, sequences don't necessarily even terminate. -Kevin Ballard On Wed, Dec 30, 2015, at 04:01 PM, Daniel Duan wrote: > Users who don’t get the single-pass nature of SequenceType may expect > a .last as

Re: [swift-evolution] Proposal: Add function SequenceType.find()

Is it worth considering a version that returns a tuple of (index, element) ? Nevin On Tue, Dec 29, 2015 at 9:40 PM, Keith Smiley via swift-evolution < swift-evolution@swift.org> wrote: > +1. We've added an extension for this and find it very useful. > On Tue, Dec 29, 2015 at 18:38 Kevin Ballard

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

> On Dec 30, 2015, at 4:23 PM, Matthew Johnson via swift-evolution > wrote: > > >> On Dec 30, 2015, at 5:19 PM, Kevin Ballard via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Wed, Dec 30, 2015, at 03:12 PM, Kevin Wooten via swift-evolution wrote: > > Anothe

Re: [swift-evolution] Proposal: Add SequenceType.first

Users who don’t get the single-pass nature of SequenceType may expect a .last as well. > On Dec 30, 2015, at 3:57 PM, Kevin Ballard via swift-evolution > wrote: > > It's sometimes useful to get the first element of a sequence. To that end I'd > like to propose > > extension SequenceType { >

[swift-evolution] Proposal: Add SequenceType.first

It's sometimes useful to get the first element of a sequence. To that end I'd like to propose extension SequenceType { /// Returns the first element of `self`, or `nil` if `self` is empty. /// - Complexity: O(1) var first: Self.Generator.Element? { var gen = generate() return gen.next() } }

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 30, 2015, at 11:33 AM, Patrick Gili > wrote: > > Just finished reading your write-up. It sounds similar to the Forwardable > module supported by the Ruby standard library > (http://ruby-doc.org/stdlib-2.0.0/libdoc/forwardable/rdoc/Forwardable.html). > Is this the case? It works som

Re: [swift-evolution] [Proposal] Protocols on Steroids

Please split this in smaller pieces. Nobody will want to discuss all of it at once. Félix > Le 30 déc. 2015 à 17:50:44, Howard Lovatt via swift-evolution > a écrit : > > Proposal: Protocols on Steroids > === > > Change the way protocols and generics work, in particular: >

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

> On Dec 30, 2015, at 5:19 PM, Kevin Ballard via swift-evolution > wrote: > > On Wed, Dec 30, 2015, at 03:12 PM, Kevin Wooten via swift-evolution wrote: Another possibility I've thought of is defining `defer { val }` to guarantee that val remains alive until the defer fires on

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

On Wed, Dec 30, 2015, at 03:12 PM, Kevin Wooten via swift-evolution wrote: >>> >>> Another possibility I've thought of is defining `defer { val }` to >>> guarantee that val remains alive until the defer fires on scope >>> exit. That might let us leave `defer` as the one "guarantee >>> something hap

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

On Wed, Dec 30, 2015, at 02:27 PM, plx via swift-evolution wrote: > >> On that note, core language team, anyone know offhand why >> SequenceType has a bunch of extension methods that aren't part of the >> protocol? For example, contains(_ predicate:). The only real reason I >> can think of is to sh

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

>> >> Another possibility I've thought of is defining `defer { val }` to guarantee >> that val remains alive until the defer fires on scope exit. That might let >> us leave `defer` as the one "guarantee something happens exactly at scope >> exit" language construct. What about this… defer let

[swift-evolution] [Proposal] Protocols on Steroids

Proposal: Protocols on Steroids === Change the way protocols and generics work, in particular: Generic protocol with type parameters inside `<>`, like classes and structs Allow covariant return types including for generic types Allow covariant generic argument types with a runt

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

Sent from my iPad > On Dec 30, 2015, at 3:33 PM, Joe Groff via swift-evolution > wrote: > > >> On Dec 30, 2015, at 1:27 PM, Kevin Ballard wrote: >> >> On Wed, Dec 30, 2015, at 09:53 AM, Joe Groff wrote: >>> On Dec 29, 2015, at 8:55 PM, Kevin Ballard via swift-evolution wrote:

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

> On Dec 30, 2015, at 3:39 PM, Kevin Ballard via swift-evolution > wrote: > > Refactoring like that can always be done later; introducing infinite > sequences now shouldn't make it any harder to refactor the protocols. If > anything, it will provide more practical experience with how infinite

Re: [swift-evolution] Remove forEach?

In most programming languages, map does not have any side-effect. This is may be the reason forEach was added. > On Dec 30, 2015, at 2:10 PM, Howard Lovatt via swift-evolution > wrote: > > You could replace `forEach` with a supped up `map` that also allowed `break` > and `continue`. The follo

Re: [swift-evolution] Remove forEach?

You could replace `forEach` with a supped up `map` that also allowed `break` and `continue`. The following library function gives `continue` and `break` and also combines `repeat`, `times`, `forEach`, `filter`, `flatMap`, and `map` into one: public final class MapController { var results =

Re: [swift-evolution] Proposal: Add function SequenceType.find()

On Wed, Dec 30, 2015, at 02:13 AM, James Campbell wrote: > We should add the full collection of ruby methods  > http://matthewcarriere.com/06/23/using-select-reject-collect-inject-and-detect/ We already have them. Well, almost: select - this is filter reject - this is just filter with a negated p

Re: [swift-evolution] Proposal: Add function SequenceType.find()

On Wed, Dec 30, 2015, at 07:33 AM, Donnacha Oisín Kidney via swift-evolution wrote: > +1 on this. > > I see a lot of code like this: > > sequence.filter(predicate).first > > Which is of course is inefficient. However, the go-to optimisation: > > sequence.lazy.filter(predicate).first > > Is not nec

Re: [swift-evolution] Beef up Imports

Clang modules have always supported submodules, and in fact when you import an Obj-C framework (that doesn't use a completely custom module.modulemap), each header from the framework is automatically a submodule (and importing the framework automatically imports all the submodules). All Swift is m

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

There's no rule-of-five if you explicitly define (as Rust does) that you cannot override assign/copy/move. In Rust, a copyable struct is always memcpy()'d. Anything that's not memcpy'd but still wants to support explicit copying conforms to the Clone trait, and the compiler lets such structs automa

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

On Wed, Dec 30, 2015, at 01:33 PM, Joe Groff wrote: > Another possibility I've thought of is defining `defer { val }` to > guarantee that val remains alive until the defer fires on scope exit. > That might let us leave `defer` as the one "guarantee something > happens exactly at scope exit" languag

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

IMO the biggest problem with this approach is that it leads to a much more complicated programming model. The vast majority of structs should be copiable, which gets you into rule-of-five programming (where nearly every nontrivial struct needs to implement init, deinit, copy, assign, move) pre

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

Refactoring like that can always be done later; introducing infinite sequences now shouldn't make it any harder to refactor the protocols. If anything, it will provide more practical experience with how infinite sequences interact with the current protocol hierarchy that would help guide the design

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

> On Dec 30, 2015, at 1:27 PM, Kevin Ballard wrote: > > On Wed, Dec 30, 2015, at 09:53 AM, Joe Groff wrote: >> >>> On Dec 29, 2015, at 8:55 PM, Kevin Ballard via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> An alternative solution is to do what Rust and C++ do, whic

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

On Wed, Dec 30, 2015, at 09:53 AM, Joe Groff wrote: > >> On Dec 29, 2015, at 8:55 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote: >> >> An alternative solution is to do what Rust and C++ do, which is to >> use RAII. Which is to say, instead of introducing a new language >> const

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

A uniquely-owned class that guarantees stack allocation is pretty much the same thing as a move-only value type, isn't it? The only real difference I can think of is classes allow for subclassing. -Kevin On Wed, Dec 30, 2015, at 01:18 PM, Chris Lattner wrote: > >> On Dec 30, 2015, at 10:31 AM, Jo

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

> On Dec 30, 2015, at 10:31 AM, Joe Groff wrote: > >> >> On Dec 30, 2015, at 10:26 AM, Chris Lattner > > wrote: >> >>> >>> On Dec 30, 2015, at 9:53 AM, Joe Groff via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> On Dec 29, 2015, at 8:

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

> I'm not as familiar with OS X but why is it vital there ? > Do you have an example of use ? If those questions are for me ;-): Afair (have to do iOS most of the time now), "Undo" is the most prominent example. You don't link those menu entries to a concrete object, but rather say "bind this

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

I like this proposal overall and the proposed syntax in particular; I think it addresses a real issue in a straightforward, predictable way. As an aside — and FWIW — one thing I was at some point going to propose was a shorthand syntax for specifying trivial “argument-ordering-adjustment” closur

Re: [swift-evolution] Closure Syntax

Reasonable. That all makes sense. For clarity's sake, there's really two syntactic issues that I think would be good to address. The first, which I think is the far bigger problem, which is that right now a list of params with closures is very hard to read. For example, this requires mental effort

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

NSControl and subclasses have an action property and a target property but no method to set both at once (in opposition to, say, NSTimer, which has methods that accept a target and a selector at the same time). Félix > Le 30 déc. 2015 à 11:52:41, James Campbell a écrit : > > Do you have an ex

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 30, 2015, at 10:27 AM, Matthew Johnson wrote: > > >> On Dec 30, 2015, at 10:06 AM, plx via swift-evolution >> wrote: >> >> Thanks for writing this up. > > Thanks for responding with comments. > >> >> Some quick points. >> >> Firstly, I think it is best if the `init(_ forwardeeRe

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

+1 to Joe’s comment. > On Dec 30, 2015, at 10:31 AM, Joe Groff via swift-evolution > wrote: > > >> On Dec 30, 2015, at 10:26 AM, Chris Lattner > > wrote: >> >>> >>> On Dec 30, 2015, at 9:53 AM, Joe Groff via swift-evolution >>> mailto:swift-evolution@swift.org>> w

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 29, 2015, at 5:25 PM, Charles Srstka wrote: > > Strong +1 on this proposal. I use Objective-C’s forwarding mechanisms quite > often in my custom view code, in order to separate the code managing the > outer view, the layout of subviews within the view, and business logic into > separ

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

> On Dec 29, 2015, at 6:38 PM, Dave Abrahams wrote: > > >> On Dec 29, 2015, at 3:39 PM, plx via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Dec 29, 2015, at 1:17 PM, Kevin Ballard via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> On Tu

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

> On Dec 30, 2015, at 10:26 AM, Chris Lattner wrote: > >> >> On Dec 30, 2015, at 9:53 AM, Joe Groff via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Dec 29, 2015, at 8:55 PM, Kevin Ballard via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>

Re: [swift-evolution] Keeping unused values around until containing scope exits?

> On Dec 30, 2015, at 10:10 AM, Ollie Wagner via swift-evolution > wrote: > > I'm using the lifetime of a variable to push and pop a context in an > animation system that I'm writing. I'm interested in using a pattern like: > > func doAnimations() { > AnimationContext(speed: 1.0, bouncine

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

> On Dec 30, 2015, at 9:53 AM, Joe Groff via swift-evolution > wrote: > > >> On Dec 29, 2015, at 8:55 PM, Kevin Ballard via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> An alternative solution is to do what Rust and C++ do, which is to use RAII. >> Which is to say, ins

[swift-evolution] Keeping unused values around until containing scope exits?

I'm using the lifetime of a variable to push and pop a context in an animation system that I'm writing. I'm interested in using a pattern like: func doAnimations() { AnimationContext(speed: 1.0, bounciness: 1.0) // do some animations using these options } But today, the value returned by

Re: [swift-evolution] Custom summary for Mirrors?

I believe 'summary' is obsolete, and you're supposed to use Custom[Debug]StringConvertible to customize your type's reporting now. -Joe > On Dec 29, 2015, at 10:38 PM, Austin Zheng via swift-evolution > wrote: > > Hi all, > > I'd like to gauge reaction for a proposal I was considering: addin

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

> On Dec 29, 2015, at 8:55 PM, Kevin Ballard via swift-evolution > wrote: > > An alternative solution is to do what Rust and C++ do, which is to use RAII. > Which is to say, instead of introducing a new language construct that's > explicitly tied to a scope, you just use a struct to represent

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 30, 2015, at 10:06 AM, plx via swift-evolution > wrote: > > Thanks for writing this up. > > Some quick points. > > Firstly, I think it is best if the `init(_ forwardeeReturnValue: > Forwardee)`-style initializer be replaced by something with a > distinctly-named argument, e.g. `ini

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

Just finished reading your write-up. It sounds similar to the Forwardable module supported by the Ruby standard library (http://ruby-doc.org/stdlib-2.0.0/libdoc/forwardable/rdoc/Forwardable.html). Is this the case? Cheers, -Patrick Gili ___ swift-evol

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

Based on the discussion here, I'm withdrawing this proposal. I created it because of a section in the Error Handling Rationale and Proposal document ( https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst) about `using`: Swift should consider providing a using statement which

Re: [swift-evolution] Proposal: Add function SequenceType.find()

But overloading the first method with a closure is a clever ide s Sent from my iPhone > On 30 Dec 2015, at 15:33, Donnacha Oisín Kidney > wrote: > > +1 on this. > > I see a lot of code like this: > > sequence.filter(predicate).first > > Which is of course is inefficient. However, the go-to

Re: [swift-evolution] Proposal: Add function SequenceType.find()

Ruby calls that method detect. As in detect and return the item that matches this condition Sent from my iPhone > On 30 Dec 2015, at 15:33, Donnacha Oisín Kidney > wrote: > > +1 on this. > > I see a lot of code like this: > > sequence.filter(predicate).first > > Which is of course is ineff

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

I'm not as familiar with OS X but why is it vital there ? Also for Linux this api is unneeded since there is no access to objective c Sent from my iPhone > On 30 Dec 2015, at 16:06, Tino Heth <2...@gmx.de> wrote: > > >> Ah good point, in swift you can return a function as a closure (see that

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

Do you have an example of use ? Sent from my iPhone > On 30 Dec 2015, at 15:48, Félix Cloutier wrote: > > How do you import the API to Swift when the target and action properties are > separate? > > Félix > >> Le 30 déc. 2015 à 09:36:24, James Campbell via swift-evolution >> a écrit : >>

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

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

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 30, 2015, at 10:06 AM, plx via swift-evolution > wrote: > > Thanks for writing this up. Thanks for responding with comments. > > Some quick points. > > Firstly, I think it is best if the `init(_ forwardeeReturnValue: > Forwardee)`-style initializer be replaced by something with a

Re: [swift-evolution] Beef up Imports

+1 -Thorsten > Am 29.12.2015 um 01:47 schrieb Kevin Ballard via swift-evolution > : > > I like the idea here, but I'm not sold on the syntax. I also do explicitly > want an `import qualified`. And with qualified imports, I question whether we > really need to support renaming in the import sy

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

> Ah good point, in swift you can return a function as a closure (see that > link) so interface builder could bind an action. afaics this cannot work when myClass is nil: The transponder chain might be invisible on iOS, but for OS X, it is vital. Tino

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

Thanks for writing this up. Some quick points. Firstly, I think it is best if the `init(_ forwardeeReturnValue: Forwardee)`-style initializer be replaced by something with a distinctly-named argument, e.g. `init(forwardeeReturnValue value: Forwardee)`. For use with actual wrapper types the “i

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 30, 2015, at 5:47 AM, Tino Heth <2...@gmx.de> wrote: > > Have you looked at how this is handled in Kotlin? I hadn’t, but I did look at a paper on a forwarding preprocessor for Java that was called Jaime. The way forwarding is declared is very similar to Kotlin so it may have been a p

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

How do you import the API to Swift when the target and action properties are separate? Félix > Le 30 déc. 2015 à 09:36:24, James Campbell via swift-evolution > a écrit : > > Ah good point, in swift you can return a function as a closure (see that > link) so interface builder could bind an a

Re: [swift-evolution] Proposal: Add function SequenceType.find()

+1 on this. I see a lot of code like this: sequence.filter(predicate).first Which is of course is inefficient. However, the go-to optimisation: sequence.lazy.filter(predicate).first Is not necessarily better, and has some strange behaviour: let array = [1, 2, 3, 4, 5, 6] func noisyPredicate(n

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

Sent from my iPad > On Dec 30, 2015, at 12:52 AM, Thorsten Seitz wrote: > > Thanks for proposing this, Matthew! > > Am 30. Dezember 2015 um 03:05 schrieb Matthew Johnson via swift-evolution > : > > * Why the method-based conversion syntax for return values, rather than > something

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

Sent from my iPad > On Dec 29, 2015, at 10:55 PM, Kevin Ballard via swift-evolution > wrote: > > An alternative solution is to do what Rust and C++ do, which is to use RAII. > Which is to say, instead of introducing a new language construct that's > explicitly tied to a scope, you just use a

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

Ah good point, in swift you can return a function as a closure (see that link) so interface builder could bind an action. Like so : addAction(myClass.actionFunction) Instead of what it does now: addAction(myClass, action:"actionFunction:") Sent from my iPhone > On 30 Dec 2015, at 14:14, Jean

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

> Le 30 déc. 2015 à 12:21, James Campbell via swift-evolution > a écrit : > > These are very good points. >> >> Actually, it comes in as addAction(action: Selector), not String. You can >> initialize a Selector from a string literal. > > Yes :) should have looked it up before I tried to rem

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

Totally agree with that proposal, I think we should do that as a temporary step but also look to reduce the need for selectors in favour of closures. As I think a lot of the behaviour of selectors Could be replicated by existing swift features. Sent from my iPhone > On 30 Dec 2015, at 12:54,

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

For reference, I'll just point out that there was an interesting discussion about this topic at the beginning of December. https://lists.swift.org/pipermail/swift-evolution/2015-December/000233.html -- Michel Fortin https://michelf.ca ___ swift-evolut

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

In the performSelector and nsinvocation case. Are people using it for existing functions in which case type safety is important. But if it's for dynamic calling of a method ( for example for a visitor pattern) then I don't think there is any safety that can easily be applied via a special synt

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

Have you looked at how this is handled in Kotlin? Imho Jetbrains solution is quite elegant — especially as it also has a natural answer to another problem ("flexible memberwise initialization"; the whole init process is only a short chapter in the docs). Of course, their approach is different, bu

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

These are very good points. > > Actually, it comes in as addAction(action: Selector), not String. You can > initialize a Selector from a string literal. Yes :) should have looked it up before I tried to remember it off the top of my head. > > Three questions about your proposal: > > 1. Wher

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

It is an appealing idea on first sight, but it makes the language more complex, and I don't think scoped resources are versatile enough to back justify their inclusion. The defer feature which is already mentioned in the proposal is very similar — and I expect that will not only be the case for

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

> What if selectors arguments could be imported into swift to take a closure > instead ? > > This would fit into the proposal to rewrite the imported objective c Apis > > So > > - addAction:(Selector)action > > Becomes > > addAction(action:(AnyObject)->Void) > > Instead of > > addAction(

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

+1 for that. Closures are much more swift-y than selectors (and honestly, even in Objective-C, selectors are a pain to use). This would definitely be nice, although I'm not quite sure if it's possible with reasonable effort. Selectors are very, very different beasts. On Wed, Dec 30, 2015 at 10:56

Re: [swift-evolution] Proposal: Add function SequenceType.find()

We should add the full collection of ruby methods http://matthewcarriere.com/06/23/using-select-reject-collect-inject-and-detect/ Sent from my iPhone > On 30 Dec 2015, at 02:40, Keith Smiley via swift-evolution > wrote: > > +1. We've added an extension for this and find it very useful. >> O

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

What if selectors arguments could be imported into swift to take a closure instead ? This would fit into the proposal to rewrite the imported objective c Apis So - addAction:(Selector)action Becomes addAction(action:(AnyObject)->Void) Instead of addAction(action:String) Like it does no