On Tue, Jan 18, 2022 at 1:09 AM Daveed Vandevoorde <
daveed@edg.com> 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,
Exactly.
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.
Someone might be tempted to write:
constexpr auto mems = members_of(^S);
and then later feed that to some other reflection algorithm, I suppose. Our implementation will then make the underlying array persistent for the compilation.
Also, I’m still hoping that we will have more facilities to have “compile-time variables” as proposed in P0596R1 some day.
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;
Good catch. That code was added before the transition and I forgot to update it. Thanks again!
Daveed
IMO it would be more correct to return `vector<info>` instead of `span<info>` until there is no concrete motivation to do the latter.
--