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

[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?

[enghitalo]

Why do you think it is a inconsitency?

[JalonSolov]

It makes sense if you know that Object2 is an alias of f32. If all you see are Object1 and Object2, it makes some sense that you would expect them to be treated the same.

Personally, I think what V does now it correct - you should know which is which, and the proper way to construct/use/etc. them. In that last example, it would only be difference of using () instead of {} on Object2:

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

[pd-giz-dave]

Its all about abstraction - as such I do not know that object2 is a type alias and do not need to know, all I need to know is that some fucntion I call wants an object2

[JalonSolov]

And that's what I said... why don't you want to know what object2 is? Don't you want to use it correctly throughout the code? If it uses the same "constructor" type without you having to know about it, do you expect it to also have fields like a struct?

[pd-giz-dave]

All access and transformations on object2 are via function calls into a module and only that module knows how its implemented, I as a mere user of the object, do not care how it is implemented.

[JalonSolov]

You shouldn't need to know how it is implemented, but you do need to know how to use it. Otherwise, how do you know if it can be constructed at all?

In an Object Oriented language, where everything is an object, then yes, it would make sense for everything to have a constructor, and be initialized the same way.

V, however, it not an OO language, so doesn't follow those same rules.

(FYI: If you click in the Write a reply box under something else, as I have been doing, it keeps the thread together. By using the Add a comment box, it looks like you're starting a new thread.)

[pd-giz-dave]

Re - write a replay: Thanks for pointing that out, I'd not noticed it before.

V may not be OO but it can get very close with struct methods. (I don't like OO, it hides too much - have I shot myself in the foot here :-)

To me object() is a cast and object{} is creation irrespective of what I'm creating. This is my mismatcn with V maybe?
I realise that object(some_literal) is casting that literal at compile time.

[JalonSolov]

It is a compile time cast. If you only had

object2_instance := 1

you would be setting the variable with a type of int.

If you used

object2_instance := 1.0

you would be setting it as a float. The only way to tell it that you want it to be an Object2 type is to cast it, as in

object2_instance := Object2(1)

[pd-giz-dave]

Its a minor thing to me, I concede :-)

[viocha]

I want to organize the syntactic sugar of other languages (such as JavaScript, Python, Go, Rust, etc.) and propose adding the useful parts to the V language.

[elimisteve]

@viocha Hi there! I'm curious which syntactic features you think should be added to V. I've thought a lot about this as well and it's an interesting challenge.

[viocha]

Unfortunately, you're a bit late to the party.

Most of your suggestions have already been discussed, multiple times, and rejected.

V supports multi-returns. It does not support tuples, and won't. They don't add any useful functionality over multi-returns, especially for a strongly typed, statically compiled language.

V supports math.pow(). It will not support ** as a replacement... it isn't used often enough to give a good ROI (Return On Investment) for the amount of parser/checker changes needed to implement.

Etc., etc.

Now, if you can beef up your suggestions with concrete, verifiable examples as to why V should support such changes, better yet create PRs adding them to the language, they may be reconsidered.

Simply requesting your favorite features from other languages be added to V because you like them is not enough.

I am really not trying to discourage you from making suggestions. It is simply that V is to the point where major syntactic changes will only be made if you can give a thorough, convincing argument as to why they are needed, as opposed to a simple request to add them.

I only decided to propose these suggestions after failing to find relevant issues through my search. It turned out they had already been discussed, possibly due to my inaccurate searching. However, the V language is already good enough now, it's the language I'm most eager to learn and use.

[JalonSolov]

@elimisteve He has created several github issues mentioning features, including tuples, using ** for raise to the power of, etc. Just look at issues entered by @viocha

[viocha]

@viocha Hi there! I'm curious which syntactic features you think should be added to V. I've thought a lot about this as well and it's an interesting challenge.

Such as cascading operator and pipe operator

[elimisteve]

Such as cascading operator>

To cascade what?

...and pipe operator

A pipe operator like this? #3191

[viocha]

Here are all the features I came up with that I consider useful.

• Exponentiation operator

  x=2**3
  y=x**2
  

• Index operator overloading

  x = obj[0]
  obj[0] = 123
  obj[1;3] = [5, 6]
  

• Negation operator overloading

  p = Pointer{1,2}
  p1 = -p
  

• Array negative indexing

  arr#[-1]
  

• Cascade operator

  obj..method()
     ..method()
     ..method()
  

• Pipe operator

  val |> func1 |> func2
  

• Tuple type

  tup = (123, 'hello')
  x,y = tup
  first = tup.0
  

• Array, struct destructuring

  x,y = [2]int{10,20}
  {x,y} = MyStruct{x:123,y:'hello'}
  

• Recursive local functions

  fn outer(){
    fn dfs(){
      dfs() // recursively call
    }
  }
  

• Range expressions with step and inclusive end syntax

  for x in 1..=7..2 {
    // print 1 3 5 7
  }
  
  

• Generator functions

  fn* my_generator() ?int{
   yield 1
   yield 2
  }
  

• Direct support for named parameters

  fn f(a int, b~ int){}
  
  f(123, b=456)
  

• Functional loop, similar to pattern matching

  sum := loop listNode, 0 {
     Nil, sum => break sum
     {val, next}, sum => continue next, sum+val
  }
  

• Derived interfaces: Automatically implement an interface for a struct if all its fields implement it

  • See https://doc.rust-lang.org/rust-by-example/trait/derive.html
  • See https://docs.moonbitlang.com/en/latest/language/derive.html

• Macros and metaprogramming

  • See https://doc.rust-lang.org/book/ch20-06-macros.html
  • See https://cangjie-lang.cn/en/docs?url=%2F0.53.13%2Fuser_manual%2Fsource_en%2FMacro%2Fmacro_introduction.html

[gchumillas]

I think the compiler should enforce initialization of "sum types", since it is very easy to inadvertently change the order of addition, resulting in an unpredictable behavior.

type MyType = string | int
x := MyType{}
println(x) // MyType('')

type MyType = int | string
x := MyType{}
println(x) // MyType(0)

[JalonSolov]

Many people do NOT want forced initialization. 🤷🏼‍♂️

It was only recently that V started initializing to the first type listed. Before that, sum types were not initialized at all, which goes against every other type in V, where V guarantees that things will be initialized to their "default 0" value.

Nothing prevents you from initializing them properly in your own code, but for those who "don't care", at least they will be initialized now.

[xxxserxxx]

I would like to request that the json encoder recognize @[json] attributes set on structs, and to correspondingly serialize and deserialize those instances as an encapsulated JSON object identified by the attribute.

I would like this code to run:

@[json: 'mything']
struct Structure {
   name string
}
k := Structure{'foo'}
str := json.encode(k)
assert str == `{"mything": {"name": "foo"}}'
l := json.decode(Structure, test_]str) or { Structure{"FAILURE"} }
assert l.name == "foo"

A more complex example, this would en/decode:

@[json:'sub1']
struct SubThing1 {
   v int
}
@[json:'sub2']
struct SubThing2 {
  n string
}
@[json:'result']
struct Container {
   subthing SubThing1
   second    SubThing2
}
v := '{"result": {"sub1": {"v": 12}, "sub2": {"n": "owl"} } }'
c := json.decode(Container, v) or { assert fail }
assert c.subthing.v == 12
assert c.second.n == 'owl'

[xxxserxxx]

As an addendum, the IRL use case is for working with APIs whose format I do not control; e.g. the jsonrpc standard, which encodes contents into a json "result" field whose value is a json object containing the type name and the serialized object:

{
  "id": 24
  "jsonrpc": "2.0"
  "result": {
    <type name string key>: <serialzed object>
  }
}

This fact that the <type name string> varies from API call to API call dependent on the result makes this difficult to represent cleanly in V structures. Having the proposed behavior would address -- at least -- the base deserialization. There remains a sum type deserialization problem, but that's a separate consideration.

[enghitalo]

We already have the tag _type if it is the case

[xxxserxxx]

This would still mean writing a custom de/serializer, right? It isn't clear to me how the tag _type helps.

This would result in non-orthoganal behavior; currently, serialization only considers fields and does not serialize types; I'm proposing that if the type itself has serialization attribute metadata, that that metadata would be included in the type serialization. The downside is that it's potentially backwards incompatible. The upside is that it would allow for a richer de/serialization that better supports V's type unions, a feature that is a value-add over e.g. Go.

I question how bad, in practice, the backwards compatability issue would be. It would only be a conflict in code where someone has annotated a type with serialization attributes -- something that is currently ignored and unused and therefore has no reason for anyone to be doing it ... unless they're writing their own de/serialization code, in which case it wouldn't be a breakage anyway.

The value is that it would allow code like this, which I've seen other people asking about:

[@json:'client']
struct Client {
  id string
 }

[@json:'volume']
struct Volume {
   volume int
}

type Payload = Client | Volume

struct Response {
    response Payload [@json:'response']
}

and allow the stdlib JSON de/serializer to correctly deserialize responses such as:

{   "response": { "client": { "id": "abc" } }   }

{   "response": { "volume": { "volume": 123 } }

The implementation seems rather straightforward: IFF the type has a serialization annotation, serialize the field as { <annotation>: <instance> }

While the annotation will probably usually be the _type, this is more flexible: the annotation can be anything, and decouples the actual struct type from the marshalled representation. Perhaps the server calls the field client, but maybe CLIENT or Client or _cilent. Perhaps, for some reason, the code wants to name the struct type RPCClient to avoid naming conflicts, but the json serialization just calls it client.

[changrui]

Comptime match:

fn func[T]() {
   $match T.type {
      int{}
      float{}
      string {}
      else {}
   }
}

[changrui]

We need a internal primary type decimal for Finance usage.

[tigawanna]

Vscode extension for syntax highlighting to work better

[gchumillas]

You can use V-Analyzer:
https://marketplace.visualstudio.com/items?itemName=VOSCA.vscode-v-analyzer

It's not perfect (you have to Reload Windows many times), but it's better than nothing.

I believe that in a language that infers types (omits them), a stable syntax highlighting tool is as important as the language itself.

[timi5691]

I like v have more functions to gg module, add high level api such as: is_screen_touch(touch_id), is_screen_draging, ... to gg module , have music module like sonic pi (https://sonic-pi.net/), and module to create some beautiful vfx for game like explosion, fire, smoke, spark, magic, ...

[Wajinn]

VUI needs more attention, particularly as a featured module on the front page and as something new users would obviously look at. Even just updating the roadmap, would be a good gesture.