22 ms·
And decoding subsequences of UTF-8 code units (bytes) into Unicode scalars (runes), which also forces a copy. But why did Go pick the same syntax for cheap con
by debugnik 2y ago
And decoding subsequences of UTF-8 code units (bytes) into Unicode scalars (runes), which also forces a copy.
But why did Go pick the same syntax for cheap conversions and expensive ones, though? I'd expect this to be a standard function, not a type conversion.
- foldr 2y agoDon't all conversions require copying the value at the level of the language semantics? You can cast a float to an int, but you can't assign an integer value to a float variable (leaving aside whatever optimizations the compiler might make). Casting a float to an int is only cheap because a float is a fixed size. So it seems unsurprising to me that casting a larger value results in a proportionally larger copy.
- TheDong 2y agoMost conversions are things like casts to enum types or aliases I think, which never are O(n), like: dur := time.Second * time.Duration(2) headers := http.Header(map[string][]string{}) httpDir := http.Dir(filepath.Join(parts...)) In all of these cases, it's just a type-cast which is zero-cost, and I think that's what makes it feel surprising that casting between strings/runes specifically incurs more significant computation than any other cast.
- foldr 2y agoAll of those are copies and hence O(n) in the size of the value copied. This is hidden somewhat because your examples use constants and literals. (As numeric constants aren’t typed in Go the first example arguably doesn’t involve a copy, but the rest do.)