On Tue, Jan 18, 2022 at 1:09 AM Daveed Vandevoorde <daveed_at_[hidden]> wrote:

> On Jan 16, 2022, at 8:36 AM, Andrey Davydov <andrey.davydov_at_[hidden]>
> wrote:
>
> I wonder what is the lifetime of underlying storage referenced by
> std::span returned from such functions as std::meta::members_of? Is this
> array persisted throughout the compilation process?
>
> That’s a good question (and one of the reasons I was reluctant to make the
> vector->span change at first).
>
> An implementation is of course free to recompute the array if it needs to.
> However, if the array “leaks” outside constant-evaluation, it is likely to
> be made persistent, but doesn’t leak.
>
> I don’t expect span<info> objects to typically “leak”, but the
> “string_view” objects yes.
>

Thanks for the response!

I agree that `string_view` could easily "leak", a function
`std::string_view to_string(Enum auto e);` is one of such examples, but I
don't see how to use `span<info>` outside of constant-evaluation, because
`meta::info` couldn't be used in runtime and `span<info>` is not a
structural type and so couldn't be used as NTTP.

Moreover, if the lifetime of underlying storage returned by
meta::members_of is underspecified then implementation of `get_base_types`
in the example on page 46 looks quite suspicious. It's not obvious why it's
valid to modify span elements inplace:

auto result = bases_of(...);
for (auto &info : result) {
  info = type_of(info);
}
return result;

IMO it would be more correct to return `vector<info>` instead of
`span<info>` until there is no concrete motivation to do the latter.

-- 
Andrey Davydov