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.

[spytheman]

Groupings impede simple search tools like grep and ripgrep.

[spytheman]

Go also has a few grep and grep-like knockoffs.

They also suck, for the same reason - the grouping syntax just makes certain workflows a lot harder, for not much good reason, beside the aesthetic preferences of some.

[Wajinn]

Speed differences within seconds or fractions of a second, are arguably irrelevant to the task of general users finding what they are looking for, which v where can do (find what's in a const grouping).

If a user has some other specific requirements or preferences, that v where can't satisfy or be modified to address, they could still use those other external tools. In other words, v where and ripgrep (or other tools of a different ecosystem), satisfies both groups versus the creation of division. Cutting off supporters, with either abrupt or arbitrary user facing changes, appears contrary to V's claims or goals of stability, gives a bad look, and narrows the audience it can appeal to.

In regards to ripgrep or other, if a person is already satisfied with using some other tool to find something, it doesn't appear to make sense to then turn around and strip out existing conveniences or preferred functionality in the language, used by a large number (around 45%) of its users. Unless there is something more going on or unelaborated critical necessity.

The attraction of V, for the wider audience, would likely be its built-in conveniences that other languages do not have, V created tools (including the fun of making them), often mentioned readability, etc... That should arguably include being less verbose. To continually take away things in which users and supporters like about V, could decrease its popularity, in an already crowded and very hostile environment. And that seems counter-productive.

[Wajinn]

They also suck, for the same reason - the grouping syntax just makes certain workflows a lot harder, for not much good reason, beside the aesthetic preferences of some.

Yet Go kept grouping syntax in the language. That naturally generates the question of why they did so. They could have just as easily and forcibly, pulled it out. It could be that they made a cost–benefit analysis, where keeping the grouping syntax for users had won.

[jorgeluismireles]

IMHO Golang is different in the sense they use the pattern for "almost everything", next is valid golang code.

import (
	"fmt"
)

var (
	a int
	b float32
)

const (
	c = 10
	d = 32.43
)

type (
	e struct{}
	f interface{}
)

At least, V cannot take advantage of the pattern too much because has no global vars nor the structs are defined using type keyword.

[Wajinn]

V had used this pattern more, but it was stripped away. import used to have it. It was a compromise of the community (or it had appeared to be) to just remove it from import and keep it for const and __global (used with flag), but now it looks to be under siege too.

[spytheman]

Go and other languages have figured out how to do this, why would V go backwards?

They have not. It is a pain to search for stuff in Go projects (for me, I do not know about others), using language agnostic tools.