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

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

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

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

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

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

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] [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] 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] [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 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] [Draft] UnsafeRawPointer API

> 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 = UnsafePointer(r, to: Int.self) >> >> I don't find “to” to

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

If you want consistent behavior, the proposal should just be “remove access modifiers from extensions”. That way, access for members follows the same defaults as in the original type. The only purpose for access modifiers on extensions is to change the default, so if you don’t like the behavior

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

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 > “don't deduce generic parameters here.” This is

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

That’s a very good point, IMHO. - Dave Sweeris > On Jun 27, 2016, at 2:43 PM, Stephen Canon via swift-evolution > wrote: > > >> On Jun 27, 2016, at 3:34 PM, Saagar Jha wrote: >> >> Seems fine to me. One addition though: some sort of

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

> 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 > syntax. Should we use a different word to

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

> On Jun 27, 2016, at 13:00, Adrian Zubarev via swift-evolution > wrote: > > I still have no idea why you want to make this change, other than “putting an > access modifier on an extension is different from putting an access modifier > on a type”. Are you trying to

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

“The access modifier of an extension sets the default modifier of its members which has no modifier applied to them.” public extension SomeType { func extensionMember() {} } “If there the extension has no access modifier, then the default modifier of its members which has no explicit

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

Charlie Monroe via swift-evolution writes: > This will only get you an array of closures: > > let bars = foos.map(Foo.getBar) // [() -> Int, () -> Int, () -> Int] > bars[0] // () -> Int > bars[0]() // 1 Just checked: struct A { func a() -> Int { return 0 } }

Re: [swift-evolution] [Proposal draft] NSError bridging

Obviously, I’m in favor of this one. +1! I think I did prefer the older name of CustomUserInfoError for the domain/code/userInfo protocol, rather than CustomNSError. This is just because I’d like to be able to do a global search through my project for “NSError” and have it turn up empty. Maybe

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

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 >>> wrote: >>> On Jun 24, 2016, at 11:17 AM,

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

I considered suggesting that at first - and maybe that’d be easier/better - but I liked the idea of preserving the *intent* of the alias in different scenerios. Not sure. That could be hammered out assuming people thought this was a good direction to even consider vs. just picking a single name

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

Yeah, I like that they have a common prefix, but I sort of don’t like how that all looks, either. What if they were grouped first by the fact that they are delegates? func dataSource(tableview: UITableView, numberOfRowsInSection section: Int) -> Int func delegate(tableview: UITableView,

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

More generically, it could be something like @alias: > @alias(filter) func where(…) This would allow this particular case to have another name, but also allow for things like alternate spellings. Jeff Kelley slauncha...@gmail.com | @SlaunchaMan |

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

And along a similar line of thinking, what about a @termOfArt() attribute that similarly redefines or provides additional names for things. This way the name in the standard library/etc would be the “Swift” version of the name - but there’d be a way to use it and find it even if you’re familiar

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

> On Jun 27, 2016, at 1:26 PM, Jordan Rose via swift-evolution > 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 →

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

> On Jun 24, 2016, at 11:30 PM, Austin Zheng wrote: > > Would you be willing to elaborate a bit on "Removing argument labels from the > type system"? The bulk of this went away when tuple splatting was removed, > and values of function type already seem to ignore the

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

FWIW, I rely on typing `tableView` and looking at the autocompletions to find delegate methods. Not that that makes this a bad idea, and I'm not sure how many other developers do that (although I imagine quite a few do). Just food for thought. On Mon, Jun 27, 2016 at 11:44 AM Saagar Jha via

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

Regards (From mobile) > On Jun 27, 2016, at 10:18 PM, Dennis Lysenko via swift-evolution > wrote: > > My 2c: > > This proposal is made more appealing to me because it is not simply a > 'beginners will get confused' issue. > > I have written tens of thousands of

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

Hadn't thought of roundUp/Down. Makes it so obvious. +10 > On 27 Jun 2016, at 18:32, Erica Sadun wrote: > > I'm with those recommending round, rounded, roundUp, roundedUp, roundDown, > roundedDown, with Remy's precision factored in as needed. > > This is usually the

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

+1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly a carryover from Java. They show up in method signatures from non-nullable-annotated Java, but you can't define a new method that takes e.g. an Int!. The limited scope of this proposal is ideal in my opinion since we see areas

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

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 (mangled) runtime name 3. @objc(Foo) class Foo: NSObject → exposed to

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

Here’s a perhaps unlikely “what if” idea that is tangentially related to the problem that FP and mathematical names are sometimes weird in Swift and often don’t have a place to “live” that makes sense. Let’s say we add an ability to declare a function on a struct/protocol/class/enum as a

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

My 2c: This proposal is made more appealing to me because it is not simply a 'beginners will get confused' issue. I have written tens of thousands of lines of Swift from Swift 1 to the Swift 3 preview and I still can't shake occasionally accidentally capturing `self` strongly when I, for

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

"The access modifier of an extension sets the default modifier of its members which has no modifier applied to them." I cannot understand the sentence, or the following: "If there the extension has no access modifier, then the default modifier of its members which has no explicit modifier will

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

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 > things conform. They don't recognize that there's a semantic restriction >

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

on Sat Jun 25 2016, Austin Zheng wrote: >> On Jun 25, 2016, at 6:23 AM, Matthew Johnson wrote: >> >> Hi Austin, >> >> I’m sorry to say, but this proposal makes me really sad. I consider >> associated type inference one of the more elegant

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

As i said, already deeply regretted mentioning P|Q as on closer examination of a well known precedent it is very realistic to have P only. Apologize again for not doing the due dilligence before pressing send. (From mobile) > On Jun 27, 2016, at 7:04 PM, Austin Zheng

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

on Mon Jun 27 2016, Erica Sadun wrote: > 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

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 1:05 PM, Dave Abrahams wrote: >> >> >> on Mon Jun 27 2016, Erica Sadun > > wrote: >> > On Jun 27, 2016, at 12:02 PM, Dave Abrahams wrote:

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

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

Seems fine to me. One addition though: some sort of round(withPrecision: Int) On Mon, Jun 27, 2016 at 12:23 Stephen Canon via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 27, 2016, at 12:34 PM, Karl wrote: > > > On 27 Jun 2016, at 16:23, Stephen Canon

[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] Stdlib closure argument labels and parameter names

> On Jun 27, 2016, at 1:05 PM, Dave Abrahams wrote: > > > 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: >>>

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 27 Jun 2016, at 04:56, 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

  1   2   >