The calling convention is irrelevant to the standard, as the ABI is the
responsibility of the implementations. And you already can make an arena
allocator and use it either for explicit collections (via `Allocator`
parameters) or replace the global allocator.

I'm not sure why providing a third way to override the allocator would be
necessary.

On Thu, 18 Apr 2024 at 09:32, Stephen Channell via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> The proposal is a half-way house between the current scheme where the heap
> has unchecked access and compiler-controlled pointers of Rust and C++ code
> analysis.
>
> It does so by standardizing Arena Allocators and adding a calling
> convention to pass a reference to the current threads arena.
>
>
>
> An example of Arena allocator is provided by google protobuf (
> https://protobuf.dev/reference/cpp/arenas/) with a similar allocator for
> LevelDB/derivations and apr_bucket for Apache httpd.
>
>
>
> Standardizing the different implementations of Arena allocation would be a
> worthy endeavor but does not justify the effort on its own but would for
> memory safety.
>
> arena alloc = make_unique<std::Arena>();
>
> would indicate that alloc is used as the default arena allocator while it
> remains in scope.
>
> std::Arena stored = arena;
>
> Would store the current arena for use by a std::allocator for collections
> that are part of a larger {session, singleton, configuration}.
>
>
>
> arenacall calling convention would extend the AMD64 ABI (where ‘this’ is
> the first parameter), with the arena as the second parameter, or thiscall
> convention (where ‘this’ is passed in register) with a register reserved
> for the arena. The arena would be either the current arena of the caller
> or ZERO to indicate that no arena is passed.
>
> arenacall functions for memory allocation and free would use the arena
> pointer for allocation and free if passed, and the CRT heap otherwise.
>
> void* __arenacall operator new (size_t size);
>
> void __arenacall operator delete (void* p);
>
> void __arenacall operator delete[] (void* p);
>
> void* __arenacall malloc(size_t
> <http://en.cppreference.com/w/cpp/types/size_t> size )
>
> void __arenacall free( void* ptr );
>
>
>
> · arenacall is suitable for scenarios where Rust might otherwise
> be considered, recognizing that Rust functions are normally called from
> C/C++, and call C/C++ foundation functions and cannot therefore guarantee
> safety.
>
> · arenacall is suitable for messaging services that would
> otherwise use a framework specific allocator or arena.
>
> · arenacall is suitable for scenarios where a system allows
> domain modules to be loaded but requires an elevated level of assurance
> that they cannot overwrite memory of other modules and do not leak memory.
>
> · arenacall would be faster for methods that allocate many
> temporary objects –saving heap calls may offset the cost of checked arena
> assertions.
>
> · arenacall embraces the C++ principle that you do not pay for
> options you do not choose to use.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>