Related: #5076
Cons:
cn needs context to be associated with 'constant declaration', while 'const' is self explanatorycn vs fn. not as distinguishable as const and fnconst func = fn(...) Type {} vs cn func = fn(...) Type {}if and cncn vs if/else/switch/whilePros:
cn is shorter than constcn is also shorter than varconst appears very frequently in code.cn and 'constant declaration' will happen quickly for newcomers.cn and const in a transition period, and let zig fmt convert to the new form in the meantime[]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
cn is too long. c is better and isn't China.
So we have v and c? Sounds good.
Or maybe var and con?
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.
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.
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.
Most helpful comment
By the (-1) reactions I suppose
constis 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.