V: Using << with array operator gives weird output

Created on 4 Nov 2019  路  13Comments  路  Source: vlang/v

Hello,
I am new to V and going through the docs. I was trying to append multiple values to an array and got weird output. I am curious as to why it happened and whether appending multiple values is allowed in V.

Code

mut a := [1, 2, 3, 4]
a << 5 << 6 << 7 << 8
println(a)

Output

[1, 2, 3, 4, 10485760]
Feature Request Documentation

All 13 comments

Chaining << does not work. Pushing elements individually to the same array works.

Hey. 10485760 is the result of shift left operations (5 << 6 << 7 << 8) :)
So it's a << (5 << 6 << 7 << 8) with the different meaning of <<.
Works "as designed", but not "as expected" :)

Hey. 10485760 is the result of shift left operations (5 << 6 << 7 << 8) :)
So it's a << (5 << 6 << 7 << 8) with the different meaning of <<.
Works "as designed", but not "as expected" :)

Yeah I guessed that. Just wanted to be sure if that was the intended behavior. Thanks for your answer 馃憤

I don't think it's intended behavior. Just nobody ever thought of that way to use <<.
It's a good question what should be done about it to eliminate disambiguation.

Good find @Waqar144

I'll think about the best way to handle this.

In Ruby multiple << simply append to the array several times.

Since you can already do a << [3,4,5], I think a << 3 << 4 << 5 should simply not be allowed.

In Ruby multiple << simply append to the array several times.

Coming from Qt land, you can append to QStringLists using <<

Since you can already do a << [3,4,5], I think a << 3 << 4 << 5 should simply not be allowed.

Great, that will make it much more straightforward.

@medvednikov I think if you'd make the type of the result of a << 1 to be an array,
a << 1 << 2 << 3 would automatically work as array push (providing that << is left-associative).
If I remember correctly, the meaning of << as array push is determined by the type of the left operand being an array.
That way, a << (1 << 2 << 3) would also work by calculating the result of the expresion in paranthesis as left shift operations. So everything would be as expected.

Yes, perhaps it makes sense to return the new array like in Go's a = append(a, val).

I'd prefer to keep it simple thought since << modified it in place, and there's already a way to append multiple values.

This is not of immediate importance, of course.
My thinking was not about returning a new array, but making compiler understand that the result of the a << 1 operation is that same array a (so that would mean the result type is array), and then compiler should treat next << in a regular way as another array push operation.
This would require some changes in compiler to be able to parse consecutive array push, as I understand.
It's up to you how you decide: make changes to accept that or just ban it.

To quote from The Book of V (docs):

The advantage of using V for this is the simplicity and predictability of the language

Having one way of doing everything is the best way to keep it simple and more understandable, especially for people who didn't write the code, in my opinion. So, I support the author's stance on this.

It's doing a << (5 << 6 << 7 << 8), nothing can be changed, unless we only allow a single shift.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

radare picture radare  路  3Comments

arg2das picture arg2das  路  3Comments

clpo13 picture clpo13  路  3Comments

shouji-kazuo picture shouji-kazuo  路  3Comments

lobotony picture lobotony  路  3Comments