Gwendal Roué comments

Results 270 comments of


                                            Gwendal Roué

Incorrect resolution of sync/async overload when async overload is provided as the default implementation of a protocol requirement

Thank you!

Wrong Sendable closure diagnostics with implicitly unwrapped optional

Reproducible with both `swift-DEVELOPMENT-SNAPSHOT-2024-03-29-a` and `swift-6.0-DEVELOPMENT-SNAPSHOT-2024-03-26-a`.

Wrong Sendable closure diagnostics with implicitly unwrapped optional

The bug is still present in Xcode 16.0 beta (16A5171c).

Wrong Sendable closure diagnostics with implicitly unwrapped optional

The bug is still present in Xcode 16.0 beta 3 (16A5202i).

Closures with `DatabaseComponents` argument should become throwing closures

Thanks for the reminder. I don't know why it's not shipped already :-)

Closures with `DatabaseComponents` argument should become throwing closures

Shipped in 7.6.0

Swift compiler does not chose the correct sync/async overload

Bug still present in Xcode 16.0 beta 3 (16A5202i)

Swift compiler does not chose the correct sync/async overload

Hello @hborla, Thanks for looking at this issue. I'm the author of the [amendment](https://forums.swift.org/t/amendment-se-0296-allow-overloads-that-differ-only-in-async/49808) that specified, so I'm all responsible for this. Let's provide my own emphasis: > In **non-async...

Swift compiler does not chose the correct sync/async overload

BTW, since fixing this issue would be a breaking change (some code that is currently accepted would stop compiling with an "expression is 'async' but is not marked with 'await'"...

Swift compiler does not chose the correct sync/async overload

> This must be a bug since the async overload is not even a real option here since the line is not marked with `await`, right? @qusc, this is not...