Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 26, 2016, at 10:56 PM, Jonathan Hull via swift-evolution > wrote: > > Can’t a Sequence be potentially infinite, whereas a collection has a defined > count/endIndex? Other than that, I agree with your statement. > > Here is what I see as the appropriate

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> On Jun 26, 2016, at 6:38 PM, Károly Lőrentey via swift-evolution > wrote: > > I’m not sure if this has been mentioned yet, but the semantics of Integer > operations also needs to be tied down. In particular, the expected behavior > of the remainder operation (in

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

> On Jun 26, 2016, at 10:11 AM, Hooman Mehr wrote: > > Syntax by itself is not clear enough. Appending Initializable makes it too > long. > > We can replace Syntax with LiteralSyntax to clarify. Then we will have: > > extension MyNumber: LiteralSyntax.Integer,

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

> On Jun 27, 2016, at 7:40 AM, Ben Rimmington wrote: > > > > CORRECTIONS: > > Find:"ExtendedGraphemeClusterConvertible" > Replace: "ExtendedGraphemeClusterLiteralConvertible" > > Find:

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Mon Jun 27 2016, Xiaodi Wu wrote: > On Mon, Jun 27, 2016 at 9:10 AM, Dave Abrahams > wrote: > >> >> on Sun Jun 26 2016, Xiaodi Wu wrote: >> >> > On Sun, Jun 26, 2016 at 2:18 PM, Erica Sadun via swift-evolution < >> >

Re: [swift-evolution] Stdlib closure argument labels and parameter names

On Mon, Jun 27, 2016 at 9:10 AM, Dave Abrahams wrote: > > on Sun Jun 26 2016, Xiaodi Wu wrote: > > > On Sun, Jun 26, 2016 at 2:18 PM, Erica Sadun via swift-evolution < > > swift-evolution@swift.org> wrote: > > > >> > >> See below. But in a nutshell, `do` gets the idea

Re: [swift-evolution] Revisiting SE-0041 Names

on Thu Jun 23 2016, Xiaodi Wu wrote: > On Thu, Jun 23, 2016 at 4:34 AM, Dmitri Gribenko > > wrote: > >> On Thu, Jun 23, 2016 at 2:00 AM, Xiaodi Wu >> wrote: >> > On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via

Re: [swift-evolution] [Idea] Syntactic sugar for using methods as functions

I don't have anything against it, besides that it is an additive feature and should probably wait for after Swift 3. Félix > Le 27 juin 2016 à 07:22:42, David Rönnqvist via swift-evolution > a écrit : > > +1. This makes sense to me. > > Since the API Guidelines

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

> On 27 Jun 2016, at 14:37, Xiaodi Wu wrote: > > DictionaryLiteral seems fine to me; it's as much a dictionary as ArrayLiteral > is an array, right? The `DictionaryLiteral` *structure* isn't a hash table. It's an array of key-value pairs, and allows duplicate keys.

Re: [swift-evolution] [Idea] Syntactic sugar for using methods as functions

+1. This makes sense to me. Since the API Guidelines say: “Prefer methods and properties to free functions”, it would make sense to add sugar like this to make methods just as convenient and clear to pass to higher order functions as free functions currently are. I’m also wondering if the

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> On Jun 27, 2016, at 8:40 AM, Dave Abrahams via swift-evolution > wrote: > “each” is just what's required to make “so” read sensibly. > >(0..<100).filter(so: isPrime) > > doesn't make any obvious sense. Shouldn't there be a term of art exemption for

Re: [swift-evolution] Stdlib closure argument labels and parameter names

Just tossing my vote in the hat for renaming .filter() to something like .select() since that better matches what it does, IMO. “Filter” is almost like the opposite word from what it should be since the closure returning true is what decides what is included in the results, not what is filtered

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On Jun 25, 2016, at 05:06, Karl via swift-evolution > > wrote: > >> Proposal: https://gist.github.com/karwa/273db66cd8a5fe2c388ccc7de9c4cf31 >> Karl, thanks for

Re: [swift-evolution] Revisiting SE-0041 Names

on Mon Jun 27 2016, Matthew Johnson wrote: >> On Jun 27, 2016, at 9:29 AM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Wed Jun 22 2016, Matthew Johnson >> > wrote: >> On Jun 22, 2016,

Re: [swift-evolution] Revisiting SE-0041 Names

on Wed Jun 22 2016, Matthew Johnson wrote: >> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko >> wrote: >> >> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution >> >> >

Re: [swift-evolution] Revisiting SE-0041 Names

> On Jun 27, 2016, at 9:29 AM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Jun 22 2016, Matthew Johnson > wrote: > >>> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko >>>

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

Alright, I’ve written it up a proposal; you can find it here . This is my first proposal (and anyways I’ve been told that I can be unclear), so if you guys see anything that should be changed feel free to let me know. Here it is

Re: [swift-evolution] [Proposal] Sealed classes by default

That is a very good point, it should be explicitly mentioned in the proposal. My thought would be that since in the Obj-C runtime it's not possible to guarantee a class won't have subclasses, or that a method is not overriden, Obj-C classes would be imported as open. On the Swift side, I think

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

> On Jun 27, 2016, at 2:51 PM, Russ Bishop via swift-evolution > wrote: > >> >> On Jun 27, 2016, at 12:35 AM, Christopher Kornher > > wrote: >> >> >>> On Jun 26, 2016, at 4:25 PM, Russ Bishop >>

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

Comments inline > On Jun 27, 2016, at 9:39 AM, Dave Abrahams wrote: > > > I should be clear up-front about the main problem I'm trying to solve: > > Today, people see a beautiful, simple protocol (Sequence) to which many > things conform. They don't recognize that there's

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> [Just to complicate things... I wonder if finiteness is really > meaningful. It's easy to create a finite sequence that's so long that > it's “effectively infinite.”] And similarly, operations like `first(while:)` on an infinite sequence might or might not produce an infinite sequence,

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

> Just want to point out that `prefix` and `suffix` may introduce ambiguity, as > they are also imperative verbs. For example, `S.prefix(1)` can be inferred as > prefixing `1` to the sequence, instead of retrieving the prefix of the > sequence. While that is true, I think the types will

Re: [swift-evolution] [Pitch] Remove type inference for associated types

on Mon Jun 27 2016, Austin Zheng wrote: > Thanks for your response, Dave. > > There is a bit of a dilemma here: wait until the generics and type system > features have stabilized at the risk of making major source-breaking > changes after 3.0, or make changes now without clarity about the

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

I apologize for all the typos I make, I’m way too tired and it’s already late night for me. (I just feel like I need to apologize :] ) I meant: Anything else I may need to change to drive my proposal into that direction? --  Adrian Zubarev Sent with Airmail Am 28. Juni 2016 um 00:17:35,

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Mon Jun 27 2016, Anton Zhilin wrote: > Dave Abrahams via swift-evolution writes: > >> I should be clear up-front about the main problem I'm trying to solve: >> >> Today, people see a beautiful, simple protocol (Sequence) to which many >>

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

on Thu Jun 23 2016, Remy Demarest wrote: > I would also like to know why bit shifting and bit-wise and, or and > xor operations are limited to FixedWidthInteger. I would think that a > variable-length integer would be able to handle these operations in a > predictable

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

on Fri Jun 24 2016, plx wrote: > +1 but with a few reservations. > > # Arithmetic > > What *are* the expected semantics of the operators? It seems like you > can’t assume much about a generic `Arithmetic` type, e.g. in a generic > context I can’t reliably assume even

Re: [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

I wasn’t going to be +1 guy, but “+1”: I use where pretty heavily across both `if let` and in `for … in` loops. I find both really readable when formatted, and I’d be disappointed to see them go. I’m super annoyed that I missed (see “wasn’t paying attention during”) the review of SE-0099

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

> On Jun 27, 2016, at 2:35 PM, L. Mihalkovic via swift-evolution > wrote: > > > > Regards > (From mobile) > > On Jun 27, 2016, at 10:18 PM, Dennis Lysenko via swift-evolution > > wrote: > >> My 2c: >>

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 27, 2016, at 4:27 PM, Andrew Trick via swift-evolution > wrote: > > >> On Jun 27, 2016, at 3:35 PM, Dave Abrahams > > wrote: >> >>> Casting from a raw pointer to a typed pointer is only more dangerous >>>

Re: [swift-evolution] Revisiting SE-0041 Names

> On Jun 27, 2016, at 4:47 PM, Dave Abrahams via swift-evolution > wrote: > >> Maybe we could say that the type gives form to the literal or embodies >> the literal? Thus maybe a name like `IntegerLiteralEmbodiment` or >> `IntegerLiteralManifestation`, maybe even

Re: [swift-evolution] [Proposal] Sealed classes by default

Could you elaborate on how we should treat classes imported from Objective-C or CF-style C? That is, do we always annotate them as being “open” because those paradigms permit subclassing anywhere, or do you propose some kind of recommended “sealed” audit, or what? > On Jun 27, 2016, at 3:40

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 27, 2016, at 2:41 PM, Dave Abrahams wrote: > > > on Mon Jun 27 2016, Matthew Johnson > wrote: > >>> On Jun 27, 2016, at 11:46 AM, Dave Abrahams >> > wrote: >>> >>> >>> on Mon

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 23, 2016, at 6:40 PM, Andrew Trick via swift-evolution > wrote: > > https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md Would anyone like to bikeshed the allocation API? Here are two options with a slight stylistic

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

This looks like good solution that will provide the intended behavior. Thanks Jordan! Sent from my iPad > On Jun 27, 2016, at 6:19 PM, Jordan Rose wrote: > > Robert and I wrote up the changes in the form of an amendment to SE-0025: >

Re: [swift-evolution] [Proposal] Sealed classes by default

I was also referring to how we present Objective-C classes in Swift. That is, if a Swift user tries to subclass an Objective-C-imported class, then we’d take into account sealed-ness in order to issue an error/warning, etc. If you are also proposing a Clang attribute for this, e.g.

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

I would be against removing access modifiers on extensions. I actually don't see anything wrong with the way extensions work with modifiers right now. Consistency for consistency's sake is never a good measurement if it is not addressing a pain point. When ever I extend a swift standard

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> After all, it's absurd that a closure would be supplied as an argument for > any purpose other than being done or invoked or performed. In the calls at hand, like `withUnsafeMutablePointer`, "do" is the verb of the call. That is not true of many—perhaps most—closures. For instance, the verb

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Sent from my moss-covered three-handled family gradunza > On Jun 27, 2016, at 4:50 PM, Andrew Trick wrote: > > >>> On Jun 27, 2016, at 4:27 PM, Andrew Trick via swift-evolution >>> wrote: >>> >>> On Jun 27, 2016, at 3:35 PM, Dave Abrahams

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Sent from my moss-covered three-handled family gradunza > On Jun 27, 2016, at 4:27 PM, Andrew Trick wrote: > > >>> On Jun 27, 2016, at 3:35 PM, Dave Abrahams wrote: >>> >>> Casting from a raw pointer to a typed pointer is only more dangerous >>> than

Re: [swift-evolution] Revisiting SE-0041 Names

on Mon Jun 27 2016, David Sweeris wrote: >> On Jun 27, 2016, at 13:13, Dave Abrahams via swift-evolution >> wrote: >> >> There's an exception to everything. In this case, protocols used to >> interface with the language at the lowest levels may be purely about >>

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

> On Jun 27, 2016, at 2:35 PM, L. Mihalkovic via swift-evolution > wrote: > > > > Regards > (From mobile) > > On Jun 27, 2016, at 10:18 PM, Dennis Lysenko via swift-evolution > > wrote: > >> My 2c: >>

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

> On Jun 25, 2016, at 10:57 AM, Anton Zhilin via swift-evolution > wrote: > I replaced `precedencegroup` with `precedence` and added `Precedence` > suffix to all precedence group names. See: > > https://github.com/Anton3/swift-evolution/blob/fix-operator- >

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 27, 2016, at 3:27 PM, Dave Abrahams wrote: > > Aside from the fact that it doesn't compile? (s/Type/self/) ;-) Sorry, I keep converting between decl/use style and forgetting to update that. > No gripes. I think I suggested it. I was responding to LM, and the

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 27, 2016, at 9:39 AM, Dave Abrahams via swift-evolution > wrote: > > Perhaps the language should accept types conforming to either of two > unrelated protocols (your Sequence and Iterator, as you've described > them, with no refinement relationship) for

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

Robert and I wrote up the changes in the form of an amendment to SE-0025: https://github.com/apple/swift-evolution/pull/383 . Please let me know if we missed anything! I talked briefly to Chris and he said the core team will decide whether it

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

Sent from my iPad > On Jun 27, 2016, at 8:32 PM, Jonathan Hull via swift-evolution > wrote: > > Comments inline > >> On Jun 27, 2016, at 9:39 AM, Dave Abrahams wrote: >> >> >> I should be clear up-front about the main problem I'm trying to

Re: [swift-evolution] [Draft] UnsafeRawPointer API

on Mon Jun 27 2016, Andrew Trick wrote: >> On Jun 27, 2016, at 1:52 PM, L. Mihalkovic >> wrote: >> >> think you mean T.Type, not T.self, because this looks like a declaration. >>> >>> To evaluate, you have to look at the use-site: > >>> >>> let p =

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Fri Jun 24 2016, Anton Zhilin wrote: >> +100. I even want to brought the term-of-art argument here. IMO These >> functions are expected to be called without any parameter names. > > That would probably be a good scenario, but core team needs to release > their

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 27, 2016, at 3:35 PM, Dave Abrahams wrote: > >> Casting from a raw pointer to a typed pointer is only more dangerous >> than other raw pointer operations because it is the first step in this >> sequence of operations, which is undefined: >> >> ptrA =

Re: [swift-evolution] [Draft] UnsafeRawPointer API

on Mon Jun 27 2016, "L. Mihalkovic" wrote: > Regards > (From mobile) > >> On Jun 27, 2016, at 8:39 AM, Dave Abrahams wrote: >> >> >> on Fri Jun 24 2016, Andrew Trick wrote: >> On Jun 24, 2016, at 11:22 AM, Andrew Trick via swift-evolution

Re: [swift-evolution] [Draft] UnsafeRawPointer API

on Mon Jun 27 2016, Andrew Trick wrote: > I agree, this syntax works best, all considered: > > UnsafeRawPointer.cast(to: UnsafePointer.Type) > >> On Jun 26, 2016, at 11:39 PM, Dave Abrahams wrote: >> is better. But I hate that the language doesn't give us a way to say >>

[swift-evolution] [Proposal] Sealed classes by default

Hello! I sent this as a PR on the swift-evolution repo, but we never had any discussion about it on-list, besides a long time ago . Here's the first draft of the proposal:

Re: [swift-evolution] [discussion] Change the behavior of @objc on a class?

on Mon Jun 27 2016, Jordan Rose wrote: > Hey, all. An engineer at Apple noticed the following behavior: > > 1. class Foo: NSObject → exposed to Objective-C, Swift-style (mangled) > runtime name > 2. @objc class Foo: NSObject → exposed to Objective-C, Swift-style

Re: [swift-evolution] Revisiting SE-0041 Names

on Thu Jun 23 2016, Xiaodi Wu wrote: > On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> > On Jun 22, 2016, at 19:35, Dmitri Gribenko wrote: >> > >> >> On Wed, Jun 22, 2016 at 5:15

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

I should be clear up-front about the main problem I'm trying to solve: Today, people see a beautiful, simple protocol (Sequence) to which many things conform. They don't recognize that there's a semantic restriction (assume you can make only a single-pass!) on it, so they write libraries of

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

On Mon, Jun 27, 2016 at 12:38 AM, Károly Lőrentey wrote: > > > On 2016-06-25, at 14:23, Nicola Salmoria via swift-evolution < > swift-evolution@swift.org> wrote: > > The first comment I have to make is that, as has already been noted by > plx, > > the Arithmetic protocol

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Mon Jun 27 2016, Erica Sadun wrote: >> On Jun 27, 2016, at 8:40 AM, Dave Abrahams via swift-evolution >> wrote: >> “each” is just what's required to make “so” read sensibly. >> >>(0..<100).filter(so: isPrime) >> >> doesn't make any obvious sense. > >

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Mon Jun 27 2016, Matthew Johnson wrote: >> On Jun 26, 2016, at 10:56 PM, Jonathan Hull via swift-evolution >> wrote: >> >> Can’t a Sequence be potentially infinite, whereas a collection has a >> defined count/endIndex? Other than that, I agree with your > >>

Re: [swift-evolution] [Idea] Syntactic sugar for using methods as functions

> struct Foo { > let bar: Int > > func getBar() -> Int { > return self.bar > } > > } > > let foos = [Foo(bar: 1), Foo(bar: 2), Foo(bar: 3)] > let bars = foos.map(.getBar) This can be done now: let bars = foos.map(Foo.getBar) > While for parameterless functions this might

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`

I think the rationale thread for the original version of this proposal pretty much shut down the possibility of disjunctive type constraints. In fact, the primary argument against '&' was that it would encourage conversations about '|'. It's also been added to the commonly rejected proposals

Re: [swift-evolution] Revisiting SE-0041 Names

Regards LM (From mobile) > On Jun 27, 2016, at 4:45 PM, Matthew Johnson via swift-evolution > wrote: > > >> On Jun 27, 2016, at 9:29 AM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Wed Jun 22 2016, Matthew Johnson

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On 27 Jun 2016, at 16:23, Stephen Canon wrote: > > >> On Jun 25, 2016, at 05:06, Karl via swift-evolution >> > wrote: >> >>> Proposal: https://gist.github.com/karwa/273db66cd8a5fe2c388ccc7de9c4cf31 >>>

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

I'm with those recommending round, rounded, roundUp, roundedUp, roundDown, roundedDown, with Remy's precision factored in as needed. This is usually the point where Dave A wanders in and explains how this can all be implemented by a single FloatingPoint protocol, with built-in properties and

Re: [swift-evolution] [Pitch] Add Null struct to Foundation

well, JSONSerialization uses NSNull() as the null value currently. I think this is right, because a JSON null is conceptually a different thing than `nil as Any?` - Representing null as "not any value" a.k.a. `nil as Any?` would be a pun in my opinion. -Michael > Am 27.06.2016 um 08:32

[swift-evolution] [Question] Grand Renaming and Delegate/Datasource protocols !

Hi everyone, I can't find anything about Cocoa Delegate/Datasource protocol "Grand Renaming" for Swift 3 Is something planned about this ? Because I find that actual names don't fit with Swift 3 API guidelines. For instance : func numberOfSectionsInTableView(_ tableView: UITableView) -> Int

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`

> On Jun 25, 2016, at 12:00 AM, L. Mihalkovic > wrote: > > Inline > Regards > (From mobile) > >> On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Jun 23, 2016, at 8:55 PM, Jordan Rose via

Re: [swift-evolution] Stdlib closure argument labels and parameter names

On 27.06.2016 19:02, Erica Sadun via swift-evolution wrote: On Jun 27, 2016, at 8:40 AM, Dave Abrahams via swift-evolution > wrote: “each” is just what's required to make “so” read sensibly. (0..<100).filter(so: isPrime) doesn't

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`

Inline Regards LM (From mobile) > On Jun 27, 2016, at 6:48 PM, Joe Groff wrote: > > >> On Jun 25, 2016, at 12:00 AM, L. Mihalkovic >> wrote: >> >> Inline >> Regards >> (From mobile) >> >>> On Jun 25, 2016, at 1:00 AM, Joe Groff via

Re: [swift-evolution] Revisiting SE-0041 Names

On Mon, Jun 27, 2016 at 6:47 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Thu Jun 23 2016, Xiaodi Wu wrote: > > > On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via swift-evolution < > > swift-evolution@swift.org> wrote: > > > >> >

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

Regards (From mobile) > On Jun 27, 2016, at 11:59 PM, Adrian Zubarev via swift-evolution > wrote: > > “The access modifier of an extension sets the default modifier of its members > which has no modifier applied to them.” I get it now.. "which do not have their

Re: [swift-evolution] Partial list of open Swift 3 design topics

> This came from a short list of topics Doug provided me, but the basic issue > is that: > > func f(a : Int, b : Int) { > let x = f // x has type (a: Int, b: Int) -> () > } > > I’m not exactly sure what the counterproposal is. My guess is to require let x = f(a:,b:) (specifying arguments)?

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Regards LM (From mobile) > On Jun 28, 2016, at 12:18 AM, Andrew Trick wrote: > > >>> On Jun 27, 2016, at 1:52 PM, L. Mihalkovic >>> wrote: >>> >>> think you mean T.Type, not T.self, because this looks like a declaration. >>> >>> To

Re: [swift-evolution] Partial list of open Swift 3 design topics

> On 27 Jun 2016, at 00:57, Russ Bishop via swift-evolution > wrote: > > >> On Jun 22, 2016, at 11:48 PM, David Hart via swift-evolution >> wrote: >> >> >>> - Bridge NSRange to “Range?” >> >> I don’t think I can handle writing a

Re: [swift-evolution] [Draft] UnsafeRawPointer API

on Mon Jun 27 2016, Andrew Trick wrote: >> On Jun 27, 2016, at 7:15 PM, Dave Abrahams wrote: >> >> >> >> Sent from my moss-covered three-handled family gradunza > >> >> On Jun 27, 2016, at 4:27 PM, Andrew Trick > > wrote: >>

Re: [swift-evolution] [Discussion] Terms of Art Swiftification

I liked Brent Royal-Gordon’s suggestion of `every(where:)`. Select is too abstract and SQLish, whereas ‘every’ is a basic english word that would look familiar in a Swift Playground. Or `where(_:)` I could live with. Patrick > On 28 Jun 2016, at 5:31 AM, Erica Sadun via swift-evolution >

Re: [swift-evolution] [Proposal] Sealed classes by default

-1 for the fact that if all devs can write working code, fewer can do it in a clear structured fashion that is well designed for extensibility. A couple months ago I even ran into difficulties when trying to extend AlamoFire because some things had not been designed as cleanly as they could

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Mon Jun 27 2016, Patrick Smith wrote: > Side question: is there going to be any situation where I’m iterating > through a sequence/collection that I wouldn’t want to always use > `lazy`? Is `lazy` *always* going to be more efficient than the > array-creating defaults when the result is

Re: [swift-evolution] Partial list of open Swift 3 design topics

I think the point is to get rid of the argument labels. 'x' should be typed simply (Int, Int) -> (). That being said, right now the argument labels in the type don't seem to actually affect anything, so like Chris I'm not sure what the counter-proposal is. (cc. Doug) Best, Austin > On Jun

Re: [swift-evolution] Partial list of open Swift 3 design topics

Oh, I see. The issue is then the following: let x = f x(1, 2) // Error: Missing argument labels 'a:b:' in call let y: (Int, Int) -> () = f f(1, 2) // OK Which requires you to write x(a: 1, b: 2). I must admit, however, that I always liked this behavior... > On Jun 28, 2016, at 7:06 AM, Austin

Re: [swift-evolution] Stdlib closure argument labels and parameter names

Side question: is there going to be any situation where I’m iterating through a sequence/collection that I wouldn’t want to always use `lazy`? Is `lazy` *always* going to be more efficient than the array-creating defaults when the result is iterated? For instance, something much better than

Re: [swift-evolution] [discussion] Change the behavior of @objc on a class?

Do you know how would this affect e.g. XIB files or CoreData models where you have the class name + module? If the class was previously marked @objc and now it would be implicitely @objc(ClassName), would it require all XIB files to be updated, or would the XIB compiler be able to deal with it?

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Regards LM (From mobile) > On Jun 28, 2016, at 12:25 AM, Dave Abrahams wrote: > > >> on Mon Jun 27 2016, "L. Mihalkovic" wrote: >> >> Regards >> (From mobile) >> >>> On Jun 27, 2016, at 8:39 AM, Dave Abrahams wrote: >>> >>> >>> on Fri Jun 24

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

> On Jun 27, 2016, at 9:10 PM, Christopher Kornher wrote: > > >> On Jun 26, 2016, at 11:22 PM, Charlie Monroe via swift-evolution >> > wrote: >> >>> All object references used within a closure must unwrap

Re: [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

> On 24 Jun 2016, at 17:10, Charlie Monroe via swift-evolution > wrote: > > If the `where` keyword were to stay in the language, how would you feel about > extending it? One major argument is that it is not as powerful as guard or > if. How about something like

Re: [swift-evolution] [Idea] Syntactic sugar for using methods as functions

Wow. I did not see that coming! Either way, I agree that Foo.bar works, but then again, so does Enum.value and we give that one a free pass. Beyond "it's not how it works right now", I don't really have any serious argument against the feature. I'd like to have that at some point. Félix > Le

Re: [swift-evolution] [Discussion] Terms of Art Swiftification

Erica had a nice list of various term-of-art usages among languages - it included filter, map, etc. - I just can't seem to find it anywhere. This nicely showed that there is only a few languages that name things differently, mostly C# and C++. "filter" is nowadays quite a universal word that

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 27, 2016, at 7:15 PM, Dave Abrahams wrote: > > > > Sent from my moss-covered three-handled family gradunza > > On Jun 27, 2016, at 4:27 PM, Andrew Trick > wrote: > >> >>> On Jun 27, 2016, at 3:35 PM, Dave Abrahams

Re: [swift-evolution] [Discussion] Terms of Art Swiftification

I would support a rename of filter to the right name. This is a little silly but wouldn't select(…) become selecting(…) with the naming rules? I think where(…) would only make sense if it was lazy by default. There probably needs to be a whole survey of names (seems kinda late for swift 3). I

Re: [swift-evolution] [Question] Grand Renaming and Delegate/Datasource protocols !

> I can't find anything about Cocoa Delegate/Datasource protocol "Grand > Renaming" for Swift 3 > Is something planned about this ? > > Because I find that actual names don't fit with Swift 3 API guidelines. > > For instance : > > func numberOfSectionsInTableView(_ tableView: UITableView) ->

Re: [swift-evolution] Revisiting SE-0041 Names

on Mon Jun 27 2016, Erica Sadun wrote: >> On Jun 27, 2016, at 4:47 PM, Dave Abrahams via swift-evolution >> wrote: >> >>> Maybe we could say that the type gives form to the literal or embodies >>> the literal? Thus maybe a name like `IntegerLiteralEmbodiment` or

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

I apologize for not getting the threading right in this email, Anton; Mail seems to have glitched and lost your message. > • Renaming `index(of:/where:)` to `earliestIndex(…)` and `first(where:)` > to `earliest(where:)` > > -1, because `index` is considered state-of-art. `first` does not exist

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Hi Andy, Thank you for the proposal! A few comments from me. - In the "Custom memory allocation section" you write: > Note: The same allocated raw memory cannot be used both for this custom > memory allocation case and for the C buffer case above because the C buffer > requries that the

Re: [swift-evolution] [Question] Grand Renaming and Delegate/Datasource protocols !

I believe that renaming of Apple’s frameworks is not in the scope of swift-evolution; I think you’re supposed to file a radar. On Mon, Jun 27, 2016 at 9:54 AM Jerome ALVES via swift-evolution < swift-evolution@swift.org> wrote: > Hi everyone, > > I can't find anything about Cocoa

[swift-evolution] [Discussion] Terms of Art Swiftification

Under consideration is the resolution that "some terms of art while appropriate to many FP languages, may be better served by using Swift names." Consider, for example, `filter(_:)`. Sean Heber writes, > Just tossing my vote in the hat for renaming .filter() to something like > .select()

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> David Sweeris wrote: > > I'm starting to come down from me earlier +1... Floor and ceiling are more > functions than properties of a number, aren't they? I agree with that. Having used various math libraries for decades now, I'd find it odd to find these as members of a floating-point type,

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On Jun 27, 2016, at 3:34 PM, Saagar Jha wrote: > > Seems fine to me. One addition though: some sort of round(withPrecision: Int) I noted in another post on this thread that this doesn’t actually make any sense for FloatingPoint. I’ll flesh that out here for

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Mon Jun 27 2016, Erica Sadun wrote: >> On Jun 27, 2016, at 12:02 PM, Dave Abrahams wrote: >> >> >> on Mon Jun 27 2016, Erica Sadun wrote: >> > On Jun 27, 2016, at 8:40 AM, Dave Abrahams via swift-evolution wrote: “each” is

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On Jun 27, 2016, at 12:34 PM, Karl wrote: > > >> On 27 Jun 2016, at 16:23, Stephen Canon > > wrote: >> >> >>> On Jun 25, 2016, at 05:06, Karl via swift-evolution >>>

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Mon Jun 27 2016, Matthew Johnson wrote: >> On Jun 27, 2016, at 11:46 AM, Dave Abrahams wrote: >> >> >> on Mon Jun 27 2016, Matthew Johnson > > wrote: >> > On Jun 26, 2016, at 10:56 PM, Jonathan Hull via swift-evolution

  1   2   >