Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: Go 2: for index, rune, runelen = range for strings #28599
UPDATED proposal to only apply to strings.
The proposal is to allow a new 3 value range for strings:
where index and rune are the same as in
For example current strings.Map first range loop:
changed the title
proposal: for index, size, rune = range for strings and bytes
Nov 5, 2018
Wouldn't be the better if the size is computed explicitly as its fixed and does not change? Also, I don't think
Agreed, however unless the functions are very simple the compiler cant apply this optimization as any write to a byteslice or byte through a pointer needs to assume the byteslice iterated over was changed unless the compiler can prove they cant overlap. As far as i understand the compiler for example cant optimize the bytes.Map example as the mapping function could change the bytes of the byteslice being iterated over during the range loop.
The other simplification this proposal provides is allowing to have the already computed rune size (step to the next index) in the loop be usable by code in the loop without calling utf8.DecodeRune(InString).
Updated the proposal to reflect those points better.
I would not think this is that of an absolute counter point given the existence of utf8.DecodeRune and other utf8 function operating on byte slices and the general symmetry of byteslices and string in various packages like utf8 showing byte slices frequently being interpreted as utf8 encoded runes.
fair point that will indeed be confusing.
Maybe something like
And of course the
The point I'm trying to make is, bytes aren't special. They are just a uint8, and should be treated as such. If we want to introduce a concept of
The same is true for strings. https://golang.org/ref/spec#String_types "A string type represents the set of string values. A string value is a (possibly empty) sequence of bytes." but currently range UTF8 decodes runes from the bytes of a string. The range keyword introduces the way the string or byteslice is decoded even if both have no knowledge of this on their own.
Which is not the same semantic since changes to the byteslice are not taken into account during iteration and therefore often a copy is needed.
I thought this would be brought up. I wasn't going to do it, but I was thinking that if you did I would mention that both ranging over a string and converting it to
There's not a single thing built-in to the language that assumes that a
This is a fair assessment, although I feel like in the case where you want it to be available to be changed, the
Anyway, the point I'm trying to make is that there's not a single feature in the language that assumes that a