What don't you like about V / what would you like to be changed?

[medvednikov]

After 0.4 0.6, we'll be going for 1.0 right away, freezing the syntax, similar to what Go did.

So if something has to be changed, now is the time to do it.

Please post your criticisms of V, there's a good chance that things you don't like will be fixed/improved.

[danieldaeschle]

What i like:

• Error handling
• sum types and smart casts ;D
• the way how it is developed (community etc)
• all what is not in my changelist

What should be changed imho:

• remove fmt space before ? on my_fun() ? - it's still ugly in my eyes.
• We need better approaches for option types / initialize option types as variables (would be good for empty sum types): x := ?Expr(none) instead of x := Expr{}
• Make option types generic (e.g. generics in builtin). Joe said that works even with cached modules. So i would go for it!
• we need a language specification
• A better name for "option" since it's called both "optional" and "option". i don't like any of them. in haskell it's called "Maybe", but there are other good words as well.
• error codes for our errors (diagnostic information: error codes #7290)
• Error nodes instead of exit on error in parser (poisoning PoC: poisoning #7236)
• test code coverage (Add code coverage functionality #7249)
• custom attributes (Proposal for typed attributes #7014)
  • use them in vweb / http/server
• remove all compiler magic in vweb and make them V features
  • vweb shouldn't require init_once (and the other method) methods. it should be optional. could be fixed using an is check functionality in vweb code
  • I've made a webframework once. So i know some design priciples and can help there
  • finalize the vweb template i've made some time ago
  • replace $vweb.html() with a more generic method (i think we have something there, right?)
  • once i talked with spy about how compile time functions work. he said that it's a really big hack how they work. maybe we can reinvent them?
• we definitely have to change how if and match expressions are generated. (cgen of match expr #4401, result should be true, with autofree result is false #7337)
• println should have an argument of an interface Stringer or something (which has the .str() method). the we can remove compiler magic on print functions.
• we need closures soon

i hope i covered everything. otherwise i will extend this list.

[lammel]

Thinking more about it, I think merging optional results for error handling and trying to reuse that for option types should be separated. This will make it easier to make option types more generic and easy to use.

[crthpl]

we need a language specification

won't that come from freezing the syntax anyway?

[JalonSolov]

It will certainly be easier to write once the syntax is frozen. I shudder to think of the amount of extra work it would have taken to create the document first, then keep it in sync with all the code changes.

[ZargorNET]

I am really agreeing with you on the first two points! I hope they make it into the final language, because the ? with a space before it, seems really off there like a mistype and Expr{} intuitively seems like a struct that is initialized but empty.

And to the error code thing, one could consider making a Rust-like system where the error id is referencing/linking on a webpage, where all codes are listed with some basic examples. See here

[medvednikov]

the space before ? will be removed

[div72]

@danieldaeschle's list is quite well, however I still have a few things to ask for

For V itself:

• Error handling for multiple statements ({ os.read_bytes('a') os.read_bytes('b')} or { panic('!') })
• Ability to drop {} for single statements in or blocks (os.read_bytes('a') or [byte(0)])
• Shortcut for panic (os.read_bytes('a')!)
• Better checks for when reference heavy code is used
• Operator overload for ==, <, >, >=, <=
• sets and the ability to use ranges outside for loops(also step with ranges)
• (if possible) Generators
• Easy binary serialization

For vlib

This portion could be done after 0.3 as no syntax changes are needed. Just wanted to see your opinion.

• os.Path, or something like python's pathlib
• Windows Registry module
• Improvements for the log module(like logger names for example)
• Better support for compression types

[danieldaeschle]

but the syntax has two variants anyway. still against one-way.

[cristian-ilies-vasile]

{} - help detecting begin/end of scope. Are OK.

[JalonSolov]

... and that makes it faster to parse, which is always good.

[spytheman]

What do you mean by compression types ?

[Delta456]

Operator overload for ==, <, >, >=, <= is implement now 😄

[pavi2410]

I would request you to reconsider default function arguments. It has a lot of utility while avoiding code duplication. This will specially help as there is no function overloading. This will also make the standard library less bloated.

[lammel]

Mixing positional and named arguments is never a good idea IMHO. For me it reduces readability of the code and will make tooling a lot harder.

[wanton7]

Related Go info

golang/go#21909 (comment)

This feature was deliberately omitted. See the discussion in talks/golang.org/2012/splash.article about default arguments. They are a bad idea as they make it much easier to build confusing functions that complicate the API.

https://talks.golang.org/2012/splash.article

One feature missing from Go is that it does not support default function arguments. This was a deliberate simplification. Experience tells us that defaulted arguments make it too easy to patch over API design flaws by adding more arguments, resulting in too many arguments with interactions that are difficult to disentangle or even understand. The lack of default arguments requires more functions or methods to be defined, as one function cannot hold the entire interface, but that leads to a clearer API that is easier to understand. Those functions all need separate names, too, which makes it clear which combinations exist, as well as encouraging more thought about naming, a critical aspect of clarity and readability.

One mitigating factor for the lack of default arguments is that Go has easy-to-use, type-safe support for variadic functions.

golang/go#12854 (proposal: spec: type inferred composite literals)

[timbasel]

Maybe using anonymous structs could mitigate this.

fn create_button(text string, { active bool, raised bool = false }) {
     // `text`, `active` and `raised` defined
}

create_button("name", { active: true, raised: true }) 

It would work in exactly the same way as config ButtonConfig does, in that it is just another positional parameter, but it would define the struct fields in function scope.

And if you want to have it as a struct, you could just add a name in front.

fn create_button(text  string, config { active bool, raised bool = false }) {
     // `text` and `config` defined
}

[ken0x0a]

I think, config structs with Editor extension can be a solution for this.
hover action, auto completion, suggestion, e.t.c,

Of course, python like function arguments is super flexible and nice sometime,
but that make multiple ways, and add complexity.

Don't give us preference.
Stick to one way is much easier to read, understand, and write.

I love Vlang's simplicity, so I prefer not to provide another way.

[rempas]

Maybe using anonymous structs could mitigate this.

fn create_button(text string, { active bool, raised bool = false }) {
     // `text`, `active` and `raised` defined
}

create_button("name", { active: true, raised: true }) 

It would work in exactly the same way as config ButtonConfig does, in that it is just another positional parameter, but it would define the struct fields in function scope.

And if you want to have it as a struct, you could just add a name in front.

fn create_button(text  string, config { active bool, raised bool = false }) {
     // `text` and `config` defined
}

Yeah but this will create a struct right? Which will be slower than If we had normal arguments. Also in the name of an anonymous struct, how would we access the fields? Just with their names as if they were variables? You can start to see the weak points of this approach... It's much more complicated to design and implement and it will result in a slower program.

[cristian-ilies-vasile]

My very subjective ideas are:

//A constants declaration
as is

const (
	pi    = 3.14
	e     = 2.718281828459045
)

to be

const {
	pi    = 3.14
        e     = e_init()
}

//B << operator
<< operator does not fit at all in the language philosophy

// C logical operators
as is

!      logical NOT
&&     logical AND
||     logical OR
!=     logical XOR

to be

NOT    logical NOT
AND    logical AND
OR     logical OR
XOR    logical XOR    

[Cons-Cat]

I love the third point, you guys should rethink. Nobody writing && thinks "double ampersand", just make it readable.

Typescript's sum type syntax (by extension V) uses & and | for "intersection" and "union" which are often named "and" and "or" in other contexts. The symbols make that less confusing because the only words in a sum type definition are type names, but the logic behind that doesn't make sense when & and | do not represent and and or. V doesn't have intersection sums, and maybe it never will, but it does have union sums.

EDIT: Just occurred to me that bitwise operators are another point for consistency.

[gustavofo]

I love the third point, you guys should rethink. Nobody writing && thinks "double ampersand", just make it readable.

Typescript's sum type syntax (by extension V) uses & and | for "intersection" and "union" which are often named "and" and "or" in other contexts. The symbols make that less confusing because the only words in a sum type definition are type names, but the logic behind that doesn't make sense when & and | do not represent and and or. V doesn't have intersection sums, and maybe it never will, but it does have union sums.

EDIT: Just occurred to me that bitwise operators are another point for consistency.

You have a point about consistency, leaving it as a syntactic sugar at least sounds good.

[Wajinn]

This has a point in the context that the & and != are used in various ways in V. So not, and, or, xor could make a greater distinction in usage and clarity. The thing is, maybe ! , &&, ||, != has already taken hold too deeply (in addition as a carry over from C style thinking) .

[Kyllingene]

V really isn't trying to be the next Python, so changing all the boolean operators to be words seems out-of-place. From my experience, V is trying to be more like the good parts of C mixed with the good parts of Go. I use Python regularly, but still prefer the && syntax for languages like this.

[medvednikov]

const() blocks have been removed
now it's just

const x = 0
const y = 1

easier to grep + one way

[danieldaeschle]

Something like pythons python -m mymod to execute installed modules.

[pavi2410]

A special __main__.py file is executed for python.

I hate this thing. Makes it so complicated.

[div72]

@spytheman That's for running the file normally python script.py vs import script

[Delta456]

I think the function should be init.

[div72]

I am very against making the function init, init is reserved for module imports so it would conflict with that.

[danieldaeschle]

Path to the main module in v.mod like
path: cmd/v

[Ekopalypse]

What are you thinking about chained comparison?
Like x < y < z

[danieldaeschle]

i think we forbid this with a reason.

[Ekopalypse]

Do you know the reason?

[danieldaeschle]

too complex

[Delta456]

It can be unreadable and also goes against one way of philosophy.

[hernaneche]

Why not initialize with simple = automatically at first appearance, instead of requiring := ?

A thing that I find somewhat contradictory is to need types "after varname", except when using mut, which has to be "before varname".

Why not let the types come before or after the var name, as a user choice rather than a required order?

[div72]

Disagree with the second point, makes parsing more complicated and is against the one way rule.

[JalonSolov]

And types are always "after varname". Adding mut in front doesn't change that.

[Kyllingene]

When the compiler can always tell when you should have a := instead of a =, it seems to me that the := operator is redundant.

[larpon]

When the compiler can always tell when you should have a := instead of a =, it seems to me that the := operator is redundant.

:= is declaration
= is assignment

So they're not the same thing.

I find it extremely useful (especially for your mental context) to be able to tell the difference.
When debugging large code bases it really makes a difference IMO.

By simply looking at a := b or a = b your know instantly if a has been used/referenced before the line you're looking at.

[dedesite]

I understand the need to differentiate declaration and assignment, but in a language like V with multiple assignment possible it is sometimes problematic.
For example, it is not possilbe to do that:

mut a := 10
a, b = 20, 30

or that :

mut a := 10
a, b := 20, 30

Ok I can use a temporary variable... :)

[finomeng]

hello all, really thanks for the excellent language!

I am working on Linux kernel (with real-time extension: Preempt-RT or Xenomai )and driver development for hard real-time control system, so I hope V to be a "modern C", can 100% replace C in low level , the first layer over hardware.

the missing part:

*) Data structure alignment: support enforce data structure padding&packing&align manually. This feature is need due to hardware's register are fixed already, software need follow the hardware spec when define a struct/array for register set. Also need by cache line fits.

https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Common-Type-Attributes.html#Common-Type-Attributes

*) sperate API for creation of real threads and co-routine: real threads are needed by time critical code (e.g. hard realtime OS); co-routines are for non-realtime code.

nice to have if possiable:

*) stack size estimation at compile time:

maybe with certain limits (e.g. don't allow variable logic arrays, disable recursion...), stack size can be estimation at compile time, avoiding stack overflow and gain good performance by avoiding dynamic stack size allocation (as Go's design);

performance is important for hard real-time system (Preempt-RT Linux, Xenomai, Vxworks and other RTOS), latency/jitter is < 10us on a fine tuned x86_64 CPU, so they need avoid dynamic memory allocation in the realtime loop.

various embedded system with small memory may also benefits.

Thanks & best regards,

fino/

[lammel]

The keywords for async operations based on a dedicated threads should be readable and self-explainatory.
Words that may be used are probably async, go, coro, thread and some more.

// For co-routing use go or async
go { println("run in co-routine scheduler") }
// For threads use a dedicated keyword (may require params or attributes)
thread { println("run in dedicated thread') }

But for 0.3 there will be quite some experiments and discussions I guess.

[KeyWeeUsr]

I would rather not see go as a keyword. Seems to resemble a goto keyword with a rather contradictory functionality and async/await is much more used nowadays, so the switch between languages would be way more seamless.

[JalonSolov]

go is used in the Go language to spawn goroutines (co-routines), so similar idea, and it is another statically-typed language. Both Go and V also have goto.

The languages that use async/await are dynamically-typed languages.

It all depends on which type of language you are more used to used, as to which you prefer.

[dedesite]

async/await is not about dynamically or statically type languages. It is just not the same feature as co-routines.
async/await allows you to easily manage asynchronous execution on the same thread, whereas co-routines create a sub thread.

[wanton7]

@JalonSolov

The languages that use async/await are dynamically-typed languages.

First language to have async/await is C# and it's surely not a dynamically-typed language.

@dedesite

async/await allows you to easily manage asynchronous execution on the same thread, whereas co-routines create a sub thread.

That is completely up to the implementation of async (scheduler and runtime). For example with C#'s default scheduler when async yields and returns it can return using a different thread.

[evs-chris]

My personal list from what I've found playing around, beyond what I've seen above:

• Multiple type parameters, preferably with constraints
• A more compact and connected function type syntax

A bit more iffy:

• The ability to use universal call syntax with locally defined or imported functions for imported or built-in types e.g. define map for the option type and call it against an optional.

[penguindark]

'Gated' arrays
I prorose to add the #3008
negative indexes using a tag before the array symbol:
The "new" proposal is to add # before the square bracket in the slice to use the slice with negative index and boud safe as described before.

a:='0123456789'
assert a#[..20]=='0123456789' // true
assert a#[-20..]=='0123456789' // true
assert a#[-4..20]=='6789' // true
assert a#[20..]=='' // true, it never return an error, it return an empty array.

a[-4..20] ==> ERROR
a[20..] ==> ERROR // without gate symbol the behaviour will be the usually

where the # symbol can be the indicator for "safe but slower" operations 😉
The symbol must be decided.

[Delta456]

Or I think we can allow negative indexes inside unsafe:

a:='0123456789'
unsafe {
     assert a[..20]=='0123456789' // true
     assert a[-20..]=='0123456789' // true
     assert a[-4..20]=='6789' // true
     assert a[20..]=='' // true, it never return an error, it return an empty array
}

a[-4..20] ==> ERROR
a[20..] ==> ERROR // without gate symbol the behaviour will be the usually

[abdulbadii]

Excellent!

[ntrel]

@Delta456 unsafe should be kept for memory-safety only, otherwise you will get unchecked memory-safety when using it for other reasons.

[igotfr]

it would better a behaviour like Python for negative numbers in Ranges

[JalonSolov]

No, it wouldn't. At the very least, a lot of extra runtime checks that aren't there now would have to be added.

[penguindark]

Struct Memory Layout
Mantain the memory layout of the structs:

Struct A{
 a int
 b int
}

Struct B{
 a f32
 b int
}

v1 := A{b:1} // A b's displacement  in memory is 4
v2 := B{b:1} // B b's displacement  in memory is 4

This feature is needed to use V for low level in OS and system programming

[danieldaeschle]

i don't get it?

[penguindark]

In simple words: to preserve the order of the vars in a struct like they are written in the declaration.

[larpon]

Yes to avoid padding memory

[spytheman]

I think V already preserves it 🤔 . Is there something I am missing?

[elimisteve]

Yeah I thought V already worked like this.

[insberr]

It would be nice if you could do something like import './path/to/some/file.v' to import a file as a module.

[spytheman]

In V, you always import whole modules, NOT single files.

[jordan-bonecutter]

As a V noob, how would one import a module in a remote directory?

[KeyWeeUsr]

I'm not quite sure what would be the use-case though except that "Go has it". Relying on Internet to be there so that you can import a remote module isn't the smartest thing to do. Intranet however might kind-of work, but from my experience that's even less stable than Internet (especially with proxies/VPNs), so imo just use curl/wget and import the normal way.

[insberr]

@spytheman

In V, you always import whole modules, NOT single files.

Maybe path to folder where the whole module is located?
So importing a whole module, but being able to specify the directory it’s located at?

Like for a module named example
import './path/to/module/example'

[Cons-Cat]

Maybe an attribute that allows mutable fixed-length arrays? I feel that in some cases, being able to confidently assume that an array is on stack and has a fixed length can make data easier to reason about. So perhaps:

[fixed]
mut arr := []int{ 2, 0 }

arr[0] = 4  // valid
arr << 4    // compile error

[spytheman]

Fixed arrays on the stack can be modified, for example:

mut f := [1,2,3]!!
f[0] = 10
eprintln('f: $f')

[spytheman]

also attributes inside function bodies look weird and will complicate parsing

[Cons-Cat]

Ahh, that's really cool! The !! doesn't seem to be in the docs, but it works in my command prompt. I did get this error:

>>> eprintln('f: $f')
cgen error: could not generate string method void_str for type 'void'

It looks like it does work this way:

>>> println(f)
[10, 2, 3]

And then attempting to push an element gives an unexpected kind of error, but that's okay. I don't usually care about whether I have a correct type of error if I know it shouldn't work either way.

>>> f << 23
error: invalid operation: shift of type `[3]int`
    7 | mut f := [1,2,3]!!
    8 | f[0] = 10
    9 | f << 23
      | ^

Thanks for the info!

[litenite42]

iirc, !! is a shorthand that is supposed to be removed at some point. It was a hack from the very early days of V. Maybe Alex's view on this has changed since last I saw on Discord though.

[fnetX]

I know this might create a heated discussion, but I'd love to be allowed to use

if (a == b) {
  //
}

.

I know this is against the "one way to do things" philosophy and I completely understand that point of view and the reasons for not allowing this, but I think most people are used to doing it this way and probably all or most new V developers will run into this 'feature' of V. We're a team and just checking if V is for us, and all of us are annoyed by this behaviour. In our opinion it also makes sense to wrap a condition in brackets.

By the way, why is this possible:

fn main() {
	a := 3
	b := 3 
	if a == b && b > 2 {
		println("yo")
	}
	if (a == b) && b > 2 {
		println("yep")
	}
}

? The brackets aren't necessary - but they do improve readability. And I know cases where there will be an improvement to readability when you wrap one single condition in brackets as well.

So I propose: Please allow brackets around conditions, even if they are not necessary.

Thank you a lot for that nice language nevertheless!

[medvednikov]

@lammel yes, vfmt will keep the newlines.

@fnetX the new generation of languages uses if x {: Go, Rust, Swift.

if (x) { was used only because one statement blocks could be defined without {}. There's no need in () now, and it's important for gofmt/vfmt to remove the unnecessary parentheses so that people coming from C/C++ adapt to this style. Especially for V, with its obsession over "one way".

Click on "format" in the Go playground:

https://play.golang.org/p/TyiiZyneHbE

Do you mean it can already be allowed right here

I meant to say that I'm ok with removing this error, and shifting this entirely to vfmt, just like how it works in Go.

[fnetX]

if (x) { was used only because one statement blocks could be defined without {}. There's no need in () now, and it's important for gofmt/vfmt to remove the unnecessary parentheses so that people coming from C/C++ adapt to this style. Especially for V, with its obsession over "one way".

Oh, that makes sense now! Well, the discussion I intended was actually more related to whether if c {} or if (c) {} should be the preferred way. I can understand that you went for the first one and if devs like me are requested to adapt to that new style, the current way is probably the better one.

I don't really care if the compiler allows the brackets or not, I think it might be a benefit (at leat to give a warning, so as a new V dev you can see if your logic works and correct the formatting issue later ...), but I'm okay if you leave it as-is.

Thank you for considering this and the fast replies!

[Ben-Fields]

If if (((x))) {} is allowed, it should be because parentheses group boolean expressions, and it's slightly confusing to disable that functionality in a certain scenario. As has been said above, I don't think allowing the outside parentheses should be done specifically to accommodate programming styles from other languages.

vfmt correctly keeps the ordering of the inner expressions and even redundant parenthesis in terms of order of operations (ex. if a && (b && c) {}. This is important as the readability of the expression is context-dependent. The only thing vfmt should do that it does not currently, in my opinion, is remove stacked parenthesis (ex. if a && ((b && c)) {} should format to the former).

[wenq1]

Why not let it happen by a simple '-allow-brackets' compiler flag (or more accurately checker flag)?

[Wertzui123]

Because V programs should normally compile and run without any additional flags (as there should only be one way to do something).

[Jarred-Sumner]

Feature request: Overloadable array indexing

numpy's ndarray library is likely a big part of what made Python the most popular language for machine learning/research. It works by representing n-dimensional arrays as a single array where each column has a stride and (optionally) an offset, so pixels[10,2] is actually pixels[20]. This is much faster for large matrices & grids of data than storing multidimensional arrays as arrays of pointers.

If a struct could overload indexing, that would make great syntax for a version of ndarray for v. This is important for machine learning and games where you need to read, write, and iterate through large matrices/grids of data as quickly as possible.

Example syntax:

voxels := ndarray([1,2,3,4,5,6,7,8,9], [3,3,3])

assert voxels[0,0,0] == 1
assert voxels[0,0,1] == 2
assert voxels[0,0,2] == 3
assert voxels[0,0,0..2] == [1,2,3]

For serialization, you often need to support runtime editable strides/offsets, which limits the amount of compiler magic one can do.

[Jarred-Sumner]

In addition to n-dimensional arrays, this would also enable easier access for compressed data. Say you had a run-length encoded array of values (so [1,1,1,1,1,3,3,3,3] is stored as [1,4,3,4]). You could have a struct that lazily decompresses the data, meaning array[2] would return 1 using the same syntax as a normal array without having to decode the entire array.

[elimisteve]

Clever; I like it 👍

[igotfr]

why?

assert voxels[0,0,0] == 1

and not?

assert voxels[0,0] == 1

[MarcusMWilliams]

Nothing

…

On Tue, May 21, 2024, 10:51 AM Alexander Medvednikov < ***@***.***> wrote: x.vweb which is now veb is built on top of pico.v — Reply to this email directly, view it on GitHub <#7610 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASHJW54ZOE765CXXUMDFF7TZDNUORAVCNFSM4VKY2OA2U5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TSNJRGA2DKNY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mike-ward]

There are two ways to increment a number

num += 1
num++

Personally, I never liked the ++ syntax but more to the point, does this not go against the, "only one way to do things" philosophy?

New here so maybe this has already been discussed?

[JalonSolov]

"only one way" is the preferred method. However, some allowances are made for very common constructs everyone is used to seeing.

Similar to the current discussion about adding ^ or ** to mean "raise to the power of", like 2 ** 2 == 4.

Adding this doesn't mean math.pow(2, 2) == 4 is going to go away.

[Wajinn]

Agree that V developers shouldn't trap themselves ideologically versus taking a practical approach when needed. Many users will appreciate the other core philosophies of simplicity, readability, and/or maintainability being factored in when making a decision.

[mike-ward]

Formatting request: Align multi-line struct initializers

Current:

return Args{
	bytes: bytes_arg
	follow: if f_arg { 'descriptor' } else { follow_arg }
	lines: lines_arg
	max_unchanged_stats: max_unchanged_stats_arg
    }

Desired:

return Args{
	bytes:                bytes_arg
	follow:               if f_arg { 'descriptor' } else { follow_arg }
	lines:                lines_arg
	max_unchanged_stats:  max_unchanged_stats_arg
    }

or

return Args{
	bytes                : bytes_arg
	follow               : if f_arg { 'descriptor' } else { follow_arg }
	lines                : lines_arg
	max_unchanged_stats  : max_unchanged_stats_arg
    }

[medvednikov]

This has been implemented.

[mike-ward]

Another formatting request: Align match branches

Current

multiplier := match s.to_lower() {
	'k' { kilo }
	'kb', 'kib' { kilobyte }
	'm' { mega }
	'mb', 'mib' { megabyte }
	else { return none }
}

Desired

multiplier := match s.to_lower() {
	'k'         { kilo }
	'kb', 'kib' { kilobyte }
	'm'         { mega }
	'mb', 'mib' { megabyte }
	else        { return none }
}

[louis77]

Also, is your example a bit fallacious?

No, I see such examples every day.

When and where exactly will there be that "long scenario" of yours used with the purpose to discredit the premise? Are you are using the exception, that probably can be refactored to validate your argument? Let's put our conscious before our ego and see what is better instead of criticizing whatever is different, please.

At least I try to validate my argument, and not just argue "mine is better". I'm sure you don't want me to paste screenshots from work, but I'm a professional coder for 25+ years, many languages and I see edge cases so often that I'm aware that there is no such thing as "it should be this way".

I see your point. I can see those "switch cases" in production as well now that I have another thought. Still we can be open to this suggestion, it needs a thought for more cases like the one you mentioned that makes it more complex, since it'd probably be better to move to another line if such cases are so long/many that there is a need for scrolling.

Again, I'm not arguing for a specific formatting style, but to raise awareness that Version Control and diff tools should be taken into account. Nobody wants to mentally extract changes in commits that are 95% re-formatting and 5% actual code changes. Go does exactly what you proposed, with Struct tags and it is very annoying to see these reformattings in commits. However, there is a way to break the re-formatting distance when you put a newline in between fields. Maybe that would be something that could work here too:

multiplier := match s.to_lower() {
        'and-now-we-have-that-really-long-special-case' { zintyllas }

	'k'           { kilo }
	'kb', 'kib'   { kilobyte }
	'm'           { mega }
	'mb', 'mib'   { megabyte }
	else          { return none }
}

So, what do you think?

[mike-ward]

Interesting compromise with the line break. I like it.

[medvednikov]

@louis77 looks good to me.

[StunxFS]

I see your point. I can see those "switch cases" in production as well now that I have another thought. Still we can be open to this suggestion, it needs a thought for more cases like the one you mentioned that makes it more complex, since it'd probably be better to move to another line if such cases are so long/many that there is a need for scrolling.

Again, I'm not arguing for a specific formatting style, but to raise awareness that Version Control and diff tools should be taken into account. Nobody wants to mentally extract changes in commits that are 95% re-formatting and 5% actual code changes. Go does exactly what you proposed, with Struct tags and it is very annoying to see these reformattings in commits. However, there is a way to break the re-formatting distance when you put a newline in between fields. Maybe that would be something that could work here too:

multiplier := match s.to_lower() {
        'and-now-we-have-that-really-long-special-case' { zintyllas }

	'k'           { kilo }
	'kb', 'kib'   { kilobyte }
	'm'           { mega }
	'mb', 'mib'   { megabyte }
	else          { return none }
}

So, what do you think?

@louis77 If the problem is formatting and diff, then two commits should be made, one with the changes and one with the format.

[mike-ward]

Another option might be to add a // vfmt align on/off to vfmt. This could also work for assignment blocks.

[mike-ward]

Saw this in a twitter post and verified it in V repl

empty := []int{}
mut lists := [empty, empty, empty]
lists[0] << 5
println("Result: ${lists}")
Result: [[5], [], []]

Is this expected behavior?

[TheOnlySilverClaw]

I take it your question is whether empty should be mutable?

I think the important part here is that your lists does not contain the actual empty, but a copy of it.
Therefore, the immutable variable isn't mutated.

For comparison:

>>> mut l1 := [1]
>>> mut l2 := [2]
>>> mut lists := [l1, l2]
>>> lists
[[1], [2]]
>>> l1 << 3
>>> l1
[1, 3]
>>> lists
[[1], [2]]
>>> lists[0] << 4
>>> lists
[[1, 4], [2]]
>>> l1
[1, 3]

[kimi996z]

structural concurrency

[pd-giz-dave]

This says it all:

module main

// compile error: incompatible initializer for field `f`: expected `[]f32`, not `[]f64`
struct Awkward {
	a []f32 = [1.0, 2.0]  // the compiler ought to be able to deduce that 1.0 and 2.0 are f32 not f64
	b []f32 = [f32(1.0), f32(2.0)]  // unnecessarily verbose
}

fn main() {
	s := Awkward{}
	println(s)
}

[medvednikov]

@pd-giz-dave indeed you only need [f32(1.0), 2.0], vfmt should update it.

@TheOnlySilverClaw I'm not a fan of it either. What would you suggest? []f32([1.0, 2.0]) ?

[TheOnlySilverClaw]

As a side note, I was about to complain about fixed array initialization, but after checking the current documentation, I like the current proposal.

So I don't see why it should be more complicated than

f32_array := f32[1.0, 2.5] 

fixed_f32_array := f32[1.0, 2.5]!

I think fixed array would have been a better place to use the # symbol instead of whatever purpose they are supposed to serve with negative indices, so it could be

fixed_f32_array := f32#[1.0, 2.5] // type is [2]f32

But that's not a hill I'm gonna die on.

I also think the initialization syntax could be replaced by some generic functions and using vargs/update syntax.
Then instead of

large_array := f32[] {len: 1000, cap: 3000, init: 3.0}

it could be

large_array := [...f32(3.0).repeat(1000), ...f32(0.0).repeat(2000)]

where repeat is just a helper function returning an array of the same item.
It's arguable a little longer, but you gain the freedom of placing your initialized items anywhere you want.

And since all values are known at compile-time, this could be adapted to a fixed array:

fixed_large_array := #[...f32(3.0).repeat(1000), ...f32(0.0).repeat(2000)] // type is [3000]f32

But those are just some quick ideas. I'd actually have to experiement with the current options, library functions and what the actual memory layout ends up being to make a more educated suggestion.

[JalonSolov]

One minor thing... the syntax for initialization of a dynamic array is slightly different from what you have. It should be

large_array := []f32{len: 1000, cap: 3000, init: 3.0}

[JalonSolov]

If you don't want to do any special initialization, just create an empty array, it is a simple as

large_array := []f32{}

[TheOnlySilverClaw]

@JalonSolov Yep, I was in a rush and always mix those up...

[suvendusamanta]

I landed in V world to cover the shortcomings of Go. I am a 'data scientist' professionally and explore many languages as alternatives to Python. I like the following feature of V which I miss in Go.

1. REPL
2. Using operator as function (operator overloading) - limited but I can understand the design choices
3. Sum type
4. Emphasis on functional programming - extra 'mut' keyword to make mutable variable, immutable functional argument by default etc.
5. Default struct values - as a substitute to default function arguments
6. struct updates
7. Generics ( Now Go supports too)
   ... and many more.

My opinion on the downsides are :

1. Don't like V's deviation from minimalistic design. It's loaded with tons of features. I understand that It's a trade-off between flexibility and simplicity. But I want to see it as more of a simple language(like Go) than a flexible one(like Nim, D etc). Again it's just a matter of my personal taste and why I am here)
2. Lots of 'Atributes' to modify behaviours of functions and struct ( similar to Python decorators) make V program complex.
3. Union, Sum type and Enum can be brought into a single feature/type.
4. The 'pub', 'mut' modifiers inside a struct are adding more complexities
5. Emphasising how small the compiler or generated executables are not valuable much for most cases (except embedded systems ). Rather the creator(s) should emphasize other thing in designing the language.

Though I decided not to use V for 'machine learning' library development due to it's complexities ( bugs or partially implemented features will improve over time), I feel V is nice language to work with.

[Avey777]

Machine learning is the present and the future! This should be given enough attention in V

[medvednikov]

Thanks for the feedback.

I feel like having smaller simpler features for union, sum types, and enums is easier than having one big super feature. Each one only does its own isolated thing, Unix style.

What would be an alternative to pub mut? We can't go with Go's capitalization.

Having a smaller compiler and binaries is great, it's only one of the features. We don't call it the most important one, but why not mention it if it's there.

Attributes like direct_array_access are mostly for low level stuff where people need that kind of flexibility. How would you implement this differently? A context?

[mike-ward]

Everything should be made as simple as possible, but not simpler. Albert Einstein

I think V gets it about right when it comes to simple.

[hellolio]

Everything should be made as simple as possible, but not simpler. Albert Einstein

I like this sentence
The practicality should not be abandoned; we need to strike a balance between simplicity and practicality.
Can this sentence be considered as the philosophy of V?

[medvednikov]

@hellolio for sure :)

[yerlaser]

For me the current show-stopper is the automatic download of tcc binary compiler when building from source.
I am on a corporate laptop and downloading binaries is a no-go for our IT department and automatically triggers an alert.
Can you make it optional? Or opt-out with a question during configure/build or a switch?
I already have a fully working GCC compiler set.

[JalonSolov]

Yep... as long as there is one, which isn't guaranteed. You can make it use a specific compiler if you wish

CC=gcc make

Of course, that relies on you having gcc installed already. Substitute clang for gcc if that is your preference. You can also set VFLAGS='-cc gcc' or VFLAGS='-cc clang' in your .bashrc or whatever so that it is always set when you run V, and you never have to use tcc.

Not recommended, but an available option.

[yerlaser]

Unfortunately, that only works when compiling V files, but not the V itself. Hence my post.

[JalonSolov]

CC=gcc make works when compiling V itself. If the env var CC is already defined on your system, it should work with only make, as it will use CC from your env. This is why make takes longer to build V the first time... it doesn't use tcc.

Setting VFLAGS makes V use that when compiling all other V code. Including V itself, after the initial make. This will make all V compiles slower.

[yerlaser]

In #17951 you said:

tcc will still be downloaded, but never used.

The Makefile hasn't been altered for two years.

[spytheman]

The Makefile hasn't been altered for two years.

The Makefile is for the BSD versions of make. The GNU versions of make (that most linux distros use, and that you can use by installing gmake, even on BSD systems), use GNUMakefile, and that has support for building a lot of different versions of V. The same is true, for make.bat, which is used on Windows.

[pd-giz-dave]

I find fixed size array handling frustrating, e.g.

module main
fn main() {
	mut fixed := [2]int{}
	fixed = [1,2]
	println(fixed)
}

results in a compiler error of: "cannot assign to fixed: expected [2]int, not []int"
Surely the compiler can see [1,2] is in fact [2]int

[medvednikov]

The error should be better.
You need to use fixed = [1,2]!

[pd-giz-dave]

I've just noticed that extended syntax in the documentation...that's great
Is it new?

[medvednikov]

No, it's been there from the start.

[ZeroAurora]

idk but I'm always getting more and more interested in V... I always thought it a toy language for everyone's fun, but now at least it seems that it's a promising tool for me to do toy things.
but one thing always stopping me is that V on Windows is not reproducible, because the tcc is distributed in binary form. I don't really know about other platforms. I already started this discussion but there's no further replies.
Having non-reproducible binaries bundled within a programming language is somewhat pursuading me to quit. It's a trasparency problem, after all. It also stops linux distros from packaging v properly.
edit: perhaps related to this :)

[JalonSolov]

Although V does supply tcc in precompiled form, you can build it yourself if you like. The exact SHA to use is listed on https://github.com/vlang/tccbin - this is where tcc is downloaded from when make.bat is run on Windows.

So it can be as reproducible as you like - you can either rely on the pre-built version, or you can clone the exact version built by V devs and build it yourself locally.

[ZeroAurora]

I don't know of any serious distro that relies on upstream binary releases for packing (but maybe that is not the point you are trying to make?). If source is available they always use that, never an available binary. If only a binary is available, most distros will never have a package for it. Most packages on most distros, there is no upstream binary release. In the open source world, outside of this Linux, this includes the BSDs. Lack of upstream binary. FreeBSD packages v, and it does not include tcc. In FreeBSD v is available through the standard pkg installation method. https://www.freshports.org/lang/v/#history I installed v on FreeBSD and also built from the provided ports pkg source. tcc was not downloaded or used, and tcc is not on my system.

@bogen85 Your talking is what I want to say. Having binaries bundled is definitely not desirable on most distros. In some distros binaries are stripped out, but on others the packaging purpose might be denied if no attention was given.

[ZeroAurora]

Although V does supply tcc in precompiled form, you can build it yourself if you like. The exact SHA to use is listed on https://github.com/vlang/tccbin - this is where tcc is downloaded from when make.bat is run on Windows.

So it can be as reproducible as you like - you can either rely on the pre-built version, or you can clone the exact version built by V devs and build it yourself locally.

That would be good but in practice I couldn't even make a usable tcc on Windows, due to lack of a how-to instructions (I tried my best but no luck)

[ZeroAurora]

@ZeroAurora you can build your own version of tcc from source and use it via -cc mytcc.exe

Or just use -cc gcc

@medvednikov I'd like to ask if there is a make-time configuration to avoid using tcc at the very start, and how can I persist these options (better to mention it in doc I think)

[medvednikov]

@spytheman I think there's a way to do this with make

[andrew-wmg]

Please add ROR/ROL circular shift (rotate) operators alongside left and right shift operators. As a bare-metal programmer, I find this very useful and the lack of these operators in C is a pain. In C you have to use different hacks, such as Inline asm or compilers intrinsics like __builtin_rotateleft8 for Clang or __rolb for GCC. These methods do not help to write portable code. Of course, you can write a function for this and pray that the compiler is smart enough to optimize rotate_left_8 in one instruction. Alternatively, you can always check the compiled code. However, it's not a solution. Therefore, the rotr and rotl were added to C++20.

Bitwise algorithms are general purpose tools which can be used in a wide variety of domains and are the key to unlocking high performance in many important algorithms. A bitwise operations library has been badly needed in the C and C++ standard libraries for many years.
We present a bitwise operations library which exposes these native instructions wherever possible and provides backup implementations in C++ if they do not exist.

I think that in any reasonably low-level language like C, circular shift operators should be part of the language. Also, efficient implementation of bitwise operations is a necessary condition for writing performance code.

[medvednikov]

Ok will do.

[hellolio]

I have two suggestions.
1:

// if unwrapping with assignment of a variable
u_name := if v := arr[0] {
    v.name
} else {
    'Unnamed'
}
println(u_name) // John

I really don’t like If unwrapping u_name := if v := arr[0] { ,
we already have or {}.
I hope this language remains simple. it shouldn't have too many features.

2:
regarding interfaces, why should it be like Go: where you don't need to explicitly declare which interfaces are implemented by a type?
I prefer Rust's explicit declaration: impl Fly for Bird

[Wajinn]

I really don’t like If unwrapping u_name := if v := arr[0] { , we already have or {}. I hope this language remains simple. it shouldn't have too many features.

The advantage of V's "if unwrapping" is made more clear when written as an "if expression" (or ternary in other languages).
Instead of multiple lines, it can be written as one line, when doing the variable declaration and initialization. Thus, it can be argued as being very convenient for many and a useful feature of the language.

// Note- this is a modification of the example shown in the V documentation
mut u_name := if var := arr[0] {var.name} else {'Unnamed'}
println(u_name)

[hellolio]

mut u_name := if var := arr[0] {var.name} else {'Unnamed'}
println(u_name)

Or you can change it to or {}:

    u := arr[0] or { User{'Unnamed'} }
    println(u.name)

This approach is more simpler, clearer, and consistent with V's handling method (error-handler uses or {}).
If you can provide an example that can only be written using an if unwrapping and is quite common in development, I would agree with your statement.

[Wajinn]

The "if expression" looks not to be something to remove from the language, because of its usage as a ternary replacement and that it allows else-if chains. If that being the case, removing "if unwrapping" usage as a feature, doesn't seem to make sense. To me, it would be like removing one of the existing ways to write for-loops. Because another way is found to do something, does not mean to quickly remove all other options or those that can be more clearly understood by various users.

[hellolio]

Your answer seems to be saying: "Yes, I bought a piece of clothing, it's not good-looking, and I rarely wear it, but since I already have it, why should I throw it away?"
However, a language is not like clothing, because others will use it, and such code will forever exist in our code repository.
Removing "if unwrapping" would make our code clearer. if would return to its original purpose, and its boundary with or {} would become clearer. When someone sees if, they'll know exactly what it's doing, and when they see or {}, they'll understand its purpose as well—rather than seeing if and thinking: "Does this line return a bool or an error?"

Anyway, I don't think this is a big issue. I just hope that before V reaches 1.0, it improves as much as possible by fixing the bad parts. Once it reaches 1.0, it will be too late

[Avey777]

agree with

[pd-giz-dave]

Something that trips me up is not being able to construct primitive types in the same way as structs, e.g:

struct Object1 {
  member int
}
type Object2 = f32
...
object1_instance := Object1{1}  // constructor allowed
object2_instance := Object2{1}  // constructor not allowed

Is this inconsitency really neccessary?