-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
How do we indicate that functions should be callable during compilation? #748
Comments
There's also a semantic question: should a function that is annotated this way be evaluatable only during constant evaluation (like C 's Given how central constant evaluation is to Carbon's semantics, I think we can easily justify a punctuation syntax here. Perhaps something like a |
Do we need both semantics? I understand the historical reasons why C needed them, but I'm wondering if there is a way to avoid that in Carbon. |
I think we need:
Assuming both situations require a marker, I think we can get away with using the same marker for both, and reject programs that (transitively) use compile-time-only constructs from runtime functions. I think then the question would be: do we want an explicit, declarative statement of intent in code to indicate whether a function is usable at runtime, in the same way we want an explicit, declarative statement of intent in code to indicate whether a function is usable at compile time? I think the answer might reasonably be no. The only way we wouldn't be able to work this out for ourselves is if a function is intended for compile-time use only but the implementation happens to not use any compile-time-only functionality yet, which seems like a rare situation (quite unlike the situation of a runtime-only function that just happens to not use any runtime-only functionality yet, which is common). We could provide a mechanism to address that narrow issue (such as a compile-time-only operation that happens to be a no-op) if we think it's worthwhile, and then just have a single "usable at compile time" marker that allows runtime use only if the function doesn't transitively depend on anything that's compile-time-only. |
This comment was marked as outdated.
This comment was marked as outdated.
While not urgent, reading this it seems like we're close to a decision here? Specifically, if we don't try to model both semantics (and allow a future proposal to do a no-op compile-time-only operation if it comes up), then we only need one syntax. @zygoloid had suggested Do folks have specific reasons to prefer one position or another? Do folks have specific concerns with using |
I have a mild preference for |
I think there are two things we could say here:
In the first "constexpr" case, a function with the annotation would be during-compilation-only if all its parameters are compile-time-only (declared with In the second "consteval" case, parameters that aren't marked compile-time-only (declared with It seems to me that it is going to be common to want an easy way to say "this function should be available at both runtime and compile-time because it performs a pure computation and will be needed in both contexts," and so I think we need a way to say "constexpr." There is also a use case for "this function computes a type or something else like an initializer that we want to be sure is comptime_only." I'm open to that being "constexpr all parameters are |
I would like to bring up a big issue with the The tl;dr is that type_traits run at compile time but they were designed to make decisions about runtime. "Does this function exist" at compile time is really trying to ask "Will this function exist at runtime, such that I can compile a call to it here" and consteval basically breaks type_trait usage because it's not available at runtime. Rust side steps this whole thing because I think these footguns should be known before copying them from C at least. |
We are likely going to have compile-time-only values, like types, and compile-time-only functions (for interop with C |
In #498, we had a question of whether you can call unannotated functions in a type context:
The current resolution of #498 suggests that functions would need an explicit annotation in order to be able to be called in this context, perhaps analogous to C 's
constexpr
. This seems to be easily justified by our code evolution goal.However, given that we want to support forms of compile-time programming similar to the above, we will need some syntax to indicate the intent to allow uses of
g()
in constant evaluation, along with everything that implies -- in particular, imposing constraints on future evolution of the function. So what syntax should we use? Some options:constexpr
or perhaps simplyconst
)!
somewhere in the function declaration (fn!
org!
)There are probably many others.
The text was updated successfully, but these errors were encountered: