We already have a mechanism how to allocate in constexpr/consteval context. And in C++20 std::string and std::vector is constexpr thanks to Louis Dionne's heroism. We currently only don't have a mechanism how to transfer an allocation from compile-time into runtime. That's something https://wg21.link/p1974r0 <https://wg21.link/p1974r0> is trying to solve.

Hana

> On 9. 4. 2021, at 14:35, Matus Chochlik via SG7 <sg7_at_[hidden]> wrote:
>
> Hi Peter
>
> On Fri, Apr 9, 2021 at 2:26 PM Peter Dimov via SG7 <sg7_at_[hidden]> wrote:
> Matus Chochlik wrote:
> > Hi,
> >
> > IIUC the current plan is to use `string` and `vector<meta::info>` in the
> > reflection API (both of which require consteval dynamic allocation). Is this
> > correct and if so, was there some reason for not using `string_view` and
> > `span<meta::info>` instead? The returned metadata is always static, so
> > mutable containers look like overkill.
>
> I would go even further and argue in favor of returning char const*. You
> can construct a string_view from that but not vice versa.
>
> vector<info> can't be replaced with span<info> though because it's
> often built dynamically (e.g. if the contents are filtered with a predicate.)
>
>
> This still happens at compile-time inside of the compiler, so it could allocate the filtered range of metaobjects by using some internal mechanism, that is not exposing generic "dynamic" allocation in consteval.
> Just saying, in case solving dynamic allocation in constexpr/consteval contexts is something blocking us moving forward with reflection.
> Or am I missing something?
>
>
> --Matus
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7