On Tue, Jul 9, 2024, at 19:46, Ian Lance Taylor wrote:
> On Tue, Jul 9, 2024 at 5:24 PM 'David Anderson' via golang-nuts
> wrote:
> >
> > In practice, as you point out, the original Go implementation does the
> > obvious thing and reuses the range iteration behavior. Would it be
> > reasonable t
On Tue, Jul 9, 2024 at 5:24 PM 'David Anderson' via golang-nuts
wrote:
>
> In practice, as you point out, the original Go implementation does the
> obvious thing and reuses the range iteration behavior. Would it be reasonable
> to nail down that `[]rune(foo)` must behave the same as range iterat
On Tue, Jul 9, 2024, at 15:22, peterGo wrote:
>
> On Tuesday, July 9, 2024 at 3:42:51 PM UTC-4 David Anderson wrote:
>> __
>> I've been going over the spec to clarify finer points of how string vs.
>> []byte behave, I think there may be an unnecessary degree of freedom that
>> could be removed.
On Tuesday, July 9, 2024 at 3:42:51 PM UTC-4 David Anderson wrote:
I've been going over the spec to clarify finer points of how string vs.
[]byte behave,
In https://go.dev/ref/spec#Conversions, `[]rune(str)` is specified as:
"Converting a value of a string type to a slice of runes type yields
On Tuesday, July 9, 2024 at 3:42:51 PM UTC-4 David Anderson wrote:
I've been going over the spec to clarify finer points of how string vs.
[]byte behave, I think there may be an unnecessary degree of freedom that
could be removed. Either that, or I missed a load-bearing statement that
constrai
I've been going over the spec to clarify finer points of how string vs. []byte
behave, I think there may be an unnecessary degree of freedom that could be
removed. Either that, or I missed a load-bearing statement that constrains
implementations.
In https://go.dev/ref/spec#Conversions, `[]rune(
