Const Groupings Versus Creating User Inconviences

[Wajinn]

Why would V go down this path of creating more user inconveniences on this issue? This includes forcing users to rewrite and update their code unnecessarily or seemingly frivolously. Please reconsider this issue and keep in mind V's many loyal fans and attracting new users. I've happen to have already read some comments concerning such (groupings and needing to do rewrites).

Groupings just makes more sense than unnecessarily typing the same keyword repeatedly. Especially if V is promoting readability and ease of use. V is such a great language, that it should stay looking nice.

This excessiveness (which is arguably a kind of violation of DRY)...

const a = 1
const b = 2
const c = 3
const d = 4
const e = 'more'

Would arguably look better as...

const (
a = 1
b = 2
c = 3
d = 4
e = 'more'
)

If the argument is to force only 1 way, then this can be done by typing const (a = 1) for single items, where () is always used. In fact, that's arguably the direction that import and __global should go as well.

Understand there can be reasons and are totally sympathetic to developers, but if Go and other languages have figured out how to do this, why would V go backwards? And finally, medvednikov typed he preferred const groupings, so not understanding as to what could have happened.

[medvednikov]

There's no re-writing, vfmt updates const and import groups to the new syntax.

It's much easier to grep for consts and imports this way.

[jorgeluismireles]

By the way we already have v where, so just need to add that functionality.

Is nice to have this tool! Thanks!

In different modules I have several enum ComputerSet and several pub const vid = ....

• This works ok, giving all the related enums by the filter:

$ v version
V 0.4.7 4ee948f
$ v where enum Computer* -dir .
...
...

• This fails (gives a panic)

$ v where enum *Set -dir .
V panic: 
query: .*enum\s**Set\s*.*
err  : --------^
ERROR: err_syntax_error
...

• This gives nothing, I think it should gives whole list:

v where enum * -dir .

• This gives nothing (seems const is not programmed yet, const vid really exists even is pub):

v where const vid -dir .

Is odd, the last fails if I have:

const vid := 0x1a86

But it works ok if I have:

const vid = 0x1a86

[JalonSolov]

The current v where just uses regex patterns. The change Alex is talking about will use the LSP to do a full and proper search based on the parsed files.

For example, const vid := 0x1a86 isn't valid V. v fmt would change it for you, to the correct version of const vid = 0x1a86 as you say works. The new thing would also parse it correctly, as it would do the same substitution as v fmt. A simple regex search, though, can't do that.

And don't bother saying "but you could make the regex work" - there's no reason to even try, with the improvements that are coming.

[jorgeluismireles]

Exactly const vid := 0x1a86 works currently and also const vid = 0x1a86. It think it should force in the compiler the former is rejected, so there was a "single way to write constants".

[JalonSolov]

I believe the plan is to force only the 2nd way, but not yet - don't want to break people using :=.

[JalonSolov]

Although there have also been arguments for making const vid := the "correct" way, because then it matches regular var initialization, such as x := 0.