[Pitch] Compile-Time Constant Values

[wowbagger (冀卓疌)]

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:

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:

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.