# \[Pitch\] Compile-Time Constant Values

**URL:** <https://forums.swift.org/t/pitch-compile-time-constant-values/53606>\
**Category:** Pitches\
**Created:** [November 19, 2021, 10:22pm UTC](https://forums.swift.org/t/pitch-compile-time-constant-values/53606 "2021-11-19T22:22:41Z")\
**Posts on this page:** 1\
**Showing post:** 53

<div class="post-metadata">

**Author:** ![wowbagger](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/wowbagger/32/13847_2.png) [@wowbagger](https://forums.swift.org/u/wowbagger)\
**Post date:** [December 2, 2021, 1:58pm UTC](https://forums.swift.org/t/pitch-compile-time-constant-values/53606/53 "2021-12-02T13:58:47Z")

</div>

Thanks for the the answers to my questions!

> [@ben-cohen](#):
>
> The term is not rigorously defined but I would describe enum cases as literals too.

I've always thought of literals as a piece of hard-coded data written in code, but I can see it being understood differently. If enum cases are covered in this pitch, do you think things that behave like them such as static `Self` typed properties like `Double.pi` are covered in this pitch too?

> [@ben-cohen](#):
>
> These maxims must be applied with pragmatism in mind rather than as hard rules. For example, you could say `func` is brevity over clarity, except that the clarity of `function` is vanishingly small. This isn't such an extreme case, but `compileTime` is really very verbose for something that may become moderately common in Swift source, and I find it hard to believe it would make anything more clear except for the very earliest encounter of the feature, which is _not_ what we should be optimizing for (and even then, it really doesn't tell you what you need to know, you still need to look it up to understand).

I understand and agree to an extent with the argument of pragmatism. However, I think the pragmatism of clear and distinct meaning should take precedence over that of less verbosity. As many upthread have pointed out, "constant", which "const" is short for, is too close in meaning in English to "immutable". This in my opinion makes the feature less teachable if we use the `const` spelling, because both "constant" and "immutable" have been used in documentation to describe `let` properties/values/declarations.

A search for "constant" in the latest TSPL shows 340 result:

 ![Screen Shot 2021-12-02 at 21.00.26](https://global.discourse-cdn.com/swift/original/3X/e/7/e7a58f6bf1219018dcff0bcaa78c5077d83c4a1b.jpeg)

I did not check each of the 340 results, but all those that I checked use "constant" for `let`. Meanwhile, "immutable" only shows up 3 times:

 ![Screen Shot 2021-12-02 at 21.10.52](https://global.discourse-cdn.com/swift/original/3X/e/d/eda47196de698d908a7eb4b186ef9b9168dc6333.jpeg)

This shows a clear history of "constant" being used as the primary description for `let`. It will be difficult for people new to the language to learn that even though we call `let` "constants", we only write `const` for some of them in code, and they are treated differently from other "constants", because they're `const`. Even for people already familiar with the language, `const` in my opinion still messes with the mental model _after_ they have learnt about it. Because although writing in Swift is not writing in English, your understanding of the English word still seeps in when you use the word.

I agree with this statement from you:

> [@ben-cohen](#):
>
> `const` is to `constant` as `func` is to `function`

but I think it's somewhat off the point.

I believe what many of us are saying isn't that we want longer keywords, but keywords that disambiguate from existing usage. The difference between the pitched feature and `let` is not the constant-ness, but the compile-time known-ness of the constant-ness. This is why keywords like `compileTime` and `predefined` are suggested as alternatives. If they are too long, then they can be trimmed shorter, but whether they're in long or short forms, they're more clear than `const`.

And here is a counter-example: `def` is to `define` as `const` is to `constant`. Although `def` is shorter than `function` (and `func`), just as `const` is shorter than `compileTime`, it shouldn't be a more pragmatic choice than `function` is, because it doesn't disambiguate from other declaration keywords.

---

_[View the full topic](https://forums.swift.org/t/pitch-compile-time-constant-values/53606)._