V: Thoughts on lowercase const names?

[medvednikov]

This may sound like a minor issue, but it's actually a pretty important one.

There will be lots of consts in V code since there are no globals, and consts are a lot more powerful than in other languages.

There are 3 options:

1. ALL_CAPS
   This is great in languages like C, where you can only use it for primitive values.

   But in V half the code base would now be SHOUTING_AT_YOU. And os.ARGS[1] or MY_CONST_ARRAY.do_something() just look ugly.

2) PascalCase
This is the one currently used. It's also used in Go.

I don't like it because, again, it forces to use a different naming style for a huge part of identifiers, and consts can now be confused with types.

Current `os.args` would have to be renamed to `os.Args`, and this doesn't feel right to me.

3) lower_case
The only problem with this is consts are now indistinguishable from variables. But that's already the case with mutable vs immutable variables, and consts are basically just module level immutable variables.

4) ALL_CAPS for primitives (ints mostly), lower_case for everything else

What do you think?

[dcurrie]

If V is serious about immutable by default and consts are the only globals, then these should be the easiest to write and read. The best option is lower case.

[medvednikov]

Also in order to distinguish consts from local variables, full path can be required: println(math.pi), even if it's called from the same module.

[runeimp]

I think ALL_CAPS is great specifically because it would not get confused with variables and types. Additionally, in the case of this language since constants are so much more powerful, I think it helps denote the authority of constants. Mentally I see ALL_CAPS and I expect a constant or environment variable. Both global concepts in most languages. I don't feel it as shouting personally. It just easily demarks what you're dealing with on a conceptual level. It's one of the few things I truly miss in Go.

[joe-conigliaro]

Personally I like Pascal case. But if you don't like that then either all caps or maybe all lowercase but must maybe start with, or start and end with an underscore (_myconst_) or some other identifying marking. because I think they need to be easily identifiable as soon as you see one you should know it's a const right away. Just examples

_myconst
#myconst
~myconst

[ntrel]

BTW os.args shouldn't be a constant, because its contents aren't known at compile-time. os.args should be an immutable global (or a global hidden behind an accessor function call).

[dcurrie]

... because I think they need to be easily identifiable as soon as you see one you should know it's a const right away.

The default is immutable; if there's special syntax for exceptional values it should be for mutable values, not const values. Functions are immutable: all lower case. Consts are immutable: all lower case. Variables are by default immutable: all lower case, unless made mutable. Etc.

[medvednikov]

BTW os.args shouldn't be a constant, because its contents aren't known at compile-time. os.args should be an immutable global (or a global hidden behind an accessor function call).

@ntrel in V that's exactly what os.args is:

fn main() {
  println(os.args)
}

The definition of consts is different in V. They do not need to be known at runtime, they are basically immutable global variables with a defined value.

They could be differentiated, but that would complicate the language, and I don't really see the benefits.

[ntrel]

The definition of consts is different in V

That gives a misleading impression, they should be called globals. I thought V supported compile-time function execution, but it seems those calls are just made before main is executed.

I don't really see the benefits

V could read compile-time constants with $if and $for, you can't do that with immutable globals.

Go allows fixed-size arrays to be declared with a compile-time constant:
https://play.golang.org/p/3t1y4TzFieN
(See #762).

[medvednikov]

Go allows fixed-size arrays to be declared with a compile-time constant:

@ntrel I've just implemented that.

[ntrel]

Ok, great. But there is a difference between compile time constants and immutable globals:

const (arr = [1, 2])
a := [arr.len]int

arr.len can be known at compile time, os.args.len can't. (Also, &os.args can be allowed but not &arr, because arr doesn't need space in the binary). I suggest we have different keywords e.g. const and global.