Reflection and constexpr values (P0425/P0598) leaking into non-constexpr context

[Axel Naumann]

Hi,

Could someone explain to me why this is not a problem, or how this will
be prevented?

// TU1.h
std::meta::type get();

// TU1.cxx
#include <string>
std::meta::type get(std::string) { return reflexpr(std::string); }

// TU2.cxx
#include "TU1.h"
#include <iostream>
int tu2() {
std::cout << get("").name();
// ... or do more stuff, e.g. enumerate std::string's members etc
}

Cheers, Axel.

[Peter Bindels]

Hi Axel,

Good find.

One solution, and I think most in line with the intent of it being compile-time reflection, is to give any meta type no ABI-level resolution, and implicitly make them unemittable (inline?) functions. This makes TU2.cxx not compile, as it doesn't have the meta type to resolve and cannot emit tu2() without it.

Does this fix the whole problem? I haven't thought this through completely, but I think it covers it.

Regards,

Peter

--
You received this message because you are subscribed to the Google Groups "SG 7 - Reflection" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reflection+unsubscribe@isocpp.org.
To post to this group, send email to refle...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/reflection/.
For more options, visit https://groups.google.com/a/isocpp.org/d/optout.

[Louis Dionne]

I think we already have a similar problem with the currently proposed
reflexpr (per P0194):

// a.h
using X = reflexpr(int);
void foo(X*);

// a.cc
#include "a.h"
void foo(X*) { }

// b.cc
#include "a.h"
int main() {
foo(nullptr); // does that link?
}

I think this can be clarified by making sure that a type resulting from
`reflexpr` can never appear in the signature of a function with external
linkage, etc.. I think this problem is similar to what we run into when
we try to make lambdas appear in an unevaluated context, and we could
probably apply a similar fix.

For our approach (and the problem you raised with it), we could probably
just mandate that one can't create a `std::meta::type` outside of a
constexpr context, and that a `std::meta::type` can't escape a constexpr
context. Peter’s solution may also work. In any case, I don’t think it’s
a deal breaker at this stage in the design (but we should certainly tackle
this when we get to wording).

Louis

Note: I’m confused why there’s both refle...@isocpp.org and e...@lists.isocpp.org
in the recipients of the original message. I’m replying to both, just in case.

> To unsubscribe from this group and stop receiving emails from it, send an email to reflection+...@isocpp.org.

[Andrew Sutton]

For our approach (and the problem you raised with it), we could probably
just mandate that one can't create a `std::meta::type` outside of a
constexpr context, and that a `std::meta::type` can't escape a constexpr
context. Peter’s solution may also work. In any case, I don’t think it’s
a deal breaker at this stage in the design (but we should certainly tackle
this when we get to wording).

This is the direction I was going to explore in my implementation.

--

Andrew Sutton