Re: [swift-evolution] [Idea] Replace enumerate() with something more explicit

> With the above definition I would suggest a name change to entries, since a > Dictionary's keys are not necessarily numbers, hence enumerate is misleading. > > Nothing for Set since it isn't subscriptable. I think you're slightly confused. All Collections have an Index. Dictionary's Index

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

For the Arithmetic protocol how about changing it to: protocol Arithmetic { func + (lhs: Self, rhs: Self) -> Self mutating func += (rhs: Self) -> Self ... } That way naming issues are largely avoided, except for `mutating func negate()` which has no operator and

Re: [swift-evolution] [Accepted] SE-0048: Generic Type Aliases

> On Apr 16, 2016, at 1:12 AM, Nicola Salmoria via swift-evolution > wrote: > >> Proposal link: >> https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md >> >> The review of SE-0048 “Generic Type aliases” ran from March 24…29,

Re: [swift-evolution] [Idea] Replace enumerate() with something more explicit

I would suggest enumerate only for types that are subscriptable and that it be defined as their (index, value) set that iterates in the collection's indices order. IE: for index in collection.indices { let value = collection[index] ... } and for (index, value) in

Re: [swift-evolution] SE-0031 and Swift 2

FWIW the Python 3 migration found removal of old syntax and introduction of new syntax in the same release to be hugely problematic, and ended up back-porting a lot of Python 2 syntax features into 3.1 & 3.2 to ease the transition. The problem is that large codebases are very rarely controlled by

Re: [swift-evolution] [Idea] Replace enumerate() with something more explicit

I have to agree with those that simply want enumerate() fixed. There are many modern languages that have a similar function, such as Ruby. ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

> On Apr 16, 2016, at 12:10 PM, Patrick Gili via swift-evolution > wrote: > > As an alternative, could we require the parens on the return. For example: > > (Int) -> (Float) > (String) -> () > () -> () > () -> (Double) > > This looks cleaner, improves consistency,

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> > * What is your evaluation of the proposal? 1) I think eliminating intervals increases consistency and reduces confusion. 2) I really like the fact that this will make in-place index traversal methods public. It will reduce the amount of boilerplate for developers implementing new

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

As an alternative, could we require the parens on the return. For example: (Int) -> (Float) (String) -> () () -> () () -> (Double) This looks cleaner, improves consistency, and simplifies the syntax (i.e., no need to remember when parens are necessary). -Patrick > On Apr 15, 2016, at 1:38 PM,

[swift-evolution] [Pitch] Unifying init parameters with properties

Since we know the types of the properties, how about we replace the type in the signature with either an indication that the property should be automatically set, or better yet, the property which should be set: class Foo { let foo : String let bar : String let barCount

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> On Apr 15, 2016, at 9:00 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > This discussion is about a proposal for API to enumerate/count all possible > values of a type, particularly enums. The goal is to address potential issues > with an old proposal,

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

> Am 12.04.2016 um 01:01 schrieb Yuta Koshizawa : > > Hi. > > Decoding a JSON is just an example. As I replied to Thorsten, we can > think about various cases we want to unwrap multiple optionals at > once. > > This is another example (with the notation `|?` and the postfix

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> Am 15.04.2016 um 23:19 schrieb Dmitri Gribenko via swift-evolution > : > > On Fri, Apr 15, 2016 at 1:30 PM, Stephan Tolksdorf wrote: >> On 2016-04-12 Dmitri Gribenko via swift-evolution wrote: >>> >>> Not even to mention that >>> indices are

[swift-evolution] SE-0031 and Swift 2

Hello, I'm writing to complain about SE-0031 and Swift 2 compatibility. I understand (and agree with!) the change, but the migration between now and 2017 is annoying, hence my complaint. In snapshot swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a, we started erroring on the old syntax. That means

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

> Oh, a couple more things I just thought of: > > > public protocol Arithmetic: Equatable, IntegerLiteralConvertible { > If your goals include supporting complex numbers, how is > IntegerLiteralConvertible going to fit in there? > > > /// Initialize to zero > > init() > 0 is valuable as the

[swift-evolution] [Accepted] SE-0048: Generic Type Aliases

> Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md > > The review of SE-0048 “Generic Type aliases” ran from March 24…29, 2016. The > proposal received overwhelmingly positive feedback and has now been > implemented for Swift 3. > > -

Re: [swift-evolution] Open Source version of "The Swift Programming Language"

Yes, switching easily between language version outside of Github would definitely be sweet. The docs could even be organized as one or multiple playgrounds with pages. Allowing to see the results live and play with it. The learning by playing with it strategy of playground seem definitely