On Monday, 18 December 2023 17:11:16 -03 Frederick Virchanza Gotham via Std-
Proposals wrote:
> On Mon, Dec 18, 2023 at 4:55 PM Thiago Macieira wrote:
> > There shouldn't be unaligned versions. The parameters should be plain T
> > pointers.
>
> 'std::unaligned' will need to relocate an object into (and back out
> of) unaligned space, and therefore we need an void* or byte*.

That's not established. You've offered this extension with no supporting
evidence that it is actually needed. We know it can technically be achieved,
but we don't know why it should be achieved. There's a cost associated to
this, especially if the burden of writing the relocator is one the class
implementer, because there's more to learn, teach, and write.

Unaligned data has a very narrow use-case. You're trying to expand it by
allowing non-trivial types. Offer reasons why.

> By the way I was thinking it would be cool if every class
> automatically had "void ::_Relocate(void*,void*)" as a friend, so that
> people can write the relocation function for libraries that were
> written years ago (before the idea of relocation came up).

The paper on non-trivial relocation should offer a syntax for doing that. It
may be requiring a core language change. I don't remember the latest details.

If you've read it recently and suggest that having a friend _Relocate function
is the proper way of going about it, please talk to Arthur and/or write a
paper of your own explaining why your way and not his way.

> I've always thought though that it would be nice to be able to do the
> following:
>
> void Func( std::string &s )
> {
> friend std::string; // Now we can access all the private
> and protected members
> char *p = s._M_local_data;
> }

We might as well not have private and protected in the language then. Why
don't you write a paper to suggest we deprecate them?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering