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

[Benjamin Spratling via swift-evolution]

Howdy,
I love it!  The “do" blocks never did “feel” like Swift.  I can see how 
both would be useful.
I like to use as many conditionals in a single guard statement as I can 
get away with, so I was concerned that guard/catch would need to interoperate 
with guard/else.  However, I am fairly convinced that, at least for now, having 
to choose between guard /catch and guard /else is not that much of a problem.  
guard/catch appears optimized for the simple-call case, where there is a single 
throwing expression, so the code can handle its specific error/s more 
precisely.  When catching anything in a batch is the goal, then a do block is 
probably fine.
-Ben

> On Jul 5, 2017, at 1:30 PM, Soroush Khanlou via swift-evolution 
>  wrote:
> 
> I’d like to propose a guard/catch construct to the language. It would allow 
> code to use throwing functions and handle errors fully, without straying from 
> a happy path. do/catch can be a bit heavy-handed sometimes, and it would be 
> nice to be able to handle throwing functions without committing to all the 
> nesting and ceremony of do/catch.
> 
> Full proposal, which discusses all the corner cases and alternatives:
> https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9 
> 
> 
> Looking forward to feedback!
> 
> Soroush
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Zach Waldowski via swift-evolution]

I second Xiaodi on this. The syntax feels like a slam-dunk. The only
concerns I have are indentation, and ultimately that's not my problem to
decide about. ;)
Sincerely,
  Zachary Waldowski
  z...@waldowski.me

On Wed, Jul 5, 2017, at 07:15 PM, Xiaodi Wu via swift-evolution wrote:
> Initially, this proposal felt a little off, but on re-reading, I think
> I like it very much. It shows that guard/catch is meant to solve a
> nesting problem (just like guard/else was meant to solve one), and it
> preserves the idea that the else/catch clause must exit the outer
> scope, which is very important to the meaning of `guard`.> 
> I agree with the proposal authors that mix-and-match guard/catch/else
> feels unwise. I see no reason why rewriting to repeat only the word
> `guard` (as in, `guard A catch { }; guard B else { }` instead of
> `guard A, B catch { } else { }`) is onerous enough to justify a syntax
> that is clearly harder to reason about.> 
> On Wed, Jul 5, 2017 at 2:25 PM, Soroush Khanlou via swift-evolution
>  wrote:>> Jon — we explored allowing users to mix 
> and match optional unwrapping
>> and error catching in the same guard, but found that it was
>> ultimately pretty confusing. We think that guard/else and guard/catch
>> should be two totally different components. Dave’s email lays out the
>> two best approaches, and the “Alternatives Considered” section of the
>> proposal goes into why those alternatives were ultimately rejected.>> 
>>> On Jul 5, 2017, at 2:09 PM, Dave DeLong via swift-evolution >> evolut...@swift.org> wrote:>>> 
>>> Soroush’s proposal has the idea that maybe we could do multiple
>>> blocks for this scenario, like so:>>> 
>>> guard try something(), let thing = optionalThing catch {
>>> // try something() failed
>>> } else {
>>> // the let-binding failed
>>> }
>>> 
>>> 樂 Alternatively, what if the “error” captured was optional in this
>>> scenario?>>> 
>>> guard try something(), let thing = optionalThing catch {
>>> if let error = error {
>>> // the try call failed
>>> } else {
>>> // the optional binding failed
>>> }
>>> }
>>> 
>>> Dave
>>> 
 On Jul 5, 2017, at 12:00 PM, Jon Shier via swift-evolution >>> evolut...@swift.org> wrote: 
 I didn’t think I was going to like it but I really do. My only
 concern, which isn’t really a deal breaker, is what it would look
 like to chain multiple try and let statement in the same guard.
 Unless that scenario works well I don’t think you could convince
 others. i.e. In the case where I have: 
 guard try something(), let thing = optionalThing catch { }
 
 What happens when the let fails? No implicit error?
 
 
 
 Jon
 
 
