Introduce StringBuilder utility around raw_string_ostream

[Chandler Carruth]

On Thu, Jun 26, 2014 at 11:48 PM, David Blaikie <dblaikie at gmail.com> wrote:

> On Wed, Jun 25, 2014 at 9:53 PM, David Blaikie <dblaikie at gmail.com> wrote:
> > On Wed, Jun 25, 2014 at 5:52 PM, Alp Toker <alp at nuanti.com> wrote:
> >>
> >> On 26/06/2014 03:16, Chandler Carruth wrote:
> >>
> >>>
> >>> On Thu, Jun 26, 2014 at 2:09 AM, Alp Toker <alp at nuanti.com
> >>> <mailto:alp at nuanti.com>> wrote:
> >>>
> >>>     I've made that change, plus a couple more updated uses, and landed
> >>>     this in r211749.
> >
> > FWIW, perhaps I wasn't clear - but my "I'd like to loop back around
> > with Chandler to nail down the design choice" was "I'm not signing off
> > on this patch without Chandler", so the commit may've been a bit
> > premature.
>
> Given this confusion, I think appropriate to back this patch out until
> it's actually been signed off on.
>
> Sorry for my vague language/lack of clarity over incremental review
> compared to sign-off.


Frankly, I think your language was fine. I even misread this, but I can't
think of anything you could have written more clearly -- I just needed to
read it more carefully.

Ultimately, I completely agree with your tradeoff assessment here.
Personally, I'm on the side of a single type because I think the model of
optional-external-storage with identical behavior is a reasonable semantic
model for the type.

I also think that it would be good to keep consistency in naming and API
with raw_..._ostream classes (in part to better distinguish them from
standard _ostream variants).

Personally, given your analysis David, I'm happy with you making the call
between one type or two.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140627/d0e8faff/attachment.html>