> On Jan 18, 2022, at 5:24 AM, Andrey Davydov <andrey.davydov_at_[hidden]> wrote:
>
> On Tue, Jan 18, 2022 at 1:09 AM Daveed Vandevoorde <daveed_at_[hidden] <mailto:daveed_at_[hidden]>> wrote:
>> On Jan 16, 2022, at 8:36 AM, Andrey Davydov <andrey.davydov_at_[hidden] <mailto: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,

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.
>
> --
> Andrey Davydov