> On Jul 5, 2017, at 1:30 PM, Soroush Khanlou via swift-evolution
>  wrote:> 
> I’d like to propose a guard/catch construct to the language. It
> would allow code to use throwing functions and handle errors
> fully, without straying from a happy path. do/catch can be a bit
> heavy-handed sometimes, and it would be nice to be able to handle
> throwing functions without committing to all the nesting and
> ceremony of do/catch.> 
> Full proposal, which discusses all the corner cases and
> alternatives:> 
> https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9
> 
> Looking forward to feedback!
> 
> Soroush
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> ___
>>  swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> _
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

My initial reaction when this idea was floated was positive, but after Dave
and others' astute observations, I have come to the same opinion as him.
Namely, it seems hard to justify adding an overload that's purely syntactic
sugar, multiplying the number of ways to express the same thing, for a
result where the increase in readability is debatable.

Agree also that _if_ this is worthwhile, then keypaths as a subtype of the
corresponding function type would be the best way to go.


On Wed, Jul 5, 2017 at 4:23 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Wed Jul 05 2017, Benjamin Herzog  wrote:
>
> > Hey guys,
> >
> > I would like to pitch a small convenient change to the Swift stdlib.
> > With KeyPaths added in SE-0161 I would like to add some convenience
> > calls to map, flatMap and filter in Sequences. To extract properties of
> > an array of objects we currently use trailing closure syntax together
> > with the shorthand $0 for the first closure argument. This is still kind
> > of verbose and also hard to read in some situations.I think it is much
> better to understand what is
> > going on when using the
> > type safe KeyPaths for that. I already implemented a working solution
> > and would like to pitch the idea here to get some feedback before
> > opening the swift evolution proposal.I propose using
> >
> > persons.flatMap(keyPath: \.name)
> >
> > over
> >
> > persons.flatMap { $0.name }
> >
> > Link to pull request: https://github.com/apple/swift/pull/10760
>
> Repeating my earlier response to this idea:
>
> I am not convinced this syntactic sugar is worth complicating the
> language or library for, but if it is, IMO the right thing is to make a
> keypath be-a subtype of the appropriate function type, rather than to
> start down the path of creating a keypath overload for every method that
> takes a closure argument.
>
> --
> -Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

Initially, this proposal felt a little off, but on re-reading, I think I
like it very much. It shows that guard/catch is meant to solve a nesting
problem (just like guard/else was meant to solve one), and it preserves the
idea that the else/catch clause must exit the outer scope, which is very
important to the meaning of `guard`.

I agree with the proposal authors that mix-and-match guard/catch/else feels
unwise. I see no reason why rewriting to repeat only the word `guard` (as
in, `guard A catch { }; guard B else { }` instead of `guard A, B catch { }
else { }`) is onerous enough to justify a syntax that is clearly harder to
reason about.

On Wed, Jul 5, 2017 at 2:25 PM, Soroush Khanlou via swift-evolution <
swift-evolution@swift.org> wrote:

> Jon — we explored allowing users to mix and match optional unwrapping and
> error catching in the same guard, but found that it was ultimately pretty
> confusing. We think that guard/else and guard/catch should be two totally
> different components. Dave’s email lays out the two best approaches, and
> the “Alternatives Considered” section of the proposal goes into why those
> alternatives were ultimately rejected.
>
> On Jul 5, 2017, at 2:09 PM, Dave DeLong via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Soroush’s proposal has the idea that maybe we could do multiple blocks for
> this scenario, like so:
>
> guard try something(), let thing = optionalThing catch {
> // try something() failed
> } else {
> // the let-binding failed
> }
>
> 樂 Alternatively, what if the “error” captured was optional in this
> scenario?
>
> guard try something(), let thing = optionalThing catch {
> if let error = error {
> // the try call failed
> } else {
> // the optional binding failed
> }
> }
>
> Dave
>
> On Jul 5, 2017, at 12:00 PM, Jon Shier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I didn’t think I was going to like it but I really do. My only concern,
> which isn’t really a deal breaker, is what it would look like to chain
> multiple try and let statement in the same guard. Unless that scenario
> works well I don’t think you could convince others. i.e. In the case where
> I have:
>
> guard try something(), let thing = optionalThing catch { }
>
> What happens when the let fails? No implicit error?
>
>
>
> Jon
>
>
> On Jul 5, 2017, at 1:30 PM, Soroush Khanlou via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’d like to propose a guard/catch construct to the language. It would
> allow code to use throwing functions and handle errors fully, without
> straying from a happy path. do/catch can be a bit heavy-handed sometimes,
> and it would be nice to be able to handle throwing functions without
> committing to all the nesting and ceremony of do/catch.
>
> Full proposal, which discusses all the corner cases and alternatives:
> https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9
>
> Looking forward to feedback!
>
> Soroush
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Wed Jul 05 2017, Benjamin Herzog  wrote:

