[llvm] r290020 - Add support for formatv to llvm::Twine.

[Zachary Turner via llvm-commits]

If we did that, we'd be making a subtle change to the behavior of formatv.
Right now nobody is using a formatter that depends on state or
non-determinism (i.e. randomness), but there's nothing preventing someone
from creating one either.  If we cache the result of formatv, and a
function rendered the Twine multiple times, then the stateful / random
formatter wouldn't really work as expected.

I'm not necessarily opposted to doing that, but it's something I hadn't
given much thought to so I would have to think about it some more and try
to figure out if there's any other ways this could lead to surprising
results.

On Fri, Dec 16, 2016 at 6:39 PM Joerg Sonnenberger via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Sat, Dec 17, 2016 at 12:38:15AM -0000, Zachary Turner via llvm-commits
> wrote:
> > Author: zturner
> > Date: Fri Dec 16 18:38:15 2016
> > New Revision: 290020
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=290020&view=rev
> > Log:
> > Add support for formatv to llvm::Twine.
>
> Isn't this going to call formatv more than once if the Twine is
> evaluated multiple times? It feels like this partially defeats the
> purpose of the Twine in first place. Is there a good reason why formatv
> can't provide its own SmallString buffer for such use?
>
> Joerg
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161217/7aeb9186/attachment.html>