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 adapted

[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. > > - Do

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 addi

[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 th

Re: [swift-evolution] [SR-933] Rename flatten to flattened

By “the big three”, are you referring to only the naming of map, filter, and reduce? I would also like to see a formal proposal along these lines, and possibly more. I also feel that the `inPlace` suffix was very clear (most important) and very much liked that it made the immutable version t

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

> • The "allValues" behavior should be provided by conformance to some > protocol, named ValueEnumerable or ValuesEnumerable or similar. > • The compiler should derive an allValues implementation for "simple" > enums (those without associated values). Agreed on my part. (I favor "Values

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 valid only in context of a particular collection i

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 > version I proposed

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, so it can go up for review so

Re: [swift-evolution] [SR-933] Rename flatten to flattened

Yes, I agree. I think in the guidelines should be a recommendation for mutating methods are preferred, when nonmutating are preferred, and when to have both. If performance is a key goal of Swift, so much that it influences API design, then some details should be part of the guidelines also. Pat

[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] [Accepted] SE-0048: Generic Type Aliases

I believe he means it has been merged to master, and will be in the next snapshot. Sent from my iPad 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 >> >> Th

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,

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, and simplifies the syntax (i

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 col

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 https://lists.swift.org/mailman/listinfo/swift-evolution

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] SE-0031 and Swift 2

My stuff is maintained by a single team. My problem is that Swift 2 is too immature to be usable on Linux, while Swift 3 is considered not production-grade on iOS/OSX. I have code that compiles for both platforms, and so it needs to support 2+3, 2 for Darwin and 3 for Linux. I would really li

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 coll

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

+1 for Scala's path dependent types. On Saturday, 16 April 2016, Thorsten Seitz via swift-evolution < swift-evolution@swift.org> wrote: > > > Am 15.04.2016 um 23:19 schrieb Dmitri Gribenko via swift-evolution < > swift-evolution@swift.org >: > > > > On Fri, Apr 15, 2016 at 1:30 PM, Stephan Tolksd

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

Re. OptionSetType If you wrote: enum Ex { case one, two, three } The compiler could do: - struct Ex : OptionSetType { - private let weight: Int - private init(_ weight: Int

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 wo

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, 2016. The >> proposal received

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

> On Apr 16, 2016, at 10:10 AM, Patrick Gili > wrote: > > 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 r

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

On Apr 15, 2016, at 5:04 PM, David Owens II wrote: > It’s weird to me that we can essentially erase the parameter names and > fallback to just the type signatures, but that can be a talk for another day. I agree that that is odd. In my opinion, it should be accepted to convert from a function

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

> On Apr 16, 2016, at 8:48 PM, Chris Lattner via swift-evolution > wrote: > > >> On Apr 16, 2016, at 10:10 AM, Patrick Gili >> wrote: >> >> As an alternative, could we require the parens on the return. For example: >> >> (Int) -> (Float) >> (String) -> () >> () -> () >> () -> (Double) >>

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 i

[swift-evolution] [Draft] Expanded min/max algorithms

Hello all, Attached is a draft of a proposal to expand the min and max sequence APIs to better handle collections and to support future sorted sequences/collections. The proposal is in a gist here and inlined below—would l

Re: [swift-evolution] [Draft] Expanded min/max algorithms

Hi Nate, I think this is a very useful addition! I also had a related proposal few days ago: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014665.html I feel like min/max extensio

Re: [swift-evolution] [Draft] Expanded min/max algorithms

On Sat, Apr 16, 2016 at 11:50 PM, Taras Zakharko via swift-evolution wrote: > Hi Nate, > > I think this is a very useful addition! I also had a related proposal few > days ago: > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014665.html > > I feel like min/max extension