[go-nuts] Re: newbie: string to byte array

why?. For eg: can I do like this [...]rune("ABC")
no. because in general strings have dynamic length
(only known at run-time) but arrays need static
length.

i don't think allowing [...]rune() for const string has
any major benefits. what do you want to do with
this conversion?

--

Thanks for the clarification. I just wanted to understand the design
decision for not allowing it.

-Rajesh

Hi Minux,

I understand that strings are const and have dynamic length (one can assign
a new string at run time). However when you create a slice of rune from a
string you create a reference which points to underlying array of int32
(converted from the UTF-8 array of bytes). Also rune is editable. Since
array is a standalone object it is faster to create since there is no need
to create a reference. Also an arrray is editable. I understand passing
arrays in costly and hence slice is best choice. So it is upto the
programmer to decide whether he needs to convert a string into
a [...]rune() or []rune() based on his requirement. Why does the language
restrict to create an array of rune. It would really help if you can
clarify further.

Thanks
Rajesh

It's not about advantages of arrays. If you could do [...]rune(s) and
with a string of unknown length, the resulting array would have
unknown length, hence unknown type (since length is part of the
definition of array types).

And the language forbids you from creating things with unknown types,
which goes against static typing.

Rémy.

--

the [...]rune{1,2,3} style construct (in particular, the use of `...` here)
is shorthand for defining an array with a well known length based on the
number of arguments supplied in the array literal. It is _not_ a specifier
for variable-length-array (or "unknown length array") -- those would be
slices. This is the same reason you can't do:

var x [...]rune;

Also, the cost of a string -> []rune conversion is not significantly
greater than your hypothetically proposed operation of string -> [28]rune,
for example (where you _know_ the length of the string at compile time, and
if the conversion were natively supported). It'd probably use the same code
path as the existing slice conversion, and only involve a single extra
pointer operation, which would be immeasurably fast. If the array escaped,
it'd have to be heap allocated anyway, thus in general, there's no
guarantee the array method has any tangible advantage.

--