Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

Just realized that even inout functions don’t let you do member(object) = value. So you’re right, the write access does make keypaths more like subscripts. But when restricted to read-only access, they are identical to (non-inout) functions and so it does seem natural to be able to use them as

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

Sure, but you could just as easily call a keypath “a thing that gives you read+write access to one of an object’s members”. Sounds like an inout function to me. The difference being that in general an inout function *can* do a lot more than just give access to a single member of a base object.

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

on Tue Jul 11 2017, Robert Bennett wrote: > Er, yes, I now realize I diverged into two different keypaths-as-functions > ideas there. > > I think that the best implementation of deferred access is keypaths as > callable first-class objects, like you (Karl) said. —

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

Er, yes, I now realize I diverged into two different keypaths-as-functions ideas there. I think that the best implementation of deferred access is keypaths as callable first-class objects, like you (Karl) said. — although I wonder whether callability should be restricted to KeyPath, or

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

> On 12. Jul 2017, at 01:20, Robert Bennett wrote: > > Well, if they really are first-class deferred method calls or member > accesses, then do seem pretty function-y after all. Then again, if they were > meant to be functions, it seems like their design would reflect

Re: [swift-evolution] [Rejected] SE-0030 Property Behaviors

> On 11. Jul 2017, at 17:41, Wallacy via swift-evolution > wrote: > > When will be a good time to discuss this proposal again? I think Apple's usual policy is that Swift 4 will ship with iOS 11 (so end of September, I think). Then they have a break, and sometime

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

Well, if they really are first-class deferred method calls or member accesses, then do seem pretty function-y after all. Then again, if they were meant to be functions, it seems like their design would reflect that – instead of being used like subscripts, they would be called like functions,

Re: [swift-evolution] [Pre-pitch] Allowing enums inside protocols?

> On 9. Jul 2017, at 06:06, Xiaodi Wu via swift-evolution > wrote: > > On Sat, Jul 8, 2017 at 10:52 PM, Jonathan Hull > wrote: > Do you know why it was never brought to a vote? > > If I had to guess, it would be because

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

> On 11. Jul 2017, at 21:01, Robert Bennett via swift-evolution > wrote: > > In general, I like the idea of making ordinary types callable (although > curried functions already accomplish this to some extent), but I hesitate to > bring this capability to keypaths

Re: [swift-evolution] [Pitch] BitPatternRepresentable

on Tue Jul 11 2017, Jens Persson wrote: > I've found it practical/necessary to write my own BitPatternRepresentable > protocol and IMHO it feels like something that could have been added along > with the improved numeric protocols of Swift 4. > > Would it make sense

Re: [swift-evolution] [Request for Feedback] Providing defaults for reading and writing.

You’re right, my current implementation doesn’t win anything over what you’re written - in fact your technique is basically what I wrote at first. I was trying to work towards encapsulating the behavior in the encoder/decoder so that the automatic init/encode methods could work, so I wanted to

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

In general, I like the idea of making ordinary types callable (although curried functions already accomplish this to some extent), but I hesitate to bring this capability to keypaths because, well, they don’t really feel like functions; I think the point of them is that they work like

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

I still think using an operator for this conversation would neither increase readability nor transparency. I think my mail on Sunday was lost, so I paste the content here again. It referred to a suggestion to create a possibility for KeyPath to act as a function which would bring other benefits

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

This is also the case for $0, although I suppose that since $0 is only valid inside a closure, LLDB has some context with which to disambiguate Swift’s $0 from LLDB’s, context it wouldn’t have with $keyPath. That said, there are probably solutions to this, like requiring a backslash before a

[swift-evolution] [Review] SE-0181: Package Manager C/C++ Language Standard Support

Hello Swift community, The review of SE-0181: Package Manager C/C++ Language Standard Support begins now and runs through July 14th, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0181-package-manager-cpp-language-version.md Reviews are

Re: [swift-evolution] [Request for Feedback] Providing defaults for reading and writing.

Hi Wil, Thanks for putting this together! My biggest thought on this is — what does this provide that you can’t already do yourself today? Since you have to go through the work to put together default values and override `init(from:)` and `encode(to:)` to use them, I’m wondering whether this

[swift-evolution] Fwd: [Pitch] Guard/Catch

Begin forwarded message: From: Christopher Kornher Subject: Re: [swift-evolution] [Pitch] Guard/Catch Date: July 10, 2017 at 5:10:15 PM MDT To: Elviro Rocca This messages was modified from the original accidentally sent out privately,

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

‘$' as a prefix is reserved for use by the debugger, so it cannot be used as a conversion operator here. -BJ > On Jul 11, 2017, at 10:12 AM, Robert Bennett via swift-evolution > wrote: > > It seems that there is some consensus that the proper way to achieve this is

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

It seems that there is some consensus that the proper way to achieve this is not to overload map et al. but to provide a way to convert KeyPath to a function. I agree – not only is this “cheaper”, as overloads of these functions will not need to be written, but it’s also more general and may

Re: [swift-evolution] [Rejected] SE-0030 Property Behaviors

When will be a good time to discuss this proposal again? Em qua, 24 de fev de 2016 às 04:14, Douglas Gregor via swift-evolution < swift-evolution@swift.org> escreveu: > The review of SE-0030 “Property Behaviors” ran from February 10...23, > 2016. The proposal in its current form is *rejected*:

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

Overloads are ugly. The very existence of an overloaded function usually means a lack of available abstractions, or an insufficient abstraction power in the language: exhibit A is conditional conformances to protocols. Overloads are particularly ugly if the overloaded function's input

[swift-evolution] [Pitch] BitPatternRepresentable

I've found it practical/necessary to write my own BitPatternRepresentable protocol and IMHO it feels like something that could have been added along with the improved numeric protocols of Swift 4. Would it make sense to add something like the following to the standard library? /// A type that

Re: [swift-evolution] [Pitch] BitPatternRepresentable

Oh, I forgot the signed IntN types: extension Int8 : BitPatternRepresentable { var bitPattern: UInt8 { return UInt8(bitPattern: self) } init(bitPattern: UInt8) { self = Int8(bitPattern: bitPattern) } } extension Int16 : BitPatternRepresentable { var bitPattern: UInt16 { return

Re: [swift-evolution] [Pitch] Guard/Catch

Not sure what you mean here. A guard/catch would allow me to handle the error in the catch, something that (of course) cannot be done with "try?", so guard/else with "try?" is not a solution. And of course returning in the catch side of a do/catch is like returning in the else side of a