> Hey guys,
>
> I would like to pitch a small convenient change to the Swift stdlib.
> With KeyPaths added in SE-0161 I would like to add some convenience
> calls to map, flatMap and filter in Sequences. To extract properties of
> an array of objects we currently use trailing closure syntax together
> with the shorthand $0 for the first closure argument. This is still kind
> of verbose and also hard to read in some situations.I think it is much better 
> to understand what is
> going on when using the
> type safe KeyPaths for that. I already implemented a working solution
> and would like to pitch the idea here to get some feedback before
> opening the swift evolution proposal.I propose using 
>
> persons.flatMap(keyPath: \.name)
>
> over
>
> persons.flatMap { $0.name }
>
> Link to pull request: https://github.com/apple/swift/pull/10760

Repeating my earlier response to this idea:

I am not convinced this syntactic sugar is worth complicating the
language or library for, but if it is, IMO the right thing is to make a
keypath be-a subtype of the appropriate function type, rather than to
start down the path of creating a keypath overload for every method that
takes a closure argument.

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Soroush Khanlou via swift-evolution]

Jon — we explored allowing users to mix and match optional unwrapping and error 
catching in the same guard, but found that it was ultimately pretty confusing. 
We think that guard/else and guard/catch should be two totally different 
components. Dave’s email lays out the two best approaches, and the 
“Alternatives Considered” section of the proposal goes into why those 
alternatives were ultimately rejected.

> On Jul 5, 2017, at 2:09 PM, Dave DeLong via swift-evolution 
>  wrote:
> 
> Soroush’s proposal has the idea that maybe we could do multiple blocks for 
> this scenario, like so:
> 
> guard try something(), let thing = optionalThing catch {
> // try something() failed
> } else {
> // the let-binding failed
> }
> 
> 樂 Alternatively, what if the “error” captured was optional in this scenario?
> 
> guard try something(), let thing = optionalThing catch {
> if let error = error {
> // the try call failed
> } else {
> // the optional binding failed
> }
> }
> 
> Dave
> 
>> On Jul 5, 2017, at 12:00 PM, Jon Shier via swift-evolution 
>> > wrote:
>> 
>>  I didn’t think I was going to like it but I really do. My only concern, 
>> which isn’t really a deal breaker, is what it would look like to chain 
>> multiple try and let statement in the same guard. Unless that scenario works 
>> well I don’t think you could convince others. i.e. In the case where I have:
>> 
>> guard try something(), let thing = optionalThing catch { }
>> 
>> What happens when the let fails? No implicit error?
>> 
>> 
>> 
>> Jon
>> 
>> 
>>> On Jul 5, 2017, at 1:30 PM, Soroush Khanlou via swift-evolution 
>>> > wrote:
>>> 
>>> I’d like to propose a guard/catch construct to the language. It would allow 
>>> code to use throwing functions and handle errors fully, without straying 
>>> from a happy path. do/catch can be a bit heavy-handed sometimes, and it 
>>> would be nice to be able to handle throwing functions without committing to 
>>> all the nesting and ceremony of do/catch.
>>> 
>>> Full proposal, which discusses all the corner cases and alternatives:
>>> https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9 
>>> 
>>> 
>>> Looking forward to feedback!
>>> 
>>> Soroush
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

