[PATCH] D27679: Simplify format member detection in FormatVariadic

[Zachary Turner via llvm-commits]

I believe that will break the (admittedly rare) case where the user wants
the formatter to modify the value.  Anyway, let's just stick with the move
for now, iot's not a big deal.

On Wed, Dec 14, 2016 at 10:40 AM Pavel Labath <labath at google.com> wrote:

> If you mean the FooAdapter constructor, that will not help. No matter
> how you declare it, it is going to get treated as a value, which has
> to be explicitly moved.
>
> On the other hand, having FormatAdapter take `const T &` seems to do
> the trick. I have a feeling doing that will break the universal
> reference forwarding in some way, but I was not actually able to come
> up with an example that demonstrates it. So that could be a possible
> middle ground that could work until someone actually needs the
> universal forwarding behaviour.
>
> On 14 December 2016 at 18:13, Zachary Turner <zturner at google.com> wrote:
> > What if constructor takes a const int &
> >
> > On Wed, Dec 14, 2016 at 10:08 AM Pavel Labath <labath at google.com> wrote:
> >>
> >> On 14 December 2016 at 18:02, Zachary Turner <zturner at google.com>
> wrote:
> >> > Can you give me an example of a trivial adapter with "broken" code and
> >> > then
> >> > how to fix it?  Doesn't this work?
> >> >
> >> > class FooAdapter : public FormatAdapter<int> {
> >> > public:
> >> >   explicit FooAdapter(int n) : FormatAdapter<int>(n) {}
> >> > };
> >>
> >> That will not work because the base constructor accepts a rvalue
> >> reference, which will not bind to "n". To make it compile you need to
> >> do a std::move(n). There's nothing truly broken there, it's just
> >> moderately annoying.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161214/3d4a72ca/attachment.html>