Consider making a new index for macro names #6005
Comments
|
I see there are as yet no comments on this issue. Are people for/against this change? For my part, I am in favor of it. |
|
@tkoeppe, having a separate macro names index sounds reasonable to me. What do you think? |
|
If someone can set up the basic structure for the index, and some macro-indexing LaTeX macros, I volunteer to do the tedious work of marking up all the standard macros for the new index. |
|
We can work with https://github.com/JohelEGP/draft/tree/index_macros. Tell me how you'd like to proceed. I think you should open a PR here once you've reviewed that the index and its macros are OK. And until then, we should work on getting to that point on one of our forks, pushing and opening PRs for them. |
|
We should have buy-in from @tkoeppe before investing any effort into this. |
|
Do we have any exposition-only macros anywhere, @AlisdairM ? |
|
There should be none. Is it about my branch https://github.com/JohelEGP/draft/tree/index_macros? I was thinking of weird ALL CAPS names like |
|
I think STATICALLY-WIDEN and similar are not really macros, but some special meta-beast that shouldn't appear in a macro index. In short, it seems we don't need to allow for exposition-only macro names, thus we don't need LaTeX macros dealing with such. |
|
It should be fixed now. |
|
Checking in: if we want this for C++23 I am prepared to do the work of consistently adding the indexing macros on short notice. However, I am assuming it is more likely C++26 than adding a new index at this stage. |
|
@tkoeppe What do you think about this proposal? |
Macros are a very special kind of library name, that become more special in C++23.
First, by their nature as macros, they directly rewrite user source rather than participating in name lookup. It would be good to have such names collected in a single place to reference.
Secondly, the library is not the only source of macro names, given the compiler supplies some predefined macros.
Third, as of C++23, the user will not see any of those macros (other than compiler predefines) if they
import std;rather than directly include library headers. I think this third point now presses the case for separating macros out of the library/compiler index, and into an index of their own.The text was updated successfully, but these errors were encountered: