Open matus-chochlik opened 8 years ago
As I said: IMHO this is too early to be specified; we need more experience with the fundamental ingredients. I don't see why we need to decide this now. And any "unique across all TUs" will need lots of convincing; that's again something I'd rather like to avoid now.
@karies Shall we do things in the way C++ compiler does for this one? :) Address difficult questions as early as possible.
For what I understood about this effort around reflection, it is intended to have a sound, extensible, future-proof design as much as possible. I understand that constexpr metaprogramming support is very important for the future of the language. Besides, when you say "we" I'm not sure if you mean the designers of the proposal or the standard committee. For the former, I'd argue that's not entirely up to the designers of a proposal to make such big decisions (on how important constexpr support is). For the latter, I'd say that at least it's up to the committee to decide when it's time to decide something.
IMHO, this question should be presented for consideration to the committee.
That said, you're a number of times more experienced than me in the politics of the committee. If you tell me that bringing up such question may delay indefinitely the acceptance of the proposal, I would probably change my mind. The optimal is the enemy of the good...
The current implementation implements the metaobjects in the following way:
1) Adds a new integral type
__metaobject_id
, the actual metaobjects are constants of this type (wrapped in a template).2) The metaobject types are implemented by the following template:
Do we want to expose this to the users (at least in the future)? Will the metaobject id's have any semantic meaning to the users? (IMO no, they can be randomized and even metaobject reflecting exactly the same thing in two different TUs will have* different metaobject ids)
*) with high degree of probability, since the
__metaobject_id
type does not have unlimited range.Pros:
Cons: