[llvm] r290020 - Add support for formatv to llvm::Twine.
Zachary Turner via llvm-commits
llvm-commits at lists.llvm.org
Fri Dec 16 19:53:37 PST 2016
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
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
> > 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?
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits