Low priority proposal: Shorten 'const' to 'cn'

[ghost]

Related: #5076

Cons:

• cn needs context to be associated with 'constant declaration', while 'const' is self explanatory
• cn vs fn. not as distinguishable as const and fn
  • RFC: Make function definitions expressions #1717: const func = fn(...) Type {} vs cn func = fn(...) Type {}
• Syntax highlighting becomes more essential
• No use case requires this kind of syntax change
• "Indentation" is the same for if and cn
  • Might warrant different syntax highlighting for cn vs if/else/switch/while

Pros:

• cn is shorter than const
• cn is also shorter than var
• const appears very frequently in code.
  • Making the connection between cn and 'constant declaration' will happen quickly for newcomers.
  • Makes sense to keep the most commonly used language keywords the shortest
• Grammar change only. semantics stay the same.
  • Could allow both cn and const in a transition period, and let zig fmt convert to the new form in the meantime
  • Very easy to both implement and retract if it doesn't work out
• Immutable slices will look nicer []cn u32 vs []const u32 in that the type will stand out more than the immutability qualifier.

An alternative to cn is df for define, but []df u8 doesn't work, whereas []cn u8 is permissible. Related: #5056

[data-man]

cn is too long. c is better and isn't China.

[ghost]

So we have v and c? Sounds good.

[ghost]

Or maybe var and con?

[SuperAuguste]

I dislike this proposal a lot as const is much more intuitive to the programmer and reader, compared to c, or con, or cn, which could be very confusing, and sometimes hard to spot.

One of Zig's Zens is "Favor reading code over writing code.", and in my opinion, this change would violate that Zen.

[SuperAuguste]

Oh, and it might also violate:
"Communicate intent precisely.", as const is much better at communicating the creation of an constant than the shortened alternatives.
"Only one obvious way to do things." as c, con, or cn aren't very obvious, and adding a transition period would violate this Zen, and maybe even confuse newcomers.

[ghost]

By the (-1) reactions I suppose const is too established by now to be replaced, and it's also perfectly fine to keep it as it is. The issue can be reopened if there's any renewed interest later.

[porceCodes]

Ergonomics view:
var 3 letters, const 5 letters.

var x: u8 = 10;
let y: u8 = 20;   // 3 letter case
const z: u8 = 30; // 5 letter case

let is from Swift

[mlugg]

let has already been rejected: #181