On 4/3/22 09:21, Jason McKesson via Std-Proposals wrote:
> I don't believe this is necessary. While `T` may not be implicit
> lifetime, arrays of `T` are. So if your allocator returns a `T*`, if
> the caller uses that `T*` in a way that would require that `T*` to be
> a pointer into an array of `T`, the system will create that array
> around the pointer and declare that the pointer was always a pointer
> to an array of `T`.
>
> It does this without creating the `T` elements of the array.


The text doesn't explicitly say this, but I read the requirements on
allocate() as requiring it to return a pointer to storage for the first
array element (otherwise why would it be required to create an array
object?). If the intent was for it to return a pointer to the array
itself, the return type should be T(*)[].

But in either case, the question isn't whether implicit object creation
can create a T[n] (I think we all agree that it can), it's whether you
can get a pointer to that T[n] so that you can return it. Your
assertion that the abstract machine will "declare that the pointer was
always a pointer to an array of `T`" isn't supported by the wording.
That is returning a pointer to a suitable created object
([intro.object]/11), and only a small set of functions are described as
doing that: operator new, operator new[], and malloc and friends. Other
ways of allocating memory don't have this privilege. So an allocator
that returns a pointer into a byte[] it has stored array somewhere
doesn't return a pointer to a suitable created object, and thus is stuck
with a pointer to a byte.

-- 
Jason Cobb
Assessor, Rulekeepor, S​tonemason