v
v copied to clipboard
vlang
`str1 + str2 + str2` should be optimized
Concatenating multiple strings should always result in only one allocation.
Have you thought about python style string formatting "hello {} {}".format(firstName, lastName) or something similar? Edit: I guess we already have concatenation (+) and interpolation with variables ($var) so don't need the complexity
Also for joining and splitting arrays ",".join(array) or array.split(",") ?
Edit: I guess we already have concatenation (+) and interpolation with variables ($var) so don't need the complexity
You've answered your question correctly :)
Also for joining and splitting arrays ",".join(array) or array.split(",") ?
str_array.join(','), but no array splits.
@Delta456
@gslicer the first one
That seems again inconsistent with the Array notation where it is stated (according to docs): "<< is an operator that appends a value to the end of the array. It can also append an entire array. "
So I would expect string (which is a [byte|rune]-Array to support the same notation - why not let + be pure mathematical?
When there was something I liked in C++ it was the "<<" operator on iostreams (which were basically byte-streams or var-length strings ;)
I'm sorry @medvednikov but in current implementation string looks like an array to me (and you even called the variable representing a string "arr" which resambles Array):
module strings
pub fn repeat(c byte, n int) string {
if n <= 0 {
return ''
}
//mut arr := malloc(n + 1)
mut arr := [byte(0)].repeat(n + 1)
for i := 0; i < n; i++ {
arr[i] = c
}
arr[n] = `\0`
return string(arr, n)
}
My point is, + could be used only for arithmetic operations, and << for concatenation (of any kind) - this would be more streamlined with the "simple" and "do similar stuff with similar syntax" approach, don't you think?
No, it's not an array. String is an immutable struct with a pointer to string data, len, and capacity integers.
In this function arr refers to []byte from which a string is generated via string().
By the way thanks for referring to this function, it needs to be updated :)
Things like that may be nice, but not only it's additional complexity in the compiler, but also it's not even obvious that there are such optimizations, so it's one more random thing to learn.
I could say that maybe it's worth making it more general, like make operators variadic. But that's just complicating something that is already simple.
I would say that ''.join(s1,s2,s3) is fine, and even ''.join(s1,s2) is fine. Like if only in C++ there was no + for std::string, so much of code would be automatically optimized, you would just call concat(or whatever it would be called). So I think it's fine to remove operator overloading all together, because it inevitably leads to slow code. Let's not repeat the same mistakes.
Things like this should be simple in the new compiler. The IL will make optimizations much simpler.
