Are there any reasons not to have built-in constants?

Question

As of C17 there are no built-in constants. To use true false NULL or similar one must #include various header files. However this will change in C23 and true false and bool will be keywords.

In Java there is Math.PI instead of having PI or pi as a keyword.

Is there any reason to do that as opposed to just making them keywords that behave as literals? What are the advantages and disadvantages of having constants built-in versus having them imported from library/header files?

Answer 1

Some constants (true, false, null, maybe some others in specific languages) are so important that they need to be in scope everywhere. It would cause major problems if the user were allowed to shadow them, and it would be very inconvenient if they were only accessible through qualified names like Boolean.TRUE. By making these keywords, the user cannot declare variables with the same names, and then shadowing is impossible.

In languages where all variables are mutable (i.e. "constants" are just variables you choose not to reassign), it would even be a "WTF" for fundamental constants to be treated the same way as other variables. In very old versions of Python it's legal to redefine True, False and None, and in Javascript (in "sloppy" mode) it's legal to redefine undefined. Many people found this ridiculous, and it was fixed in later versions of Python and strict-mode Javascript.

On the other hand, keywords are part of the language grammar, and if you did this for every constant then the grammar would change every time you add a new constant to the standard library, and this would invalidate existing code which uses those names for variables. (Keyword constants can't be contextual or "soft" keywords like match in Python, because they appear in the same contexts as variable names anyway.)

Additionally, constants like PI or MAX_INT aren't used practically everywhere, and don't necessarily need to always be in scope or be protected against shadowing. So in these cases I think it makes more sense to treat them like regular constants or variables, with the same semantics as those that users are able to define.

Answer 2

Because they can be

There is no real need to give these constants special treatment in the compiler. Normal values would function exactly the same in most cases. Not giving them special treatment but simply defining them in the standard library is easier.

Not all of them are used very much

While true, false, and null are common enough to have in global scope, something like PI is only really used in trigonometry. It's not that much effort to type Math. in front of it when you need it.

PI is used in many math formulas with a different meaning than 3.14... If Pi was always in the global scope you couldn't name any variables PI without leaving you unable to access the circle constant.

Answer 3

Alternative solution: static properties + inferred base type

Swift has things like this:

extension Double {
  static var pi: Double { 3.14... }
}

Swift also has inferred base types for static variables:

let x: Double = .pi // inferred as Double.pi

These extensions can live in other modules, so they don't have to be built-in, but the inferred base types lower the barrier to use, in a sense.

Answer 4

You might not know the type and precision required

Consider Pi as a constant in a C like language

Should it be a float or a double or a 128 bit precisions float or perhaps even an arbitrary precision bigint?

How many digits do you need?

Though in fact pi has arrived in C++20. That it took so long to get there should hint there are some issues.

You may be trying to guess your users requirements

If you provide pi as float but actually most of your users wants a double you have polluted your standard namespace and everyone is rolling their own double_pi.

what do you mean by builtin?

Builtin constants are unnecessary bloat if you don't use them. Maybe I don't have any use for pi in my application.

Your constant is not as constant as you think

Say you define PATH_MAX as a builtin constant for the maximum length of a path. Does that vary by operating system or file system? Is it something your application should actually get from calling a function at runtime? See for example https://eklitzke.org/path-max-is-tricky

Some constants are safe and good

It seems pretty sane for true and false to be builtin.

Beware automatic type conversion

But to give them values of 1 and 0 might be a unwise if your language supports arbitrary conversions to and from different kinds of number.

Booleans may be better off being left as a distinct type.

Answer 5

C Has An Infinite Number of Builtin Constants

C17§6.4.4. and §6.4.5. define four different kinds of builtin constants: integers, floating-point numbers, character constants and string literals.
Each allow for an arbitrary number of either digits or characters (including in character constants).

C does not need to offer any of them as part of its feature set. Integrals can be represented fully using Peano's Numbers:

type 0
type ℤ⁺ : (ℤ⁺ | 0) -> ℤ⁺
type ℤ⁻ : (ℤ⁻ | 0) -> ℤ⁻
ℤ = 0 | ℤ⁺ | ℤ⁻

5 = ℤ⁺ (ℤ⁺ (ℤ⁺ (ℤ⁺ (ℤ⁺ 0))))
-4 = ℤ⁻ (ℤ⁻ (ℤ⁻ (ℤ⁻ 0)))

Look ma! No builtin numbers!

42 is as much a keyword as are true, false and null.
Many languages, including C-like ones, don't even have builtin negative literal constants, and instead have a unary minus operator that you apply to numbers.