On Sun, Mar 12, 2023 at 12:18 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, Mar 12, 2023 at 11:02 AM Breno Guimarães via Std-Proposals wrote:
> >
> > A while ago I floated the idea of having a function to allocate
> contiguous arrays of objects.
> >
> > I didn't have anything concrete to show back then, so I'm coming back
> with a bit more meat to the idea:
> > https://github.com/brenoguim/make_contiguous_objects/blob/main/README.md
> >
> > I'm looking for feedback on more use cases, maybe discussing alternative
> APIs, and arguments against having this in the standard.
> >
> > The last time I got feedback to apply it in major codebases (listed in
> the motivation section), and I'll get to it now that I'm back to work on
> this.
>
> I really don't like the interface, receiving a tuple of spans which
> you then have to delete by sending this tuple to some other function.
> Thus far, all of the `make_*` functions work via RAII: the object you
> get back either itself is the memory or is managed by a RAII object
> like `unique_ptr`. Either way, the object returned owns any storage
> associated with it.
>
> I feel like this should be the case for your `make_*` function too.
> You can have a `std::get`-based interface to retrieve spans if you
> like, but it should not be a bare tuple that you then have to manage.
> There can be an alternate version for allocating such arrays in
> existing storage, but the `make` version should use RAII management.
>

I haven't read the proposal in depth yet, but it sounds like I'd agree with
Jason.
My "minor" nitpick — which is highly relevant to Jason's point — is that
your first section *should not use `auto s`*.

auto s = std::make_contiguous_objects<char, int, long>(numC, numI, numL);

You need to spell out the type here, so that the reader can see what you're
proposing.
If your answer truly is
    std::tuple<std::span<char>, std::span<int>, std::span<long>> s =
std::make_contiguous_objects<char, int, long>(numC, numI, numL);
then you've got a big problem with resource management and you need to keep
iterating on it.

FWIW, consider a signature of the form

template<class... Ts>
  auto make_shared_contiguous_objects(decltype(void_t<Ts>(), size_t())...
counts)
    -> std::tuple<std::shared_ptr<void>, Ts*...>;

and then see if you can find a way to analogize that for unique ownership.
(The caller already knows the lengths of all the spans, so you shouldn't be
repeating that back to them unless the ergonomics are overwhelmingly in its
favor.)

my $.02,
–Arthur