[David Moore via swift-evolution]

The example you presented – whilst utilizing a potential syntactical expression 
– seems like a step in the right direction. Specifically, I like the addition 
of a keyword as it introduces a more explicit invocation of the behavior.

Moreover, it does seem only natural to allow the re-mapping to occur for most 
(if not all) definitions between a protocol and the conforming type. I also 
agree that this feature would be a more advanced one, which does not need to be 
exposed for cases where this is not needed.

I would also propose a slight adjustment to the syntax, albeit in a rugged 
form, to add the type annotation to the right hand side as well. E.g. remapped 
var P.f = S.g.

If the above were to be respected, then the overall functionality of this could 
be expanded greatly, but it’d have to be seen how it would affect the 
implementation. To clarify, if we added the type annotation to the right side 
too, we may theoretically be able to change the type from the enclosing type to 
some arbitrary type and its conforming requirement. Now, if this seems a bit 
too polymorphic the compiler could just emit an error which restricts the type 
annotation to the enclosing type.

Best,
David Moore

On Jul 5, 2017, 1:53 PM -0400, Chris Lattner , wrote:
>
> > On Jun 27, 2017, at 2:26 PM, David Moore via swift-evolution 
> >  wrote:
> >
> >
> > Onto Option #2, the idea of using base types to express more explicit 
> > definitions to solve the initial problem. When it comes to using a base 
> > type to correctly disambiguate these types of situations, it may be 
> > familiar to some who like a more concrete implementation, although it 
> > eliminates possible convenience, but still requires knowledge. Options #2 
> > would look something like the following.
> >
> > protocol Foo {
> >  associatedtype ABC
> > }
> >
> > struct Bar: Foo {
> >  typealias Foo.ABC = Bar.ABC // Quite explicit and communicates the 
> > solution clearly.
> > }
> >
> > Options #2, as you can see above, would also be source compatible because 
> > it would not impose on already defined typealias’ or other implementations. 
> > This could be an opt-in feature. However, I don’t know if it is as nice as 
> > just pure inference, which doesn’t seem too much more difficult than this 
> > would be, but I’m not sure about that.
> >
>
> Something like this seems like the right approach to me.  Swift’s underlying 
> implementation model (for non-@objc protocols) does not require exact name 
> matches and uniqueness.  This means that (from an implementation perspective) 
> it would be possible to allow “remapping” of requirements to implementations, 
> even if they have different (or conflicting) names.
>
> This can be useful in some cases, like the one you give above.  That said, it 
> would be a power user feature only necessary in specific situations, and thus 
> it makes sense to have super explicit syntax.  Given that remapping can apply 
> to any requirement (be it a type, method, property, subscript, …) it may make 
> sense to make it an explicit decl modifier like:
>
>   protocol P {
>     var x : Int
>     func f() -> Int
>   }
>
>   struct S : P {
>     var y : Int
>     remapped var P.x = y
>
>     func g() -> Int { return 42 }
>     remapped var P.f = g
>   }
>
> or something.
>
> -Chris
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Beta via swift-evolution]

> On Jul 5, 2017, at 10:30 AM, Soroush Khanlou via swift-evolution 
>  wrote:
> 
> I’d like to propose a guard/catch construct to the language. It would allow 
> code to use throwing functions and handle errors fully, without straying from 
> a happy path. do/catch can be a bit heavy-handed sometimes, and it would be 
> nice to be able to handle throwing functions without committing to all the 
> nesting and ceremony of do/catch.
> 

The nesting and ceremony, to me, were part of Swift’s philosophy of making 
error handling explicit.  Merging catch blocks into guards saves you maybe 3-10 
lines if you intended to actually handle the error(s), otherwise this 
effectively try?’s  into a failable pattern match.  At which point, you have to 
wonder if the error-throwing function you wrote wouldn’t be better off just 
returning an Optional if you’re going to discard the semantic content of the 
error.

~Robert Widmann

> Full proposal, which discusses all the corner cases and alternatives:
> https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9 
> 
> 
> Looking forward to feedback!
> 
> Soroush
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave DeLong via swift-evolution]

Soroush’s proposal has the idea that maybe we could do multiple blocks for this 
scenario, like so:

guard try something(), let thing = optionalThing catch {
// try something() failed
} else {
// the let-binding failed
}

樂 Alternatively, what if the “error” captured was optional in this scenario?

guard try something(), let thing = optionalThing catch {
if let error = error {
// the try call failed
} else {
// the optional binding failed
}
}

Dave

> On Jul 5, 2017, at 12:00 PM, Jon Shier via swift-evolution 
>  wrote:
> 
>   I didn’t think I was going to like it but I really do. My only concern, 
> which isn’t really a deal breaker, is what it would look like to chain 
> multiple try and let statement in the same guard. Unless that scenario works 
> well I don’t think you could convince others. i.e. In the case where I have:
> 
> guard try something(), let thing = optionalThing catch { }
> 
> What happens when the let fails? No implicit error?
> 
> 
> 
> Jon
> 
> 
>> On Jul 5, 2017, at 1:30 PM, Soroush Khanlou via swift-evolution 
>> > wrote:
>> 
>> I’d like to propose a guard/catch construct to the language. It would allow 
>> code to use throwing functions and handle errors fully, without straying 
>> from a happy path. do/catch can be a bit heavy-handed sometimes, and it 
>> would be nice to be able to handle throwing functions without committing to 
>> all the nesting and ceremony of do/catch.
>> 
>> Full proposal, which discusses all the corner cases and alternatives:
>> https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9 
>> 
>> 
>> Looking forward to feedback!
>> 
>> Soroush
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

[Chris Lattner via swift-evolution]

> On Jun 27, 2017, at 2:26 PM, David Moore via swift-evolution 
>  wrote:
> 
> 
> Onto Option #2, the idea of using base types to express more explicit 
> definitions to solve the initial problem. When it comes to using a base type 
> to correctly disambiguate these types of situations, it may be familiar to 
> some who like a more concrete implementation, although it eliminates possible 
> convenience, but still requires knowledge. Options #2 would look something 
> like the following.
> 
> protocol Foo {
>  associatedtype ABC
> }
> 
> struct Bar: Foo {
>  typealias Foo.ABC = Bar.ABC // Quite explicit and communicates the solution 
> clearly.
> }
> 
> Options #2, as you can see above, would also be source compatible because it 
> would not impose on already defined typealias’ or other implementations. This 
> could be an opt-in feature. However, I don’t know if it is as nice as just 
> pure inference, which doesn’t seem too much more difficult than this would 
> be, but I’m not sure about that.
> 

Something like this seems like the right approach to me.  Swift’s underlying 
implementation model (for non-@objc protocols) does not require exact name 
matches and uniqueness.  This means that (from an implementation perspective) 
it would be possible to allow “remapping” of requirements to implementations, 
even if they have different (or conflicting) names.

This can be useful in some cases, like the one you give above.  That said, it 
would be a power user feature only necessary in specific situations, and thus 
it makes sense to have super explicit syntax.  Given that remapping can apply 
to any requirement (be it a type, method, property, subscript, …) it may make 
sense to make it an explicit decl modifier like:

  protocol P {
var x : Int
func f() -> Int
  }

  struct S : P {
var y : Int
remapped var P.x = y

func g() -> Int { return 42 }
remapped var P.f = g
  }

or something.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jon Shier via swift-evolution]

I didn’t think I was going to like it but I really do. My only concern, 
which isn’t really a deal breaker, is what it would look like to chain multiple 
try and let statement in the same guard. Unless that scenario works well I 
don’t think you could convince others. i.e. In the case where I have:

