-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: compile time constexpr in Rust via cpp!() #95
Comments
I think for the enum use case, the best is to use the But apart from that, this can still be useful. For the implementation, it kind of sounds logical that this should be added in the Regarding your concerns:
Not a problem, this is just a
It is not a new type of error. It is simply a C++ compilation error as any other.
I think that's fine.
That's useful to declare an enum in your rust code that's usable from C++, but if you want to get the value from C++ enum from third party library, as i said before, i recommend the |
Summary
I want to evaluate C++ code at compile time, and use produced values in const-expr contexts Rust which is a more strict requirement than just any rvalue.
This is going to be used in expressions rather than statements, thus
return
keyword and;
semicolon are not needed.Description
Some things need to be known at compile time, such as const generics and enum values. Offloading them until run time is technically not an option. Thus, would be nice to have
cpp!()
macro compute C++ expressions while building and generating Rust code.The first and primary use case for this are enums: copy-pasting values back and forth is an error-prone approach. Imagine writing this instead:
It looks cumbersome, so it might be a better idea to support such scenario natively in
cpp
. Maybe via an additionalcpp_enum!
macro in complement to existingcpp_class!
?Implementation
I can think of three ways to implement this, varying by complexity level and overhead. Depending on range of supported data types, developing wire format might be required. But let's start with simple integer and floating types for now.
const
macro as a separate binary with its ownmain()
. Communicate through stdout. Invoke separate binaries one by one.main()
that chooses whichconst
expression to return. Communicate through stdout, invoke one by one with different--const <name>
.cpp!
invocations in advance before substituting any of those. (I believe, this was implemented?)All this would've been much easier if Rust would allow us to call FFI code within recently introduced inline const blocks. But that's an entirely different topic worth of RFC on its own.
Concerns
cpp
crate: panic if any of this fails, preferably with reasonable error messages. Compile time evaluation of C++ code, however, introduces new type of errors.unsafe
keyword and whether it is needed at all? In line with Rust function definitions, I suppose it would becpp!(const unsafe ...)
.const
qualifier to a function does not change its further syntax, butcpp!
removes arguments list,return
keyword and;
semicolon.Alternatives
Shared Types chapter in CXX crate: https://cxx.rs/shared.html.
The text was updated successfully, but these errors were encountered: