Skip to content

Conversation

@oldnewthing
Copy link
Member

Previous error message was

error C2672: 'get_awaiter': no matching overloaded function found

New error message is

error C2338: Not an awaitable type

If you co_await something that has both a member operator co_await as well as a free operator co_await, the error message used to be

error C2668: 'winrt::impl::get_awaiter': ambiguous call to overloaded function

and it is now

error C2338: Ambiguous operator co_await (as both member and free function)

The C++ standard has rules for resolving the ambiguity, but they are difficult to express in template metaprogramming, so we don't try and simply reject them. Hasn't been a problem yet. Added some ambiguous awaiters to the unit tests to verify that we resolve to the correct one in the cases we support.

Remove vestigial support for free awaiters, which is left over from an earlier iteration of the coroutine TS.

(There is an interesting asymmetry in awaiter_finder: We always search for await_ready on an lvalue, whereas the operator co_await uses the original reference category of the object being awaited. This is a consequence of the language specification, which converts the awaiter to an lvalue after applying operator co_await but before calling await_ready.)

oldnewthing and others added 2 commits July 28, 2020 13:05
Previous error message was

```
error C2672: 'get_awaiter': no matching overloaded function found
```

New error message is

```
error C2338: Not an awaitable type
```

If you `co_await` something that has both a member `operator co_await`
as well as a free `operator co_await`, the error message used to be

```
error C2668: 'winrt::impl::get_awaiter': ambiguous call to overloaded function
```

and it is now

```
error C2338: Ambiguous operator co_await (as both member and free function)
```

The C++ standard has rules for resolving the ambiguity, but they are
difficult to express in template metaprogramming, so we don't try.
Hasn't been a problem yet. Added some ambiguous awaiters to the unit
tests to verify that we resolve to the correct one.

Remove vestigial support for free awaiters, which is left over from
an earlier iteration of the coroutine TS.

(There is an interesting asymmetry in awaiter_finder: We always search
for `await_ready` on an lvalue, whereas the `operator co_await` uses the
original reference class of the object being awaited. This is a
consequence of the language specification, which converts the awaiter to
an lvalue *after* applying `operator co_await` but *before* calling
`await_ready`.)
Copy link
Collaborator

@kennykerr kennykerr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@kennykerr kennykerr merged commit 95c342e into microsoft:master Jul 29, 2020
@oldnewthing oldnewthing deleted the get_awaiter branch July 29, 2020 14:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants