aaronpuchert added inline comments.
================
Comment at: clang/lib/Sema/SemaCoroutine.cpp:896
+ if (S.CanPerformCopyInitialization(Entity, &AsRvalue))
+ return true;
+ } else if (auto *FTD = dyn_cast<FunctionTemplateDecl>(D)) {
----------------
aaronpuchert wrote:
> Quuxplusone wrote:
> > aaronpuchert wrote:
> > > Overlad resolution can actually still fail if there is a viable
> > > candidate, namely when there are multiple candidates and none is better
> > > than all others. It's a bit weird though to fall back to lvalue parameter
> > > then as if nothing happened.
> > That is an interesting point! I had not considered it during
> > [P1155](https://wg21.link/p1155r2). I imagine that it might make
> > implementation of [P1155](https://wg21.link/p1155r2)'s new logic more
> > difficult.
> >
> > GCC 8 (but not trunk) implements the behavior I would expect to see for
> > derived-to-base conversions: https://godbolt.org/z/fj_lNw
> >
> > C++ always treats "an embarrassment of riches" equivalently to a "famine";
> > overload resolution //can// fail due to ambiguity just as easily as it can
> > fail due to no candidates at all. I agree it's "a bit weird," but it would
> > be vastly weirder if C++ did anything //different// from its usual behavior
> > in this case.
> >
> > I'm still amenable to the idea that `co_return` should simply not do the
> > copy-elision or implicit-move optimizations at all. I wish I knew some
> > use-cases for `co_return`, so that we could see if the optimization is
> > useful to anyone.
> > I agree it's "a bit weird," but it would be vastly weirder if C++ did
> > anything different from its usual behavior in this case.
>
> I would find it more natural to throw an error, i.e. not do the fallback, in
> the case of ambiguity. So the fallback should in my opinion only happen when
> there are no viable overload candidates, not when there are too many.
>
> I see your construction as follows: we add both operations that take an
> lvalue and those that take an rvalue to a bigger “overload set”, and order
> those that take rvalues as higher/better than those that don't. One could say
> that we do overload resolution on a `T&&` argument where we allow binding a
> `T&&` to a `T&`, but this is less preferable in the overload ordering.
In light of your comment
>>! In D88220#2435959, @Quuxplusone wrote:
> This example will be mentioned in my upcoming (not-yet-finished) WG21 paper
> [P2266](https://wg21.link/p2266), as an example of why the two-pass mechanism
> sucks and should be removed from C++2b.
could we re-evaluate this point? I'm not sure what your paper is going to say,
but I think I agree that the two-pass mechanism is weird.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D68845/new/
https://reviews.llvm.org/D68845
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
