What you propose implies substantial changes to translation phase 3 (tokenization for preprocessor symbols) https://eel.is/c++draft/lex.phases#1.3 and translation phase 4 (preprocessing ) https://eel.is/c++draft/lex.phases#1.4

IMO anything that tries to bring high level language features to the pp is not going to receive attention: this is not the intent of the pp, which is a simple token stream processing. Features that require non trivial (macro) name lookup rules, or interpretation of groups of pp tokens are most likely DOA.

Potential resistance points:

1) Operator "." has never been treated specially by the pp, it would always be output as is. The only pp operator or punctuator interpreted by the pp are "#" and "##" within replacement list, the "," and ")" only from the treatment of a preceding function like macro pp-identifier. Any other token which is not recognized by the pp is output as is.

2) The pp recognize and treats single tokens independently and sequentially. The proposed dotted macro names creates context dependencies between tokens ("name1.name2" is a sequence of 3 tokens which cannot be preprocessed independently).
Apart in very few cases, pp is context independent. Namely, outside pp-directive, a sequence of pp-tokens or function like macro invocations are expanded sequencially in a completely independent way. This makes the language implemented by the pp a proper "token pasting and replacing language". Hence it doesn't need to create a syntax tree to interpret sequences of tokens, and macro name lookup is only done for a single token.

3) Name lookup should be kept dumb. Right now only a single token needs to be looked at to resolve its identity as a macro definition. Furthermore, the pp has no good syntactically effective way to express proper scoping for the names it interprets. Such block scoping, was most likely never intended for the preprocessor; TU boundaries would already be a good enough and natural choice for scoping pp sensitive entities. Providing more than this would again likely need constructing syntax trees.

4) macro replacement is complicated enough. just look at https://eel.is/c++draft/cpp.replace .

Julien V.



On September 1, 2023 1:34:29 a.m. EDT, BAMBYK via Std-Proposals <std-proposals_at_[hidden]> wrote:
>This is similar to a regular namespace but with macros. Libraries does
>often use macros and it is usually done by a large of capital letters with
>the identificator of library at the beginning (boost for example):
>BOOST_<macro meaning>
>
>But a something similar to namespace can be used for grouping such kind of
>macros.
># scope BOOST
> # define macro1
> # define macro2
> # define one 1
># endscope
> // apply macro 'one' from the scope BOOST
> BOOST.one;
> // do some preprocessor conditions
> # ifdef BOOST.one
> std::cout << "A scope BOOST has macro 'one'." << '\n';
> # endif
>
>Or if a macro is used in settings purpose
>
># scope BOOST
> /*
>here we define a scope with specific macro that is used in boost library as
>setting (for example)
> */
> # define setting1
># endscope
>
>// inside boost library
>
># scope BOOST
> // other macros of BOOST library
> # define setting2
># endscope
>
>/*
> first scope BOOST and second are concatenated and in result the BOOST
>consists of:
> setting1
> setting2
>
> So this way we've defined a custom setting for that scope
>*/
>
># ifdef BOOST.setting1
> // do something
># endif
>
>
>These scopes can be used for other purposes too and not for library only as
>they let user group their macros better. The benefit is also it is not
>wholly consists of the capslock so is easer to read.