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

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

[Jengro777]

#25010

Maybe focus on this issue

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

[axbender]

I'd like to see PREG2 as the standard RE engine (no other libraries tolerated).

[JalonSolov]

That will not happen, but there is now a PCRE module in stdlib. Just do import regex.pcre

[Jengro777]

It is hoped that v can reserve space for a borrowing checker similar to rust, so that v can have its own borrowing checker at some point in the future.
The borrow checker can be used according to the specified parameters.

[Jengro777]

It will. It's going to be optional. I'll have it ready in V2 by March.

This will be my favorite language in V, and the optional borrow checker like Rust will be used where it is most appropriate, especially where both security and performance are required

[Jengro777]

@medvednikov

Does this mean that in the future v can also have a stackless coroutine like tokio?

[elimisteve]

Fearless concurrency can be achieved without the complexity of Rust, as Vale has already shown; more people should be copying these features in their languages! See https://verdagon.dev/blog/seamless-fearless-structured-concurrency

[Wertzui123]

Very interesting article, thank you for sharing!

[Wajinn]

Does this mean that in the future v can also have a stackless coroutine like tokio?

Would like to see V's incorporation of Photon's fast stackful coroutines fully completed.

It will. It's going to be optional.

Will greatly appreciate V's greater flexibility, with having an optional borrow checker.

[de-Beast]

Since lambdas are implemented, is there any chance to remove magic variables such as a, b, it, index? I believe that arr.sort(|a, b| a > b), arr.map(|it| it.to_upper()) and []int{init: |index| index} are pretty acceptable and clear constructs, and there is no need to keep these variables now.

[JalonSolov]

It would "break the world" to remove them. It is also a more complex syntax, and not everyone even knows what a lambda is, let alone how to use them properly.

That said, it may be done at some point, it would just have to be done in stages, with proper deprecation, etc.

[Wajinn]

The counter-argument is that "magic variables" makes the code easier to learn, understand, and use. If V is not going to make itself any easier to use, and cause lots of deprecated and rewrite code headaches, then they should stay.

However, I do have a beef about index versus it. Seems like it should have stayed as it for consistency and because shorter to write. Either change all to index or keep all as it.

[Jengro777]

V After implementing the optional Rust-like borrow checker.
Is it also a good foundation for implementing fearless concurrency libraries like tokio?

[Wajinn]

Sad to say, but think the VUI and GUI situation is frustrating, despite how good the potential of both are. Before I go on, want to make it clear that Mike is doing a monumental and fantastic job.

VUI and GUI have different strengths and weakness. They each do somethings better than the other, but are not complete replacements for each other. I suppose having both is not a problem, as many languages do have multiple options for UIs.

VUI's percentage based box_layout is a hidden gem and fantastic for very quickly building UIs and also rearranging them afterwards. Works on Windows and "kind of sort of" on Android (when tested some time ago), in addition to macOS and Linux. Arguably, in a more advanced state of development, but has stalled. Additionally, many have invested time or coded some things using it.

GUI, utilizing Clay, has: an updated look, thread-safe UI updates, easier view changing, and high development pace. However, Mike has made it clear, that neither Android or Windows is a priority.

Both are arguably not yet ready, which is more an issue for VUI (because of age). But both are likely to be among the first modules looked at, for many new to the language.

[JalonSolov]

The older UI is way behind, and not much has been done on it in quite a while.

However, you need to look at the alternative, which has been improving tremendously...

https://github.com/vlang/gui

It is already so far beyond anything in UI that it will take a massive effort to bridge the gap.

Just check the readme for gui - I think you'll like it.

[Wajinn]

Yes, was typing about the alternative (GUI) to UI (VUI). Also, don't get me wrong, I'm a fan of both GUI and VUI.

The issue is the readiness to be recommended. It's debatably not just a matter of what lead or advanced developers do or have privately, but rather expectations for usage, examples, and documentation to teach newbies of V or newbies of GUI (who may come from or played with VUI).

Mike (on GUI) has explicitly typed that, GUI is maybe not for:

• Production mobile apps (Android and iOS)
• Mobile device support was also asked about on V's twitter/X (no demo yet)
• Native platform widgets (on the flip side - VUI has native widgets support
• Maturity. GUI is progressing rapidly, but will take it a bit to catch other projects, in other languages.
• Windows support appears shaky or questionable (for now)

As VUI was the first official UI, many would have used and made examples with it. VUI is very good, despite the age and has stalled a bit, with it being compared favorably to/over GIO UI (years ago) by coderlyfe (who made youtube videos on VUI).

[xxxserxxx]

Cross-platform support is the deciding factor, for me. If I'm writing exclusively for desktop, I'm writing TUIs. I don't use GUIs on the desktop if there's a decent TUI or CLI available and appropriate. So I write GUIs when I'm writing something for my wife, or -- increasingly, with Linux mobile gaining steam -- I want to write something that runs on my phone. I doubt I'm an average user, but I won't invest time learning a toolkit that'll limit where I can run the result.

$0.02. Which is worth even less, now that they've stopped making pennies.