Add transparent access for internal buffer in LocalBuffer

[maskit]

#6536 looks ok, but use of LocalBuffer requires additional variable just for type conversion. This PR adds transparent access for the internal buffer in LocalBuffer and it allows accessing LocalBuffer like a pure array.

[masaori335]

Because of std::array, std::vector, and std::string don't have this, I'm wondering if there is any trap or not.

/cc @ywkaras @SolidWallOfCode

[ywkaras]

Can you give examples where this would be useful?'

This is a conversion operator, which (without the explicit keyword) creates an implicit conversion. This, https://stackoverflow.com/questions/2346083/why-implicit-conversion-is-harmful-in-c , talks about implicit conversion due to constructors, but the issues also apply to conversion operators.

To give a simple example of how it's bad:

LocalBuffer<char> buf;
// ...
foo(buf);

It's ambiguous whether the prototype for foo() is foo(char *) or foo(LocalBuffer<char> &).

[maskit]

The implicit conversion is to not introduce additional code, which you can find on the existing unit tests and #6536.

uint8_t *buf = local_buffer.data();

As you can see on the unit tests I added, you would be able to pass a LocalBuffer to memcpy (and functions that expects a pointer for an array).

My understanding of the intent of using LocalBuffer is achieving code like below.

char buf[max(1024, given_dynamic_size)];

So making LocalBuffer usable just like an array without additional code or explicit conversion makes sense to me. I don't think we will want functions that receives LocalBuffer.

[ywkaras]

Note that the partial specialization of std::unique_ptr can be used for variable sized buffers. But the designers of this chose not to make it implicitly convert to a raw pointer. https://godbolt.org/z/ozKPso

[maskit]

I guess it's because implicit conversion can easily break the concept of ownership.

[SolidWallOfCode]

Yes. I have to agree with removing the implicit conversion and requiring a call to data(). That makes it consistent with the other types of containers (e.g. string_view, string, etc.).

If you want to pass directly to things like memcpy I would overload such functions to take advantage of knowing the size implicitly.

[maskit]

If we want to make the conversion explicit I think it should not provide index access neither since you can do &buf[0].