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
:
>
>
> O
o 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
:
> 2017-11-12 2:
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:() throws -> Void = { ... }`.
>>
>>
>>> Can a n
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 void functions work and disp
> 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 asy
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 s
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 =
>> 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 meaning of ! for logic erro
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:
>
>
`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
thi
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 di
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
https://lists.swift.org/mailma
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
_
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 t
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 SetAlgebra — why must s
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 types that conform to `S
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 co
t; 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
> >> also possible to introduce a
ns, 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-evolution
> ha scritto:
&g
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 f
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 it
> 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 separa
`???`, 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
> wrote:
>
> I only wonder whether you really want to repeat Error() all over,
&g
> 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 `NilError
age: json["age"].int)
> } catch _ {
> // Error handling
> }
> ```
>
> -Thorsten
>
>
> Am 07. April 2016 um 14:01 schrieb Yuta Koshizawa via swift-evolution
> :
>
> I'd like to see some real-world examples of this before we did anything with
&
> 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 ??
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.
```
//
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 :
> I love your propositions Yuta.
>
> ---
> Macko Jeffrey
>
>> Le 1 avr. 2016 à 20:58, Yuta Koshizawa via swift-
t and obvious as possible.
>
> — Radek
>
>> On 01 Apr 2016, at 13:58, Yuta Koshizawa via swift-evolution
>> wrote:
>>
>> I think it would be good if the following three declarations were equivalent
>>
>> let a: Int = 42
>> a: Int = 42
>> a
I think it would be good if the following three declarations were equivalent
let a: Int = 42
a: Int = 42
a := 42
and also the following two were.
let a: Int
a: Int
Then constant declarations become shorter than variable declarations.
It encourages people to use constants in preference to variab
> • What is your evaluation of the proposal?
+1
Although I am not perfectly sure, I think it may be better to raise an
error instead of a warning when the code lacks both
`@discardableResult` and consuming a return value . When someone gets
the warning, we expect them to consume the resul
2016-03-16 2:03 GMT+09:00 Joe Groff :
>
> On Mar 15, 2016, at 6:39 AM, Yuta Koshizawa wrote:
>
> 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 f
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 promises, something we hop
33 matches
Mail list logo