guard try something(), let thing = optionalThing catch { }

What happens when the let fails? No implicit error?



Jon


> On Jul 5, 2017, at 1:30 PM, Soroush Khanlou via swift-evolution 
>  wrote:
> 
> I’d like to propose a guard/catch construct to the language. It would allow 
> code to use throwing functions and handle errors fully, without straying from 
> a happy path. do/catch can be a bit heavy-handed sometimes, and it would be 
> nice to be able to handle throwing functions without committing to all the 
> nesting and ceremony of do/catch.
> 
> Full proposal, which discusses all the corner cases and alternatives:
> https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9 
> 
> 
> Looking forward to feedback!
> 
> Soroush
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jacob Bandes-Storch via swift-evolution]

Some prior, probably not as well thought-through, discussion on this topic:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011446.html
On Wed, Jul 5, 2017 at 10:40 AM Soroush Khanlou via swift-evolution <
swift-evolution@swift.org> wrote:

> I’d like to propose a guard/catch construct to the language. It would
> allow code to use throwing functions and handle errors fully, without
> straying from a happy path. do/catch can be a bit heavy-handed sometimes,
> and it would be nice to be able to handle throwing functions without
> committing to all the nesting and ceremony of do/catch.
>
> Full proposal, which discusses all the corner cases and alternatives:
> https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9
>
> Looking forward to feedback!
>
> Soroush
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Guard/Catch

[Soroush Khanlou via swift-evolution]

I’d like to propose a guard/catch construct to the language. It would allow 
code to use throwing functions and handle errors fully, without straying from a 
happy path. do/catch can be a bit heavy-handed sometimes, and it would be nice 
to be able to handle throwing functions without committing to all the nesting 
and ceremony of do/catch.

Full proposal, which discusses all the corner cases and alternatives:
https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9 


Looking forward to feedback!

Soroush___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Benjamin Herzog via swift-evolution]

Hey guys,

I would like to pitch a small convenient change to the Swift stdlib.
With KeyPaths added in SE-0161 I would like to add some convenience
calls to map, flatMap and filter in Sequences. To extract properties of
an array of objects we currently use trailing closure syntax together
with the shorthand $0 for the first closure argument. This is still kind
of verbose and also hard to read in some situations.I think it is much better 
to understand what is going on when using the
type safe KeyPaths for that. I already implemented a working solution
and would like to pitch the idea here to get some feedback before
opening the swift evolution proposal.I propose using 

persons.flatMap(keyPath: \.name)

over

persons.flatMap { $0.name }

Link to pull request: https://github.com/apple/swift/pull/10760

Link to proposal draft:
https://github.com/BenchR267/swift-evolution/blob/keypath-based-map/proposals/0181-keypath-based-map-flatmap-filter.md
Thanks in advance for your feedback!
__

Benjamin Herzog

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Request for information about constrained protocol inheritance

[Alex Martini via swift-evolution]

Since you mentioned not finding documentation, here's the new section in "The 
Swift Programming Language":

Associated Types with a Generic Where Clause

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Generics.html#//apple_ref/doc/uid/TP40014097-CH26-ID557

> On Jul 4, 2017, at 10:53 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Replying to swift-users as well, as it's probably the more appropriate forum.
> 
> SE-0142 (Permit where clauses to constrain associated types) is what brought 
> about this feature. It is now used in the standard library.
> 
> 
> On Wed, Jul 5, 2017 at 00:26 Jens Persson via swift-evolution 
>  wrote:
> The following compiles in Swift 4 (but not in Swift 3.1):
> 
> protocol P1 {
> associatedtype A
> }
> protocol P2 : P1 where A == Int {
> }
> 
> I've not been able to find any proposal, discussion or documentation 
> mentioning it so any pointers to such would be greatly appreciated.
> 
> Also, is this new feature used somewhere in the std lib?
> 
> /Jens
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution