Re: [swift-evolution] Tuple accessor shorthand

Matthew, What I’m thinking about would be a true equivalent of the closure syntax, where the following: {$0.0.1.2} becomes Tuple.0.1.2 I’m not aware of this being achievable at the language level today. — Sasha > On 18 Dec 2015, at 16:34, Matthew Johnson wrote: >

Re: [swift-evolution] Tuple accessor shorthand

Sorry, I didn’t read your post carefully enough. You are correct, this is not possible. If you need to dig 3 levels deep into a tuple you may have cases where structs would be more appropriate. > On Dec 18, 2015, at 10:01 AM, Alexandre Lopoukhine > wrote: > > Matthew,

Re: [swift-evolution] Tuple accessor shorthand

Oh, you’re right. The first options I considered were either a global function or a new Tuple class/struct with a bunch of these methods built in, which seemed less elegant but I guess are now the only possibility. — Sasha > On 18 Dec 2015, at 16:36, Félix Cloutier wrote: >

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

Genuinely, David, thank you for taking up the mantle of this problem. To me, the lack of type annotations makes the error handling painful and I wish the team just hadn't released it until the design was smoothed out fully. Those dangling catch-all blocks when I've caught all cases make it

[swift-evolution] Tuple accessor shorthand

Hello everyone, To tie into the discussion of shorthands for “map", here’s something that I think is worth considering: Skipping the motivation (mostly, I’m on a mission to eliminate the $ character in my functional code), here’s a function definition: func first(tuple: (A,B)) -> A {

Re: [swift-evolution] [Proposal Idea] dot shorthand for instance members

For me there are two sources to the feeling of noise with simple single-statement closures and using $0, etc. - The first are the braces that seem redundant when there’s only a single statement, and the second is the presence of $0. I played around a bit, and this is probably just a personal

Re: [swift-evolution] [Proposal Idea] dot shorthand for instance members

That's an interesting idea. It's a further shorthand for closures rather than an extension of dot shorthand in a new type context. I wonder if this would apply in contexts where the dot shorthand wouldn't. >From a readability point of view I definitely prefer the dot shorthand. The $ >after

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

I'm not sure I understand your comment either. If I understand correctly, you say that the problem I describe is applicable only to polymorphic types (which is true). However, you then say that the only option today is polymorphic error types. Isn't that an issue? (Also, why is it the only

Re: [swift-evolution] [Pitch] Use enums as enum underlying types

No, because an enum on top of an enum can only restrict the enumerants, not add new ones. An exception hierarchy increases the number of possibilities; an enum-backed enum decreases the number of possibilities. > Le 18 déc. 2015 à 12:21:47, Dennis Lysenko a > écrit

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

> On Dec 18, 2015, at 7:03 AM, Félix Cloutier wrote: > > For this reason, I don't like to encourage throwing polymorphic types, and I > think that it's a misconception to pretend that having a single type in the > throws annotation ensures that the function throws a single

Re: [swift-evolution] [Review] Require self for accessing instance members

Quite quickly: I favor the proposal, but not for its stated reasons. In isolation it’s not a big deal to have implicit-self or to not have implicit-self. It does offer real conveniences, albeit ones that are IMHO rather small-and-petty. Given that, I think implicit self isn’t worth having if

Re: [swift-evolution] Readwrite reflection in Swift

> On Dec 17, 2015, at 11:21 PM, Gergely Orosz via swift-evolution > wrote: > (forwarding a discussion on Swift reflection from swift-users) > > It seems there is no disagreement on how reflection is something we would > want in Swift. Given that until this is part of

Re: [swift-evolution] [Proposal Idea] catching functions for composable and cps error handling

I’m bumping this post in case you missed it Brent. I would find any comments you have on the differences between our approaches very interesting. Thanks! > On Dec 17, 2015, at 10:36 AM, Matthew Johnson via swift-evolution > wrote: > > Brent, thanks for sharing

Re: [swift-evolution] [Proposal] Property behaviors

I am excited by the general direction but I have some concerns about the scope of the design at this time; specifically, it seems like it would benefit a lot from having some flexible-and-efficient way for behaviors to “reach upward” back into their container from within their custom methods

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

> On Dec 18, 2015, at 5:53 AM, Matthew Johnson wrote: > > David, > > Thank you for taking the time to continue working on a proposal for typed > throws. I agree that this feature is very desirable and appreciate the work > you’re doing to bring forward a proposal. I

Re: [swift-evolution] higher kinded types vs Python's syntactic sugars

Shouldn't `filter` accomplish that? On Fri, Dec 18, 2015 at 7:35 AM, Al Skipp wrote: > On 18 Dec 2015, at 00:19, T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote: > > With a Cartesian Product type [like this]( >

Re: [swift-evolution] Bool vs. Optional

This idea has actually come up before, but ultimately we came to the same conclusion as most people here: just because they're isomorphic and fairly similar doesn't mean they're really the same type. (For example, we have some auto-corrections if you try to use an Optional as a Bool. But if

Re: [swift-evolution] [Pitch] Use enums as enum underlying types

Felix, This seems to be very interestingly tied into your comments about polymorphism in 'throws' type annotations. Would you not feel that allowing enums to be built on top of other enums would promote the kind of egregious proliferation of exception polymorphism that discourages so many from

Re: [swift-evolution] [Review] Constraining AnySequence.init

The URL is right (https://github.com/apple/swift-evolution/blob/master/proposals/0014-constrained-AnySequence.md), but the link points to a different proposal (https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md). Copy-paste it to

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

Sorry Matthew, I think my email is having delivery issues because I didn't see any of those messages when I sent mine, though I see them timestamped before my message now. Yes, Felix, those were valid concerns. But, as mentioned before, what we have now is the most polymorphic thing possible. All

Re: [swift-evolution] Proposal: Add .times method to Integer type

-1 from me, if nothing else because the name is confusable with multiplication in the context of integers. > On Dec 18, 2015, at 11:53 AM, Jacob Bandes-Storch via swift-evolution > wrote: > > I like how clean "100.times { doSomething() }" looks, but I'm concerned

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

Sounds like it could be super useful for libraries! How about we drop the quote marks, though? If we have `os(iOS)` and `#available(iOS 9, *)` (in other context), why not `swift(2.2)`? — Radek > On 18 Dec 2015, at 21:22, David Farler via swift-evolution > wrote: >

Re: [swift-evolution] [Proposal] Factory Initializers

> On Dec 18, 2015, at 8:15 AM, Thorsten Seitz wrote: > > Now I'm confused: I thought the idea should enable class clusters, i.e. > allowing AbstractBaseClass(42) to return something with the *dynamic* type of > ConcreteImplementation but still the static type of

Re: [swift-evolution] Proposal: Add .times method to Integer type

You don't need stride for this. func foo() { (0..<5_000).forEach { _ in print("asdf") } } On 18 Dec 2015, at 19:25, Cihat Gündüz via swift-evolution > wrote: Dear Swift-Community, I’d like to

Re: [swift-evolution] [Pitch] Use enums as enum underlying types

I may just not be understanding what this is trying to solve, but the following would work too, wouldn’t it? enum NetworkException { case NoInternetError, SecurityError } enum ParseException { case FailedResponse(statusCode: Int) case EmptyResponse case MissingField(fieldName: String) }

Re: [swift-evolution] [Pitch] Use enums as enum underlying types

This worked for me: enum NetworkException: ErrorType { case NoInternetError, SecurityError } enum ParseException: ErrorType { case FailedResponse(statusCode: Int) case EmptyResponse case MissingField(fieldName: String) } enum ChangePictureError: ErrorType { case

Re: [swift-evolution] Proposal: Add .times method to Integer type

> Am 18.12.2015 um 21:02 schrieb Dave Abrahams : > > -1 from me, if nothing else because the name is confusable with > multiplication in the context of integers. Isn’t it a multiplication? A multiplication of the closure specified? I see it as such. Also I don’t think

[swift-evolution] [Proposal] Swift 2.2: #if swift language version

Hello everyone, For Swift 2.2, I'd like to add the following build configuration to check for the Swift language version. This is meant to be a short proposal, so let's start with a simple example, compiling with the 2.2 compiler: #if swift("2.2") print("Hello") #else this code will not

Re: [swift-evolution] Proposal: Add .times method to Integer type

> But isn’t that more a sign that Swift needs a way to make closures more > useful by adding the possibility of breaking/continueing/returning from > within them rather than a disadvantage of the `times`-syntax itself? Perhaps — there’s a thread, somewhere, with possible solutions to this.

Re: [swift-evolution] Proposal: Add .times method to Integer type

> On Dec 18, 2015, at 12:32 PM, Radosław Pietruszewski > wrote: > >> >> My personal opinion on this is that 5.times { stuff} offers no benefits over >> “repeat 5 { stuff }”, so I’d rather see the later (if anything). >> >> This is all shades of gray with no clear answer.

Re: [swift-evolution] Drafting a proposal: Make conflicting with protocol extension methods an error

> I’m not sure how it affects your proposal, but I just want to point out that > having things that are *only* statically dispatched is sometimes desirable. > For example, Set equality is different from Collection equality, but Set > conforms to Collection. If you write an algorithm over

Re: [swift-evolution] Proposal - Allow properties in Extensions

On Fri, Dec 18, 2015, at 04:38 PM, John McCall wrote: > > On Dec 18, 2015, at 4:19 PM, Kevin Ballard wrote: > > On Fri, Dec 18, 2015, at 04:11 PM, John McCall wrote: > >> I think any storage-in-extensions proposal ought to be a special feature > >> of classes; I would not support

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 18, 2015, at 3:34 PM, Joe Groff via swift-evolution > wrote: > > >> On Dec 18, 2015, at 3:24 PM, Kevin Ballard via swift-evolution >> > wrote: >> >> AFAIK there's no precedent today for

Re: [swift-evolution] Unmanaged, and COpaquePointer vs. Unsafe(Mutable)Pointer

> On Dec 8, 2015, at 3:53 PM, Jordan Rose via swift-evolution > wrote: > >> >> On Dec 8, 2015, at 10:42, Joe Groff via swift-evolution >> > wrote: >> >>> >>> On Dec 8, 2015, at 10:32 AM, Jacob

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 18, 2015, at 5:43 PM, Kevin Ballard via swift-evolution > wrote: > > On Fri, Dec 18, 2015, at 04:38 PM, John McCall wrote: >>> On Dec 18, 2015, at 4:19 PM, Kevin Ballard wrote: >>> On Fri, Dec 18, 2015, at 04:11 PM, John McCall wrote: I

Re: [swift-evolution] [Pitch] Replace 'inout' with '&'

> On Dec 18, 2015, at 5:33 PM, Dave Abrahams wrote: > >> >> On Dec 18, 2015, at 5:30 PM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Dec 18, 2015, at 5:27 PM, Matthew Johnson wrote: >>> >>> +1. Can you

Re: [swift-evolution] Proposal: Remove % operator for floating-point types

> On Dec 18, 2015, at 3:03 PM, Stephen Canon wrote: > > >> On Dec 18, 2015, at 5:57 PM, Chris Lattner > > wrote: >> >> On Dec 18, 2015, at 1:12 PM, Stephen Canon via swift-evolution >>

Re: [swift-evolution] Proposal - Allow properties in Extensions

I’d +1 this proposal for extensions existing in the same module as the class declaration. However, creating new properties for classes defined in other modules would likely involve side-table lookups, and my understanding is that it has some performance implications. In cases where you want

Re: [swift-evolution] [Pitch] Replace 'inout' with '&'

> On Dec 18, 2015, at 5:30 PM, Joe Groff via swift-evolution > wrote: > > >> On Dec 18, 2015, at 5:27 PM, Matthew Johnson wrote: >> >> +1. Can you provide an example showing where you would place it though? > > Good question. Three

Re: [swift-evolution] higher kinded types vs Python's syntactic sugars

Updated the library with that. The only downside that I can see is that flattening, as I had always planned but finally bothered to do, has no way to tell if the left tuple was the produce of a previous cartesian product operation. Small price to pay and all that. Thanks for the insight! On Fri,

Re: [swift-evolution] [Proposal] Property behaviors

On Dec 18, 2015, at 3:56 PM, Kevin Ballard via swift-evolution wrote: > Ultimately, I would love to have non-copyable structs in Swift. But the only > way to really do that is to have references in the language (otherwise the > moment you call a method on a

Re: [swift-evolution] Make non-void functions @warn_unused_result by default

I am also strongly in favor of this proposal. There are probably enough valid use cases for a @suppress_unused_warning but personally I don't think pop() is a great example. I think a second method à la dropFirst/Last/... that returns Void would be better at communicating intent and allows

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

A bare 2.2 will work. Right now, 2.2.2 won't lex because of a requirement that member access of a numeric literal be named but, if we decide down the road that we really, really need another version component, it wouldn't be a ton of work to give an exception when parsing an #if config. David

Re: [swift-evolution] Make non-void functions @warn_unused_result by default

> On 18 Dec 2015, at 23:23, Dave Abrahams wrote: >> >> I think a second method à la dropFirst/Last/... that returns Void would be >> better at communicating intent and allows pop() to retain the warning. > > Those are non-mutating methods that don’t return Void, FWIW.

Re: [swift-evolution] Readwrite reflection in Swift

I'm very interested in reflection in Swift. As Joe says, designing interfaces takes time, but since one of the goals of Swift 3 is to stabilize the ABI, and since the ABI might affect the ability to perform reflection operations, or at least their performance, it's important to work this out

Re: [swift-evolution] Make non-void functions @warn_unused_result by default

> On Dec 18, 2015, at 2:01 PM, Janosch Hildebrand via swift-evolution > wrote: > > I am also strongly in favor of this proposal. > > There are probably enough valid use cases for a @suppress_unused_warning but > personally I don't think pop() is a great example. >

Re: [swift-evolution] Proposal: Remove % operator for floating-point types

http://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/ > On 2015-12-19, at 4:17:45, Craig Cruden wrote: > > Floating point numbers by their very nature are

Re: [swift-evolution] Trial balloon: Ensure that String always contains valid Unicode

Er, typo in the first sentence! I meant to say: I was quite surprised to learn that it’s possible to create Swift strings that contain things other than valid Unicode characters. > On Dec 18, 2015, at 3:47 PM, Paul Cantrell via swift-evolution > wrote: > > I was

Re: [swift-evolution] Proposal: Python's indexing and slicing

> On Dec 18, 2015, at 1:46 PM, Joe Groff via swift-evolution > wrote: > >> >> On Dec 18, 2015, at 4:42 AM, Amir Michail via swift-evolution >> > wrote: >> >> Examples: >> >> >>> l=[1,2,3,4,5] >> >>>

Re: [swift-evolution] Proposal: Add .times method to Integer type

I agree with Radek. I find `for i in 5 { doSomething() }` or `for 5 { doSomething() }` to be very confusing since it is neither close to human language nor to any common programming language I know of. I like the idea of giving students a step by step introduction into things, but this is IMO

Re: [swift-evolution] Drafting a proposal: Make conflicting with protocol extension methods an error

> On Dec 18, 2015, at 5:38 PM, Brent Royal-Gordon > wrote: > >> I’m not sure how it affects your proposal, but I just want to point out that >> having things that are *only* statically dispatched is sometimes desirable. >> For example, Set equality is different from

Re: [swift-evolution] [Proposal] Property behaviors

> > > When do properties with behaviors get included in the memberwise >> initializer of structs or classes, if ever? Can properties with behaviors >> be initialized from init rather than with inline initializers? >> > There’s a separate discussion that mentioned allowing better control of >

Re: [swift-evolution] Proposal - Allow properties in Extensions

On Fri, Dec 18, 2015, at 05:45 PM, Joe Groff wrote: > >> On Dec 18, 2015, at 5:43 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote: >> >> On Fri, Dec 18, 2015, at 04:38 PM, John McCall wrote: On Dec 18, 2015, at 4:19 PM, Kevin Ballard wrote: On Fri, Dec

Re: [swift-evolution] [Pitch] Replace 'inout' with '&'

> On Dec 18, 2015, at 6:08 PM, Dmitri Gribenko wrote: > > On Fri, Dec 18, 2015 at 5:23 PM, Joe Groff via swift-evolution > > wrote: > For Swift 3, we're planning to phase out 'var' parameters in functions, and >

Re: [swift-evolution] Proposal - Allow properties in Extensions

On Dec 18, 2015, at 4:11 PM, John McCall via swift-evolution wrote: >> >> One potentially large downside is you can no longer look at a type >> declaration and find out how large it is. For example, I could define >> >> struct Foo { >> var x: Int >> } >> >> and

Re: [swift-evolution] [Review] Constraining AnySequence.init

Fair enough. I was thinking that it's better to err on the side of allowing flexibility, but there is something to be said for having slices of slices still be slices. My vague thought was that there might be some desire to have a slice be a type that wraps the thing being sliced, but I admit that

Re: [swift-evolution] [Review] Constraining AnySequence.init

On Fri, Dec 18, 2015 at 10:08 PM, Kevin Ballard wrote: > Well actually... > > LazyCollection right now has just this very behavior. The SubSequence of a > LazyCollection is a LazyCollection. If you say > `[1,2,3].lazy.prefixUpTo(3).prefixUpTo(3)` you end up with a >

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

Thanks for the clarification. Why is the compiler saying that the catch is not exhaustive when it is covering all the possible values of the enum? Is it to be able to catch future values added to the enum type? > On Dec 18, 2015, at 8:05 PM, David Owens II wrote: > > >>

Re: [swift-evolution] [Review] Require self for accessing instance members

I know I’m responding to myself here, but a couple more points: 1. I’ve programmed in Objective-C for many years, and I don’t feel like I’ve used “self” all that often. 2. If we do enforce self, method cascading would mitigate some of the repetition. -Kenny > On Dec 18, 2015, at 9:52 PM,

Re: [swift-evolution] [Pitch] Replace 'inout' with '&'

On Fri, Dec 18, 2015 at 5:23 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > For Swift 3, we're planning to phase out 'var' parameters in functions, > and we're also making it so that language keywords are valid argument > labels. With both of these changes pending, I have

Re: [swift-evolution] [Pitch] Replace 'inout' with '&'

> On Dec 18, 2015, at 5:23 PM, Joe Groff via swift-evolution > wrote: > > For Swift 3, we're planning to phase out 'var' parameters in functions, and > we're also making it so that language keywords are valid argument labels. > With both of these changes pending, I

Re: [swift-evolution] [Pitch] Replace 'inout' with '&'

> On Dec 18, 2015, at 5:30 PM, Joe Groff via swift-evolution > wrote: > > >> On Dec 18, 2015, at 5:27 PM, Matthew Johnson wrote: >> >> +1. Can you provide an example showing where you would place it though? > > Good question. Three

Re: [swift-evolution] RFC: Proposed rewrite of Unmanaged

I like `UnsafeReference` as the new name of the type and I think the basic API is clearer than with `Unmanaged`. The initializers are much better than the static methods and `take(Un)RetainedValue()` were certainly less than ideal method names. > On 18 Dec 2015, at 02:37, Dave Abrahams via

Re: [swift-evolution] [Review] Constraining AnySequence.init

Hi Kevin, Thank you for your feedback! On Fri, Dec 18, 2015 at 3:13 PM, Kevin Ballard via swift-evolution < swift-evolution@swift.org> wrote: > > 2. One of the added constraints looks like > > > S.SubSequence.SubSequence == S.SubSequence > > > with a comment saying that ideally the set of

Re: [swift-evolution] [Proposal Idea] dot shorthand for instance members

When you access a static member of a type using the dot shortcut, Swift evaluates the expression immediately. Are you proposing that when you access a member of an instance, Swift generate a closure? Or are you proposing that Swift generate a closure or not depending on how the expression's