Compile-Time Constant Expressions for Swift

[marcrasi]

@anandabits

What if somebody wants to use an internal @compilerEvaluable function during compilation internally but does not want to make that function @inlinable? Is there some motivation for not supporting that use case?

Interesting, I hadn't thought of that use case. I think it's possible to make rules that allow that to happen. For example:

1. Compile-time calls to external functions only work if the callee is @compilerEvaluable.
2. A @compilerEvaluable function can only call other @compilerEvaluable functions, even if the caller and callee are internal.
3. @compilerEvaluable always implies inlinable.
4. However, compile-time calls to same-module functions work on non-annotated functions. (e.g. a module can do #assert(foo()) when foo is defined in the same module, even if foo is not annotated).

(1), (2), and (3) guarantee that the transitive call graph of any compile-time call to an external function has SIL available. (4) supports the use-case that you mention.

Do those rules sound reasonable, easy-to-understand, etc?

@anandabits

Is there any motivation for coupling these behaviors besides a desire to minimize the annotation burden?

I think my only motivation was that I wasn't thinking about the purely-internal use case :) Thanks for pointing it out!

@beccadax

This sounds like the same problem we solve with @inlinable by allowing @inlinable internal . Why can't we have @compilerEvaluable internal for functions we want to call from @compilerEvaluable public functions, and still infer the attribute for purely internal calls?

Are the rules that I wrote above along the lines of what you are thinking?