On Sun, Apr 3, 2022 at 6:55 PM Jason Cobb via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 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.

The pointer will be such a pointer once it gets used as such. Or
rather, the pointer will have always been such a pointer when you use
it as such. That's kind of the point of IOC; so long as the memory is
set to implicitly create objects, you can use any pointer as a pointer
to an array of `T`.

All your allocator has to do is make sure that the memory is such that
objects will be implicitly created within it.