Re: [swift-evolution] Optional Argument Chaining

I think evaluating them in the same way as `try` calls is consistent. ``` f(g()?, h()?, i(), j()?)? // like try f(try g(), try h(), i(), try j()) ``` ``` foo(bar(x()?)) + y()? // like foo(bar(try x())) + (try y()) ``` -- Yuta 2017-12-12 7:42 GMT+09:00 Slava Pestov via swift-evolution

Re: [swift-evolution] async void

rget to mark `await`, the compiler tell us nothing and it works like `async Void` in C#. It causes unexpected behaviors. It is hard to fix such kinds of bugs. So I think introducing `beginAsync` is better. -- Yuta 2017-11-12 10:23 GMT+09:00 Yuta Koshizawa via swift-evolution <swift-evolution@swift.org>:

Re: [swift-evolution] async void

2017-11-12 2:57 GMT+09:00 Adam Kemp : > > >> On Nov 11, 2017, at 6:24 AM, Yuta Koshizawa wrote: >> >> If you replace `async` with `throws`, you can get answers. >> >> >>> Can you declare an async closure variable? >> >> Yes. Like `let throwingClosure:()

Re: [swift-evolution] async void

n and treat it as a call-and-forget. > > It’s weird to me that we would allow you to have async void closures but not > async void functions, but in order to support beginAsync we have to have > async void closures. So if we can make that work then why couldn’t we just > make async

Re: [swift-evolution] async void

> I’m not sure how the proposed design handles type checking for async > closures. Is async part of the type? Can I declare a local closure variable > as async? What are the rules for conversion between async and non-async > closures? Is it a warning or error to use a closure literal without an

[swift-evolution] [Question] Why does `beginAsync` rethrow errors?

Although I posted about this topic before, let me post this again because I think it is important and I have received just few replies. Sorry if I missed some discussion about it. In the proposal ( https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 ), `beginAsync` has the following

Re: [swift-evolution] Two thoughts on concurrency

Hi, Although `throws` and `async` are similar to return a `Result` and a `Future` respectively as you say, However, `try` and `await` are corresponding to `flatMap` theoretically. // `throws/try` func foo() throws -> Int { ... } func bar() throws -> Int { let a: Int = try foo() let b: Int =

Re: [swift-evolution] [Concurrency] async/await + actors

>> On Aug 21, 2017, at 1:56 PM, John McCall wrote: >> >> Personally, I think these sources of confusion are a good reason to keep the >> feature separate. >> >> The idea of using await! to block a thread is interesting but, as you say, >> does not fit with the general

Re: [swift-evolution] [Concurrency] async/await + actors

2017-08-21 2:20 GMT+09:00 John McCall via swift-evolution < swift-evolution@swift.org>: > On Aug 19, 2017, at 7:17 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > On Aug 19, 2017, at 8:14 AM, Karim Nassar via swift-evolution < > swift-evolution@swift.org> wrote: >

Re: [swift-evolution] [Concurrency] async/await + actors

`beginAsync(_:)` is a sort of poor man's `Future`—it guarantees that the async function will start, but throws away the return value, and *might* throw away the error unless it happens to get thrown early. Given that its ability to return information from the body is so limited, I frankly don't

Re: [swift-evolution] [Concurrency] async/await + actors

Hi, I have a question about the proposed `async/await`. Are `throws async` and `await try` allowed? I think we have three options. 1. allows only `async throws`-`try await` 2. allows both `async throws`-`try await` and `throws async`-`await try` and does not distinguish them 3. allows both and

Re: [swift-evolution] [Concurrency] async/await + actors

I think we also need `reasync` like `rethrows`. Sorry, I found it was referred in "rethrows could be generalized to support potentially async operations". -- Yuta ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Concurrency] async/await + actors

I think we also need `reasync` like `rethrows`. extension Sequence { func map(_ transform: (Element) async throws -> T) reasync rethrows -> [T] { ... } } let urls: [URL] = ... let foos: [Foo] = await try urls.map { await try downloadFoo($0) } -- Yuta

Re: [swift-evolution] [Pitch] range.contains(anotherRange)

I am not sure if removing initializers from `SetAlgebra` does not cause any problems in the standard library, it seems reasonable for me if range types could adopt `SetAlgebra`. `SetAlgebra` contains some mutating methods like `insert`, `remove`, `formUnion`. It means it is impossible for range

Re: [swift-evolution] [Pitch] range.contains(anotherRange)

2017-08-09 12:50 GMT+09:00 Robert Bennett : It’s a shame that Range can’t be made to conform to SetAlgebra as it lacks the required initializers. Is there anything that can be done about this? Actually, it makes me wonder whether those initializers should even be a part of

Re: [swift-evolution] [Pitch] range.contains(anotherRange)

2017-08-09 12:23 GMT+09:00 Xiaodi Wu : > For consistency, the name for this function would be `isSuperset(of:)`, and it would be equally interesting to have `isStrictSuperset(of:)`, `isSubset(of:)`, `isStrictSubset(of:)` and `isDisjoint(with:)`--all currently available for

[swift-evolution] [Pitch] range.contains(anotherRange)

Hi, Recently I needed to implement `contains` methods to check if a range contains another range. I think those are basic operations and suitable for the standard library. Although it may seem easy to implement such `contains` methods whenever we need them, their precise specifications are too

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

; > swift-evolution@swift.org> wrote: > > > > > >> On Jun 28, 2017, at 3:52 AM, Yuta Koshizawa via swift-evolution < > swift-evolution@swift.org> wrote: > >> > >> Hi, I think it is an orthogonal issue if we need a new operator. It is > >

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

on partial functions, why you should avoid them and how to do so: > it's a very interesting read > http://www.cocoawithlove.com/blog/2016/01/25/partial-functions-part-one-avoidance.html > > > Elviro > > Il giorno 28 giu 2017, alle ore 07:02, Yuta Koshizawa via swift-evolut

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

I like it, but I think the implementation can be improved like below. public static func !!(optional: Optional, errorMessage: @autoclosure () -> String) -> Wrapped { precondition(optional != nil, errorMessage()) return optional! } Failures of forced unwrapping are "logic

Re: [swift-evolution] [Pitch] Never as a bottom type

Joe also referred to the following model in a thread about Typed Throws. () -> () == () throws Never -> () () throws -> () == () throws Error -> () https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032267.html It means `Never` must be a subtype of `Error`. I think

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

> What is your evaluation of the proposal? -1 - Certainly `flatten` and `joined` work similarly. I think, however, the concepts behind them are different. When I use `flatten`, I want to make nested monads flat. When I use `joined`, I want to concatenate sequences, mainly `String`s, with a

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

> Even with the proposed `???`, a domain-specific solution would be arguably > better. So I just don’t consider that a compelling use case. > > — Radek > > On 09 Apr 2016, at 16:56, Yuta Koshizawa via swift-evolution > <swift-evolution@swift.org> wrote: > > I only wonder

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

> I only wonder whether you really want to repeat Error() all over, > possibly with `aString` etc. as argument. What I really want is the postfix version of `???` as I wrote in my first post in this thread. > Besides the proposed infix `???`, I also want the postfix one which > throws a

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

["lastName"].string, > age: json["age"].int) > } catch _ { > // Error handling > } > ``` > > -Thorsten > > > Am 07. April 2016 um 14:01 schrieb Yuta Koshizawa via swift-evolution > <swift-evolution@swift.org>: > > I'd like to s

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

> I'd like to see some real-world examples of this before we did anything with > it. The following is my real-world example. ``` // Decodes a JSON with SwiftyJSON do { let person: Person = try Person( firstName: json["firstName"].string ??? Error(), lastName: json["lastName"].string

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

I agree with this and I like the operator approach. Besides the proposed infix `???`, I also want the postfix one which throws a `NilError` (something like `struct NilError: ErrorType {}`). It is useful to handle multiple `nil`s at once when we are not interested in the kind of the error. ``` //

Re: [swift-evolution] Enable omitting `let` for constant declarations

er-hand But it seems that it was not well discussed, and I think it is worth discussing it. > Macko Thanks! -- Yuta 2016-04-03 16:23 GMT+09:00 Macko Jeffrey <macko.jeff...@gmail.com>: > I love your propositions Yuta. > > --- > Macko Jeffrey > >> Le 1 avr. 2016 à

Re: [swift-evolution] Enable omitting `let` for constant declarations

variable > > as explicit and obvious as possible. > > — Radek > >> On 01 Apr 2016, at 13:58, Yuta Koshizawa via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I think it would be good if the following three declarations were equivalent >&g

Re: [swift-evolution] throws as returning a Result

2016-03-15 2:23 GMT+09:00 Joe Groff : > > Yeah, we extensively discussed adding a Result type internally, but > ultimately couldn't justify it. The only real use case we could see in the > wild was for threading errors through CPS-inversion-style abstractions like > async