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

> I would suggest that ValuesEnumerable should expose allValues and the type of > allValues should be a custom OptionSet implementation that iterates in > declaration order. That would make sense if OptionSet were a generic type which took any integer-ish RawRepresentable (which I've advocated

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

> I would suggest an alternative; changing Range so that it is indexed like an > array, an Int from 0 to count - 1. Such that aRange[index] is defined as > start + index * stride. This will eliminate the problems with enumerate. A > Range's generic type would be constrained to be an Arithmetic

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

Doesn't really seem worth the trouble to me. It is fine as it is. Other languages like Java and Scala allow this short hand and Swift allows it in closures. Not that I am that fussed since the brackets are no big deal. On Saturday, 16 April 2016, John McCall via swift-evolution <

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

I would suggest an alternative; changing Range so that it is indexed like an array, an Int from 0 to count - 1. Such that aRange[index] is defined as start + index * stride. This will eliminate the problems with enumerate. A Range's generic type would be constrained to be an Arithmetic type, see

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

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 soon. Core Team / Standard Library Team feedback would be particularly welcome here, because

Re: [swift-evolution] [Discussion] Dictionary Key as Index

>> * Given just an `Index`, you need to be able to calculate the next `Index`, >> and check if it lies before the `endIndex`. The complexity of this is hidden >> in your example because you're relying on a traditional `DictionaryIndex` to >> perform these tasks. Thus, the `Index` type in your

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 15, 2016, at 4:03 PM, Douglas Gregor wrote: > > Both Joe’s suggestion and my proposal need hackery to do the right thing for > Objective-C interoperability, and both are feasible. I feel like my proposal > is more honest about the hackery going on :) Since there's

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

