[PATCH] D40291: [Support] Add WritableMemoryBuffer class

[Zachary Turner via llvm-commits]

Creating a MutableMemoryBuffer requires totally different code than
creating a non-mutable memory buffer.  They can fail in different ways, for
example, and some ways of initializing a memory buffer only apply in one
case or the other.

This works for ArrayRef and MutableArrayRef because the only difference
between the underlying type is its constness, but that doesn't work when
the underlying type is a class that has a different interface when it's
const vs non-const.

On Thu, Dec 14, 2017 at 1:16 PM David Blaikie <dblaikie at gmail.com> wrote:

> Looking at it - MutableArrayRef just derives from ArrayRef.
>
> I'm not sure why a similar design wouldn't be used here - with
> WritableMemoryBuffer deriving from MemoryBuffer. Is there a good summary of
> why the difference in design exists here?
>
>
> On Mon, Dec 4, 2017 at 2:32 PM David Blaikie <dblaikie at gmail.com> wrote:
>
>> I advocated for const-ifying ArrayRef when MutableArrayRef was added (so
>> const all the existing ArrayRef, and then have non-const ArrayRef for when
>> mutation is desired - avoiding the need to introduce an explicit
>> MutableArrayRef type) but Chris wasn't a fan of that, so we have ArrayRef +
>> MutableArrayRef (the argument being that most ArrayRefs are const, so
>> making the more common case more verbose was unfavorable)
>>
>> I believe in that case MutableArrayRef has an implicit conversion
>> operator to ArrayRef (or ArrayRef has a conversion from MutableArrayRef, I
>> forget which) & expect we could do the same thing here, to be consistent?
>>
>> - Dave
>>
>> On Mon, Dec 4, 2017 at 9:00 AM Pavel Labath via Phabricator <
>> reviews at reviews.llvm.org> wrote:
>>
>>> labath added a comment.
>>>
>>> Hi David,
>>>
>>> could you look at this by any chance?
>>>
>>> thanks.
>>>
>>>
>>> https://reviews.llvm.org/D40291
>>>
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171214/2d9857a5/attachment.html>