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 
> <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 <mailto: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 <mailto: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 
>>> <https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9>
>>> 
>>> Looking forward to feedback!
>>> 
>>> Soroush
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto: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] [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] Add an all algorithm to Sequence

[Soroush Khanlou via swift-evolution]

I really like this proposal. This is one of the first extensions I add to a new 
Swift project. I think if we’re going to add `all`, we should consider adding 
`none` as well. `none` can be used currently as `!contains`, but sometimes 
boolean logic like that can be hard to follow.

Soroush

> Hi,
> 
> A short proposal for you as part of the algorithms theme. Hopefully 
> non-controversial, aside from the naming of the method and arguments, about 
> which controversy abounds. Online copy 
> here:https://github.com/airspeedswift/swift-evolution/blob/9a778e904c9be8a3692edd19bb757b23c54aacbe/proposals/0162-all-algorithm.md
> 
> 
> Add anallalgorithm toSequence
> Proposal:SE-(file:///Users/ben_cohen/Documents/swift-evolution/proposals/0162-all-algorithm.md)
> Authors:Ben Cohen(https://github.com/airspeedswift)
> Review Manager: TBD
> Status:Awaiting review
> 
> Introduction
> 
> It is common to want to confirm that every element of a sequence equals a 
> value, or matches a certain criteria. Many implementations of this can be 
> found in use on github. This proposal adds such a method toSequence.
> 
> Motivation
> 
> You can achieve this in Swift 3 withcontainsby negating both the criteria and 
> the result:
> 
> // every element is 9!nums.contains{ $0!=9}// every element is 
> odd!nums.contains{ !isOdd($0) }
> 
> but these are a readability nightmare. Additionally, developers may not make 
> the leap to realizecontainscan be used this way, so may hand-roll their 
> ownforloop, which could be buggy, or compose other inefficient alternatives:
> 
> // misses opportunity to bail earlynums.reduce(true) { $0.0&&$0.1==9}// the 
> most straw-man travesty I could think 
> of...Set(nums).count==1&(nums).first ==9
> Proposed solution
> 
> Introduce two algorithms onSequencewhich test every element and returntrueif 
> they match:
> 
> nums.all(equal:9) nums.all(match: isOdd)
> Detailed design
> 
> Add the following extensions toSequence:
> 
> extensionSequence{/// Returns a Boolean value indicating whether every 
> element of the sequence/// satisfies the given predicate.funcall(match 
> criteria:(Iterator.Element)throws->Bool)rethrows->Bool}extensionSequencewhereIterator.Element:Equatable{///
>  Returns a Boolean value indicating whether every element of the sequence/// 
> equals the given element.funcall(equalelement: Iterator.Element)->Bool}
> Source compatibility
> 
> This change is purely additive so has no source compatibility consequences.
> 
> Effect on ABI stability
> 
> This change is purely additive so has no ABI stability consequences.
> 
> Effect on API resilience
> 
> This change is purely additive so has no API resilience consequences.
> 
> Alternatives considered
> Not adding it.
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Soroush Khanlou via swift-evolution]

+1 from me as well.

I was initially unconvinced, until Charlotte showed me her proposal. She lays 
out the case very well, and I agreed to help edit the proposal.

It’s a confusing and bad operator, and it doesn’t give us anything that a 
function on Bool can’t give us. The way I see it, this isn’t very different 
from C-style for loops, the ++ operator, or explicit optionality, which are all 
features where Swift departs from traditional C orthodoxy.

It’s easy to abuse and hard to reason about. Special cases like this operator 
have to really earn their place in the language. This one doesn’t carry its 
weight.

Soroush

> On Oct 26, 2016, at 11:42 AM, Joshua Alvarado via swift-evolution 
>  wrote:
> 
> -1
> 
> I love the idea of challenging the syntax but without any real benefit I can 
> see it harder for new devs and it will cause breaking changes that doesn't 
> outweigh the cause. The syntax z ? x : y is  not hard to comprehend and 
> expresses powerful statements in just a simple line. I do agree it is abused. 
> It is used in places that a fuller if statement would help make sense of the 
> code. It is on the developer to help make the operator easier to understand. 
> The operator is the same across many languages which helps create a standard. 
> 
> Alvarado, Joshua
> 
> On Oct 26, 2016, at 9:12 AM, Mark Sands via swift-evolution 
> > wrote:
> 
>> Strong +1 from me.
>> 
>> This simply feels like the right approach for Swift, as we see the language 
>> head in a direction that has abandoned traditional C-style idioms. As swift 
>> has already dropped support for the ++/-- operators and C-style for loops it 
>> makes logical sense that dropping the ternary operator (or replacing with a 
>> more Swift-like idiom) should follow.
>> 
>> As a side note, after upgrading my swift code to Swift 3, I feel as though 
>> I've become un-phased at future source breaking changes until full stability 
>> is met and set in stone. If they're worth it, bring them on, I say.
>> 
>> Mark
>> 
>> On Wed, Oct 26, 2016 at 8:52 AM, Mike Kasianowicz via swift-evolution 
>> > wrote:
>> I like the idea in theory, but I also like the existing ternary operator. 
>> Could some of this be accomplished without drastic changes?
>> 
>> Some alternative ideas-
>> 
>> 1) Codify ternary operator declaration in the language, but make some 
>> common-sense restrictions to reduce expression parsing complexity (no line 
>> breaks, enforced parens, 'simple' arguments, stuff like that).  If there 
>> were an extension like you propose in addition, my preference would be a 
>> verb like "select".
>> 
>> 2) Make it a binary operator with autoclosure tuple on the RHS (is it 
>> possible to put autoclosure within a tuple?):
>> 
>> public static func ?(_ value: Bool, _ branches: (_ t: @autoclosure () -> 
>> T, _ f: @autoclosure () -> T)) -> T {
>> if value {
>> return branches.t()
>> } else {
>> return branches.f()
>> }
>> }
>> 
>> 
>> 
>> On Tue, Oct 25, 2016 at 11:51 PM, Charlotte Angela Tortorella via 
>> swift-evolution > > wrote:
>> Preamble: I've read over the threads that already exist about the ternary 
>> operator and to be honest they're a complete mess without a single fully 
>> formed proposal.
>> 
>> Pitch: I'd like to simplify the syntax, compiler complexity and learning 
>> curve for newcomers when it comes to dealing with the ternary function. The 
>> best way to do that, in my opinion, is to remove it entirely and add a new 
>> function with better semantics that takes care of ternary operations 
>> entirely within the Swift language.
>> 
>> gist: https://gist.github.com/Qata/25a11c21200f1cf8f43ed78e9ffd727c 
>> 
>> 
>> Replace the `?:` operator with an in-language function
>> 
>> Proposal: TBD
>> Author: [Charlotte Tortorella](https://github.com/qata 
>> )
>> Editor: [Soroush Khanlou](https://github.com/khanlou 
>> )
>> Review Manager: TBD
>> Status: TBD
>> 
>> Introduction 
>> 
>> 
>> The ternary operator in Swift was added early in development, as a holdover
>> from C.  This document is an attempt to provide a clear look at the ternary
>> operator without the baggage of the languages that came before, and comes
>> to the conclusion that we should deprecate and remove the ternary operator
>> in favor of an extension to `Bool`.
>> 
>> As a quick refresher, here's what the ternary operator looks like:
>> 
>> let a = 10
>> let b = 20
>> // If a is less than b, sets e to "foo", else sets e to "bar"
>> let e = a < b ? "foo" : "bar"
>> 
>> Advantages of The Ternary Operator 
>>