Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

-1 It took awhile to catch up. I understand the motivation but don't agree with the solution. The suggested proposal adds language complexity that can hopefully be solved in other ways. In catching up I related to Howard Lovatt's response. Jordan responded: > On Dec 20, 2017, at 2:33 PM,

Re: [swift-evolution] Should we incorporate bunches of new operators / micro-syntactic sugar?

Ah, sorry, I misread! For readability I think I'd still favor something like: if let b = b { dict[a] = b } And I think some the arguments made in #0024 may still apply here, though feel free to discuss! Stephen > On Dec 21, 2017, at 1:37 PM, Benoit Pereira da silva

Re: [swift-evolution] Should we incorporate bunches of new operators / micro-syntactic sugar?

Such an operator was proposed here: https://github.com/apple/swift-evolution/blob/60a8980a66a0a1341871ec323797c5547d0e0925/proposals/0024-optional-value-setter.md It was ultimately rejected: https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/43.html Stephen > On Dec

Re: [swift-evolution] Optional Argument Chaining

> On Dec 11, 2017, at 1:08 PM, Matthew Johnson via swift-evolution > wrote: > > It’s worth mentioning that the problem this thread is discussing can be > generalized to idioms / applicative. The specific case here is for Optional > but many other types could

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 15, 2017, at 4:15 PM, David Hart via swift-evolution > wrote: > > I’m very much against a term like compactMap because it uses the term compact > which has no precedence in Swift’s Standard Library. I don’t really care what the name ends up being (as long

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0187: Introduce Sequence.filterMap(_:)

+1 > On Nov 7, 2017, at 6:23 PM, John McCall wrote: > > • What is your evaluation of the proposal? BJ summarized my thoughts nicely. I think “flatMap” in its current form is confusing to both newcomers and functional programmers familiar with the nomenclature. I’ve

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 9, 2017, at 1:17 PM, Gor Gyolchanyan via swift-evolution > wrote: > > Yes, except why would you need to define `((A, B)) -> C`?, If you need to > pass a 2-element tuple into a function that takes two parameters - you can! > If you want to pass two values

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

eated as a block. Ruby calls a to_proc method on whatever is in > that position. Symbol implements to_proc by returning a lambda that calls the > method named by the symbol on the lambda’s first arg. Very much the > duck-typed version of TransformConvertible above. > > >> On Ju

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

-1 A -1 from me may be surprising. I'm excited about key path composition and generic solutions, e.g. this experiment with lenses: https://twitter.com/stephencelis/status/863916921577758721 But I'd prefer a reusable solution for converting key paths into functions. Heaven help me for this

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> On Jun 7, 2017, at 10:33 PM, Xiaodi Wu via swift-evolution > wrote: > > However, what I don’t get is why you’d have a mismatch here. Your method > `first` accepts a closure, and surely the type it expects should be > `((String, Conversation)) -> Bool` instead,

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> On Jun 7, 2017, at 8:27 AM, Xiaodi Wu wrote: > > Swift package descriptions make extensive use of enums. For example, > .target(...) is an enum case with an associated value, unless I’m mistaken. I > too got the order of “dependencies” and “path” reversed the other day;

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> On Jun 7, 2017, at 2:01 AM, Xiaodi Wu wrote: > > Those are enums, which were aligned with argument lists instead of tuples in > yet another proposal, SE-0155. Can you clarify? I wasn't referring to enums, and SE-0155 starts by talking about single enum cases with

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> On Jun 7, 2017, at 1:05 AM, Xiaodi Wu wrote: > > This is not what was meant during discussion about re-evaluating SE-0110. > Tuples already behave as described, but function argument lists are not > tuples and have not been for a very long time: see SE-0029, SE-0066. >

Re: [swift-evolution] Proposal: Always flatten the single element tuple

The inline cases make sense to me, but my concern for ambiguity are because we can define both of these functions: func add1(_ x: Int, _ y: Int) -> Int { return x + y } func add2(_ pair: (Int, Int)) -> Int { return pair.0 + pair.1 } // What's the behavior here?

Re: [swift-evolution] Proposal: Always flatten the single element tuple

I like this a lot, but how do we solve for the function case? func add(_ x: Int, _ y: Int) -> Int { return x + y } [(1, 2)].map(add) Where does `map` with a function of `((Int, Int)) -> Int` fit in? > On Jun 6, 2017, at 10:15 PM, Susan Cheng via swift-evolution >

Re: [swift-evolution] Revisiting SE-0110

> On Jun 6, 2017, at 8:19 PM, Mark Lacey wrote: > > Thanks for reminding me. It’s good to call out this case specifically. The > underlying reason that this is disallowed for Swift 4 is the same as the > underlying reason that a closure immediately passed as an argument

Re: [swift-evolution] Revisiting SE-0110

> On Jun 6, 2017, at 1:43 PM, Mark Lacey via swift-evolution > wrote: > > Unless I am missing something this is an example of tuple destructuring. I’m > looking for examples of other issues. The destructuring issue is the most pervasive, but as mentioned it also

Re: [swift-evolution] Revisiting SE-0110

> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution > wrote: > > Yes, I agree. We need to add back tuple destructuring in closure parameter > lists because this is a serious usability regression. If we're reluctant to > just "do the right thing" to

[swift-evolution] Pitch: Even Smarter KeyPaths?

I've started to explore Smart KeyPaths in the latest Swift Development Snapshot with regard to lenses and have been pleasantly surprised: Swift has one of the better out-of-box optics stories I've come across! In (brief) use I've come across a few gaps that I was hoping we could fill in. ##

Re: [swift-evolution] Generic Subscripts

> On Jan 10, 2017, at 2:40 PM, Douglas Gregor via swift-evolution > wrote: > > It’s a nontrivial new user-facing feature with new syntax in the language, so > it’ll need a proposal. ‘twould be good for the proposal to link to the JIRA > ticket. > > - Doug I

Re: [swift-evolution] Changing the curried static methods

> On Mar 14, 2016, at 1:09 PM, Joe Groff via swift-evolution > wrote: > > Note that there's a proposal open to flatten away the currying altogether: > > https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md > > I agree that it

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 27, 2015, at 3:32 PM, Joe Groff via swift-evolution > wrote: > > Some more things to consider: > > - Our naming conventions encourage the first parameter to most methods to be > unlabeled, so unlabeled parameters come up a lot. I don't think there's a >

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 28, 2015, at 11:47 AM, Alex Migicovsky via swift-evolution > wrote: >> On Dec 27, 2015, at 1:32 PM, Joe Groff via swift-evolution >> > wrote: >> >> Some more things to consider: >> >> - Our naming

Re: [swift-evolution] Final by default for classes and methods

> On Dec 23, 2015, at 1:06 PM, Tino Heth <2...@gmx.de> wrote: > >>> "If I don't want to subclass something, I just don't do it — why do I have >>> to change the properties of the superclass?" >> >> Fix-its solve this with a single click. > Really? I guess I like this alternate reality — can the

Re: [swift-evolution] Final by default for classes and methods

> On Dec 23, 2015, at 12:25 PM, Tino Heth via swift-evolution > wrote: > > I also would change the list of downsides and put "annoyance" on top — > especially for those who don't care for theoretical improvement when they > have to pay the price in form of more

Re: [swift-evolution] Mixins

I remember reading another thread (the associated/typealias renaming discussion) where an Apple engineer wrote that this limitation is temporary and that functions should be definable directly in a protocol. If that's the case, this may just be a bug and not have to go through evolution.

Re: [swift-evolution] Mixins

You can search https://bugs.swift.org and see if a bug has already been filed. If not, file one :) Stephen > On Dec 23, 2015, at 3:06 PM, James Campbell wrote: > > We should get this as a proposal in. That case so it doesn't slip off the > radar if that is the case > >

Re: [swift-evolution] Proposal: Make braces optional much like semicolons.

There was a thread for this posted yesterday: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003631.html Stephen > On Dec 20, 2015, at 10:17 AM, Amir Michail via swift-evolution > wrote: > > // braces are optional here but you could still

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> On Dec 19, 2015, at 11:14 PM, Dave Abrahams via swift-evolution > wrote: > >> On Dec 19, 2015, at 5:09 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >> I don't think `required` captures the intended meaning *at all*. You're

Re: [swift-evolution] Proposal: Make braces optional much like semicolons.

> On Dec 20, 2015, at 10:54 AM, Amir Michail wrote: > > Much of that discussion doesn’t consider the possibility of making braces > OPTIONAL as shown in the examples. Sure. This is a point you could have made in that discussion. I think in general the preference is to reply