I support a fixed version. I don't think that's mutually exclusive with removing enumerate. This thread seems to be a result of a misused API, so I think it's necessary to make it obvious when that API changes. I think we'd want a period of deprecation with both enumerate() and a new (hopefully

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

I think this is a great idea. I'm not sure how big a task it is to open source the current system. Hopefully it's easy for Apple to extract the content, convert it to markdown (if needed), and allow it to be updated from a git repo. It would be great if the website allowed you to browse tagged

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

> On Apr 15, 2016, at 8:09 PM, Andrew Bennett via swift-evolution > wrote: > > I'm in support of a method of getting a sequence of (Index,Value) pairs (as > you know from the other thread). I think I'm leaning toward option three if > it's equivalent to

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

I'm in support of a method of getting a sequence of (Index,Value) pairs (as you know from the other thread). I think I'm leaning toward option three if it's equivalent to `zip(self.indices, self)`, ideally as a concise property like keys/values on a Dictionary. I've been using zip in production.

Re: [swift-evolution] [Proposal] mapValues

Thanks Brent for your in-depth response - I've responded in another thread so we don't pollute this one (sorry Jonathan): http://thread.gmane.org/gmane.comp.lang.swift.evolution/14665 I think mapValues is great, and really needed in Swift. I'm a definite +1 on a version of map that only maps the

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

> On Apr 15, 2016, at 11:15, Erica Sadun via swift-evolution > wrote: > > Finally, it's Swift. Isn't it time for π and 휏 as well as Pi and Tau? Yes! I was waiting to bring up tau. ___ swift-evolution mailing list

[swift-evolution] [Discussion] Dictionary Key as Index

I've moved this discussion over from "[swift-evolution] [Proposal] mapValues" which discusses mapValues, like map but it preserves keys and transforms values, returning a Dictionary. I'm in favour mapValues, but I feel like it should be the default behaviour of map for a Dictionary. Being the

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

> On Apr 15, 2016, at 2:47 PM, Joe Groff wrote: >> On Apr 15, 2016, at 11:43 AM, John McCall wrote: >>> On Apr 15, 2016, at 10:41 AM, Joe Groff wrote: On Apr 15, 2016, at 8:29 AM, John McCall via swift-evolution

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> That’s the other part of my argument: if it is true that Swift code only > needs to conform to ObjC protocols with optional requirements, but Swift code > does not need to invoke optional requirements of ObjC protocols except very > rarely, then it’s okay for calling-an-optional-requirement

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

> On Apr 15, 2016, at 1:07 PM, Chris Lattner wrote: > > >> On Apr 15, 2016, at 11:27 AM, David Owens II > > wrote: >> >> Hmm... I don't think this is clearer: >> >> let fn: (Int) -> (Int) -> Int >> >> I think it's much less

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 additive

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 15, 2016, at 4:27 PM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Apr 15, 2016, at 6:17 PM, Douglas Gregor > wrote: > >> >>> On Apr 15, 2016, at 4:15 PM, Matthew Johnson

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Sent from my iPad > On Apr 15, 2016, at 6:17 PM, Douglas Gregor wrote: > > >> On Apr 15, 2016, at 4:15 PM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >>> On Apr 15, 2016, at 6:03 PM, Douglas Gregor wrote: >>>

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

On 2016-04-15 Dmitri Gribenko wrote: On Fri, Apr 15, 2016 at 1:30 PM, Stephan Tolksdorf wrote: The proposal requires Index values to be Comparable. Does that mean that indices from different collection instances should be comparable i.e. have a strict total order? No,

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 15, 2016, at 4:15 PM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Apr 15, 2016, at 6:03 PM, Douglas Gregor > wrote: > >> >>> On Apr 15, 2016, at 3:55 PM, Matthew Johnson

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Sent from my iPad > On Apr 15, 2016, at 6:03 PM, Douglas Gregor wrote: > > >>> On Apr 15, 2016, at 3:55 PM, Matthew Johnson wrote: >>> >>> On Apr 13, 2016, at 11:42 AM, Douglas Gregor wrote: On Apr 11,

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 15, 2016, at 3:55 PM, Matthew Johnson wrote: > > >> On Apr 13, 2016, at 11:42 AM, Douglas Gregor > > wrote: >> >>> >>> On Apr 11, 2016, at 10:30 AM, Matthew Johnson >>

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

Review of: https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md * What is your evaluation of the proposal? I think it is a big improvement over the current collections API. However I have a number of reservations, particularly: 1. The motivation of

Re: [swift-evolution] TreeLiteralConvertible

> Aren’t JSON arrays and objects actually the same thing? They’re both > essentially just ordered dictionaries, with objects mapping keys to > properties, functions etc., while arrays are just a dictionary where the keys > are consecutive integer (or should be, as long as you don’t mess with

Re: [swift-evolution] Feature proposal: Range operator with step

Brent Royal-Gordon via swift-evolution writes: > > > for i in p1.. > > > as syntactic sugar for and internally mapped to > > > > for i in (p1.. > > > Best of both worlds? > > Look. It is very, very unlikely that you will get people to add syntactic

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

A discussion in the "mapValues" thread reminded me of a longstanding issue I have with Swift. `enumerate()` is an attractive nuisance. (That is, it looks like the thing you want, but it's not actually the right one.) Most people use it because they want to enumerate over indices and elements

Re: [swift-evolution] [Proposal] mapValues

> This is a clarification on what I meant (I haven't had much time to test it, > but I think it's representative): > > https://gist.github.com/therealbnut/c223d90a34bb14448b65fc6cc0ec70ac There are a number of problems with this: * Given just an `Index`, you need to be able to calculate the

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

> So, `Void->Int` functions would work like this? > let foo = bar(()) // returns Int Yes. -- Brent Royal-Gordon Architechies ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

> On Apr 15, 2016, at 11:43 AM, John McCall wrote: > >> On Apr 15, 2016, at 10:41 AM, Joe Groff wrote: >>> On Apr 15, 2016, at 8:29 AM, John McCall via swift-evolution >>> wrote: >>> On Apr 14, 2016, at 10:50 PM, Chris

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

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 instance, >> so in this model you could validate an index against

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

So, `Void->Int` functions would work like this? let foo = bar(()) // returns Int > On Apr 15, 2016, at 3:23 PM, Brent Royal-Gordon via swift-evolution > wrote: > > What I think we *should* eliminate, however, is using `Void` to mean "no > arguments" in a closure

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

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 instance, so in this model you could validate an index against one collection and use it with another one. The proposal requires Index values to be

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

After hitting Send button, I remembered that "Enhanced floating-point protocols" proposal uses `add`, `subtract`, `multiply` and `divide` names for mutating versions. They should be non-mutating by default, as well as other purely mathematical terms. I don't know how it can be unobvious. - Anton

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

Thinking about it, `ed`/`ing` and even `form` prefix might not be that bad. It's more a matter of what should be "default" in a specific domain. In imperative domain, mutating version usually feels as the most natural one. Think `sort`. Everyone knows that sort must modify the array (usually

Re: [swift-evolution] [Accepted] SE-0063: SwiftPM System Module Search Paths

Oh yes, of course. My apologies, and thank you for the correction. Anders > On Apr 15, 2016, at 13.18, Jacob Bandes-Storch wrote: > > That link would be > https://github.com/apple/swift-evolution/blob/master/proposals/0063-swiftpm-system-module-search-paths.md > >

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

> Given all this, I think it makes sense to go for syntactic uniformity between > parameter list and function types, and just require parenthesis on the > argument list. The types above can be trivially written as: > > (Int) -> Float > (String) -> () > > Thoughts? While it's technically

Re: [swift-evolution] [Accepted] SE-0063: SwiftPM System Module Search Paths

That link would be https://github.com/apple/swift-evolution/blob/master/proposals/0063-swiftpm-system-module-search-paths.md On Fri, Apr 15, 2016 at 1:14 PM, Anders Bertelrud via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift Community, > > The review of SE-0063 "SwiftPM

[swift-evolution] [Accepted] SE-0063: SwiftPM System Module Search Paths

Hello Swift Community, The review of SE-0063 "SwiftPM System Module Search Paths" for the Swift Package Manager ran from Feb. 7th-13th, 2016. The proposal has been accepted. Feedback was light but positive, which was not surprising since there had been email discussions of this topic for some

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

> On Apr 15, 2016, at 11:27 AM, David Owens II wrote: > > Hmm... I don't think this is clearer: > > let fn: (Int) -> (Int) -> Int > > I think it's much less readable and really, the () are syntactically > redundant: the -> is really what distinguishes this as a function.

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

I don't see any advantage of requiring parenthesis. I think programmers should be allowed to write (Int) -> Int, and they should also be allowed to write Int -> Int. -Michael ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

I'm just concerned about the obviousness of it. If what we are doing is just grabbing the type, why couldn't it be: someClass.Type (like in the generic system) I'm open to Self, but I just want to make sure we exhaust all avenues that are more obvious at a glance: .Self.Type .ThisType

Re: [swift-evolution] TreeLiteralConvertible

> On 15 Apr 2016, at 19:54, Haravikk wrote: > > While the original post is an interesting way to define this structure, I > think a specialised type is required to really capture this usefully. Sure. I never meant it as a replacement. It was a response to someone’s

Re: [swift-evolution] TreeLiteralConvertible

> On 15 Apr 2016, at 16:48, John McCall via swift-evolution > wrote: > The JSONValue type needs to be able to embed both JSON arrays and JSON > objects, Aren’t JSON arrays and objects actually the same thing? They’re both essentially just ordered dictionaries,

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

> On Apr 15, 2016, at 10:41 AM, Joe Groff wrote: >> On Apr 15, 2016, at 8:29 AM, John McCall via swift-evolution >> wrote: >> >>> On Apr 14, 2016, at 10:50 PM, Chris Lattner wrote: >>> On Apr 14, 2016, at 10:40 PM, John McCall

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

Hmm... I don't think this is clearer: let fn: (Int) -> (Int) -> Int I think it's much less readable and really, the () are syntactically redundant: the -> is really what distinguishes this as a function. Also, this would look like a error now: let fn: (Int) -> () Did the user mean

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

> On Apr 15, 2016, at 12:22 PM, Stephen Canon wrote: > >> >> On Apr 15, 2016, at 11:14 AM, Erica Sadun > > wrote: >> That said, I use M_PI_4 a lot because it's really handy for sample code. I'm >> one of the >> outlier

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

On Apr 15, 2016, at 11:05 AM, Guillaume Lessard via swift-evolution wrote: > I don’t see why this is needed; there isn't an AdditivelyInvertible protocol That’s precisely SignedArithmetic, just under a different name. –

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

> On Apr 15, 2016, at 11:14 AM, Erica Sadun wrote: > > On Apr 15: 2016: at 11:56 AM: Joe Groff via swift-evolution > > wrote: >> >> >>> On Apr 15: 2016: at 8:20 AM: Stephen Canon via swift-evolution >>>

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

On Apr 15: 2016: at 11:56 AM: Joe Groff via swift-evolution > wrote: > > >> On Apr 15: 2016: at 8:20 AM: Stephen Canon via swift-evolution >> > wrote: >> >> “e” is a great

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

On Apr 15: 2016: at 11:56 AM: Joe Groff via swift-evolution wrote: > > >> On Apr 15: 2016: at 8:20 AM: Stephen Canon via swift-evolution >> wrote: >> >> “e” is a great bike-shedding example. While it would definitely allow a >> fluent

Re: [swift-evolution] TreeLiteralConvertible

> On 15 Apr 2016, at 08:24, Andrey Tarantsov wrote: >> On 14 Apr 2016, at 19:23, Andrey Tarantsov wrote: >> >> Can you please give us a few real-world examples… > > I can't think of any real use cases for the kind of literals you want, > though,

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

Hi Stephen > Hi Erica, thanks for the feedback. > >> On Apr 14, 2016, at 6:29 PM, Erica Sadun > > wrote: >> >> * I do use % for floating point but not as much as I first thought before I >> started searching through my code after reading

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

> On Apr 15, 2016, at 8:20 AM, Stephen Canon via swift-evolution > wrote: > > “e” is a great bike-shedding example. While it would definitely allow a > fluent style if you know what you’re looking at, I worry a little bit about > readability of `Float.e` or `.e`

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

On Apr 15, 2016, at 8:20 AM, Stephen Canon wrote: >> >> Incidentally, if you make pi and e be static members of the type, we should >> get a pretty fluent style, along the lines of: >> >> let x = someDouble * 2 * .pi >> >> I agree that there is a concern about deciding

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

> On Apr 15, 2016, at 8:29 AM, John McCall via swift-evolution > wrote: > >> On Apr 14, 2016, at 10:50 PM, Chris Lattner wrote: >> On Apr 14, 2016, at 10:40 PM, John McCall wrote: > To me, the unparenthesized style

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

On Apr 15, 2016, at 12:47 AM, Andrey Tarantsov wrote: > Chris, > >> Given all this, I think it makes sense to go for syntactic uniformity >> between parameter list and function types, and just require parenthesis on >> the argument list. The types above can be trivially

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

> On Apr 15, 2016, at 5:11 AM, David Hart wrote: > > If the original rationale is gone, shouldn’t we also get rid of the empty > tuple-type and replace it by a full-blown Void instead of Void being a > typealis for the empty tuple? This could be done, but it would make the

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

> On Apr 14, 2016, at 11:59 AM, Brandon Knope wrote: > > -1 from me. To me this is not *obvious* as to what "Self" it means. > > And it seems possible to run into this: > self.someClass.Self > > Just looks confusing to me. What's wrong with using "Type" or something more >

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

The floating-point API design looks great. However, I'm concerned about providing a generic Arithmetic protocol: > On Apr 14, 2016, at 4:55 PM, Stephen Canon via swift-evolution > wrote: > > A new protocol, Arithmetic, is introduced that provides the most basic >

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

> On Apr 15, 2016, at 9:52 AM, Stephan Tolksdorf via swift-evolution > wrote: > > but the documentation for Equatable and Comparable states that == and < must > implement an equivalence relation and a strict total order, which is > incompatible with the default

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

> On Apr 14, 2016, at 12:29 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 13 2016, Joe Groff wrote: > >> It's been pitched before, but I don't think we've had a dedicated >> thread to this idea. Erica has proposed

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

Hi Stephen, You write * FloatingPoint should conform to Equatable, and Comparable but the documentation for Equatable and Comparable states that == and < must implement an equivalence relation and a strict total order, which is incompatible with the default IEEE-754 implementation of

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

> On Apr 15, 2016, at 3:19 AM, Taras Zakharko wrote: > > True, that makes sense. I was simply trying to explore different > possibilities of how these things could be represented in the syntax. What > about #type(d) for static (declaration) type and type(v) for dynamic

Re: [swift-evolution] [Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters

http://apple.github.io/swift-internals/api-design-guidelines/ It's a matter of interpretation, but: "Prefer method and function names that make use sites form grammatical English phrases." Maybe I'm missing something, but I can't figure out how to read #selector(setter: Person.name). My

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

> On Apr 14, 2016, at 11:48 PM, Nicola Salmoria > wrote: > >> /// The quotient of `self` dividing by `rhs`. >> // Arithmetic provides a default implementation of this method in terms >> // of the mutating `divide` operation. >> @warn_unused_result >> func

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

> On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution > wrote: > > I've already expressed these concerns, but nobody noticed, apparently. Here > is it: > > I think current -ed/-ing convention is ugly. It breaks syntactic correctness, > experience from

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

I've already expressed these concerns, but nobody noticed, apparently. Here is it: I think current -ed/-ing convention is ugly. It breaks syntactic correctness, experience from other languages, mathematical notation and functional idioms. `InPlace` suffix was so far more correct in these terms.

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

> On Apr 15, 2016, at 7:23 AM, plx via swift-evolution > wrote: > > One is if there’s any ETA or similar for a glimpse at the “complete picture” > of Swift’s revised numeric protocols; these floating-point protocols look > really, really good, but this is also (I

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

I understand the reasoning, but I really like and often use the shorthand notation. I hope that it stays. On Fri, Apr 15, 2016 at 12:58 AM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > We currently accept function type syntax without parentheses, like: > > Int ->

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

> On Apr 14, 2016, at 10:47 PM, daveswee...@mac.com wrote: > > In general, I think this is fantastic. In particular, I *really* like the > notion that `BinaryFloatingPoint` conforms to `FloatingPoint`. I would do a > few things differently, though: >> On Apr 14, 2016, at 6:55 PM, Stephen Canon

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 15, 2016, at 1:29 AM, Milos Rankovic > wrote: >> On 15 Apr 2016, at 03:22, John McCall > > wrote: >> Your JSON literal example is already pretty well modeled by simply making a >> JSONValue type that

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

Hi, Not sure this request fit the swift evolution mailing list, but it would be great to have an open source (GitHub) version of the programming language guide (https://swift.org/documentation/#the-swift-programming-language) in order to suggest edit regarding validated evolution and/or edit

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

> On Apr 14, 2016, at 10:12 PM, Erica Sadun wrote: > > >> On Apr 14, 2016, at 10:36 PM, Stephen Canon > > wrote: >> >> Hi Erica, thanks for the feedback. >> >>> On Apr 14, 2016, at 6:29 PM, Erica Sadun

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

+1 great addition. Would suggest the naming could be more consistent, in particular: 1. Anything returning Self could be named xxxed. In the current proposal this naming convention is sometimes used, e.g. divided, and sometimes not, e.g. subtracting. Suggest all unified with the xxxed

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

> On Apr 14, 2016, at 10:50 PM, Chris Lattner wrote: > On Apr 14, 2016, at 10:40 PM, John McCall wrote: To me, the unparenthesized style suggests that the input and output are peers, which feels more natural for the sort of value-to-value

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

> On Apr 14, 2016, at 11:05 PM, Chris Lattner wrote: > > >> On Apr 14, 2016, at 11:01 PM, Chris Lattner via swift-evolution >> > wrote: >> >> On Apr 14, 2016, at 9:49 PM, Stephen Canon >

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

+1; this is great! I have nothing but good things to say about the proposal itself. I have two smaller questions, however; I apologize if they are off-topic. One is if there’s any ETA or similar for a glimpse at the “complete picture” of Swift’s revised numeric protocols; these floating-point

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

+1 to the proposal > On 15 Apr 2016, at 13:11, David Hart via swift-evolution > wrote: > > If the original rationale is gone, shouldn’t we also get rid of the empty > tuple-type and replace it by a full-blown Void instead of Void being a > typealis for the empty

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

If the original rationale is gone, shouldn’t we also get rid of the empty tuple-type and replace it by a full-blown Void instead of Void being a typealis for the empty tuple? (Int) -> Float (String) -> Void () -> Void () -> Double It looks more consistent to me. > On 15 Apr 2016, at

Re: [swift-evolution] SE-0063: SwiftPM System Module Search Paths - JSON output of install dependencies of a package

Fair enough. Thank you, sorry for being late with my comment, great proposal, no other remarks. From: Max Howell To: Vadim Eisenberg/Haifa/IBM@IBMIL Cc: swift-evolution@swift.org Date: 04/15/2016 01:04 AM Subject:Re: [swift-evolution] SE-0063: SwiftPM

Re: [swift-evolution] [Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters

Why? What guideline are you referencing? > On 15 Apr 2016, at 09:53, Jacob Bandes-Storch via swift-evolution > wrote: > > Was the syntax fully bikeshedded by the core team before acceptance? Perusing > the API guidelines, one could also imagine: > >

Re: [swift-evolution] [Proposal] mapValues

This is a clarification on what I meant (I haven't had much time to test it, but I think it's representative): https://gist.github.com/therealbnut/c223d90a34bb14448b65fc6cc0ec70ac Sorry if I've derailed this conversation, I'm in support of mapValues, but I feel like map itself should be mapping

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

+1 Makes language cleaner and more consistent. > On 15 Apr 2016, at 06:57, Chris Lattner via swift-evolution > wrote: > > We currently accept function type syntax without parentheses, like: > > Int -> Float > String -> () > > etc. The original rationale aligned

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

True, that makes sense. I was simply trying to explore different possibilities of how these things could be represented in the syntax. What about #type(d) for static (declaration) type and type(v) for dynamic (value/instance) type? Or would that be potentially confusing as well? The reason

Re: [swift-evolution] [Proposal] Shadowing imported functions

Yes, re-labelling is allowed, as well as reordering. I will add that to the proposal. 2016-04-15 5:01 GMT+03:00 Dany St-Amant : > > Le 14 avr. 2016 à 11:28, Антон Жилин via swift-evolution < > swift-evolution@swift.org> a écrit : > > As promised, I've created a proposal to

Re: [swift-evolution] TreeLiteralConvertible

> On 15 Apr 2016, at 03:22, John McCall wrote: > > The heterogeneity that I'm referring to is the mix of sub-trees and leaves at > a single level. … which is why I was making the point that that part of the heterogeneity problem is solved. > Your JSON literal example is

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

> I do not think that I was conflating these two aspects. Using #type(self) > would return the particular type of the current instance (dynamic type) while > using #type(A.var) would return the declared (static) type of the property. Taras, to me personally, #something suggests evaluation at

Re: [swift-evolution] [Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters

Was the syntax fully bikeshedded by the core team before acceptance? Perusing the API guidelines, one could also imagine: #selector(setting: Person.name) #selector(forSetting: Person.name) On Thu, Apr 14, 2016 at 3:58 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org>

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

Chris, > Given all this, I think it makes sense to go for syntactic uniformity between > parameter list and function types, and just require parenthesis on the > argument list. The types above can be trivially written as: > > (Int) -> Float > (String) -> () I don't care about this

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

+1. The only times I've ever had to use this outside of HoFs were dirty, dirty hacks that probably should have used this anyway. I can stomach an extra bit of syntax everywhere if it means removing an inconsistency in the wider language. ~Robert Widmann 2016/04/15 0:57、Chris Lattner via

Re: [swift-evolution] TreeLiteralConvertible

Hey! >> Can you please give us a few real-world examples where initializing a >> nontrivial tree-like data structure in code would be useful? > > I suppose we always prefer to move *all* data into databases or files with > dedicated data formats, *including* arrays, strings, dictionaries, etc.

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

>> Are there potential conforming types which aren't Comparable? > > Not at present, but I expect there to be in the future. Modular integers and > complex numbers come to mind as the most obvious examples. Ooh, those are great examples. That is definitely the right decision, then. (One thing

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

> /// The quotient of `self` dividing by `rhs`. > // Arithmetic provides a default implementation of this method in terms > // of the mutating `divide` operation. > @warn_unused_result > func divided(by rhs: Self) -> Self > > /// Divides `self` by `rhs`. > mutating func divide(by

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

> On Apr 14, 2016, at 11:01 PM, Chris Lattner via swift-evolution > wrote: > > On Apr 14, 2016, at 9:49 PM, Stephen Canon > wrote: >>> On Apr 14, 2016, at 4:55 PM, Stephen Canon via swift-evolution >>>

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

On Apr 14, 2016, at 9:49 PM, Stephen Canon wrote: >> On Apr 14, 2016, at 4:55 PM, Stephen Canon via swift-evolution >> > wrote: >>> Provide basic constants (analogues of C's DBL_MAX, etc.) >> Nice, have you considered