On Tue, Dec 13, 2022 at 2:08 AM Sebastian Wittmeier <wittmeier@projectalpha.org> wrote:

The preprocessor runs in a separate compilation phase. It parses tokens instead of C/C++ code with blocks, etc.

 

Depending on your intended syntax details the preprocessor could get complicated a lot. C++ is probably the most difficult language to parse, which does not need Perl for parsing ;-) (Perl can only be parsed by Perl)

 

Even if possible, would one want to hide the usage of the preprocessor by directives without #?

Personally, I like the syntax uniformity given that they both inhabit the same source files.  

And the trend is going away from using the preprocessor, shouldn't be the proposal about a suggestion how to reduce the need for preprocessor directives?

I agree, the long term goal should be focused on reducing the need for preprocessor directives.  This particular proposal, in its current form, is mostly a proposed user experience upgrade in terms of code flow.  It should still be easy to spot preprocessor code by searching for "condexpr" in the source files.  
Are you aware of any current or past proposals addressing this space (replacing preprocessor conditional inclusion)?  I'd be happy to read up on it more, but I haven't been able to find any proposals about it.
 

What about compatibility? With C and with external tools (e.g. for include dependencies you only need to parse the preprocessor, not C++)?

Compatibility with them in that they still depend on the preprocessor? This proposal still requires the preprocessor to run as this is a syntax upgrade, not a functionality change.  I think it is very worthwhile to have a separate proposal perhaps focused on ways to reduce the need for the preprocessor directives in general, and, for that proposal, compatibility with C and external tools that rely on the preprocessor and not C++ would have to be factored into the proposal.

-----Ursprüngliche Nachricht-----
Von: Michael Levine via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Di 13.12.2022 07:13
Betreff: Re: [std-proposals] condexpr: new syntax for preprocessor conditional inclusion
An: std-proposals@lists.isocpp.org;
CC: Michael Levine <melevine45@gmail.com>;
I propose that we introduce the following new preprocessor conditional inclusion syntax:
 
    condexpr if (expression or identifier, expression or identifier...) {
        ....the conditional logic....
    }
 
New keyword to reserve:  condexpr
 
Some advantages:
  - The syntax looks more like standard C++ code and less like preprocessor directives
  - Rather than writing the preprocessor conditional inclusion syntax like #ifdef and #endif at the beginning of each line, which breaks the flow of code if the code is already nested, this syntax can be written directly into the regular C++ code.

Here is how I would rewrite most of the example from the Conditional Inclusion page here (https://en.cppreference.com/w/cpp/preprocessor/conditional) using this new syntax:

#define ABCD 2 #include <iostream>   int main() {   condexpr if (ABCD)
{     std::cout << "1: yes\n";
} else
{     std::cout<<"1: no\n";
}   condexpr if (!ABCD)
{     std::cout<<"2: no1\n";
} elif (ABCD == 2)
{     std::cout<<"2: yes\n";
} else 
{     std::cout<<"2: no2\n";
}   condexpr if (!(DCBA) && (ABCD < 2*4-3))
{     std::cout<<"3: yes\n";
}  condexpr if (CPU)
{     std::cout<<"4: no1\n";
} elif (GPU) 
{     std::cout<<"4: no2\n";
} elif (!RAM)
{     std::cout<<"4: yes\n";
} else
{     std::cout<<"4: no!\n"; }                         
  
}
-- 
 Std-Proposals mailing list
 Std-Proposals@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals