141–150 of 236 posts
Nice - but hang on a second, I thought you cannot shadow language keywords in Go. So projects bumping to 1.21 in the future should be aware that you will run into compile time errors all of a sudden… doesn’t that actually break the compatibility promise? max := something() https://go.dev/doc/go1compat
These new packages, like slices and maps, were a long time coming. So glad it's finally here. I cannot even begin to tell you how many different itemInSlice functions I've written over the years.
Nice - but hang on a second, I thought you cannot shadow language keywords in Go. So projects bumping to 1.21 in the future should be aware that you will run into compile time errors all of a sudden… doesn’t that actually break the compatibility promise? max := something() https://go.dev/doc/go1compat
package main
func main() {
arr := make([]int, 0, 10)
make := 1
arr = append(arr, make)
len := func(arr []int) int { return -1 }
println(len(arr))
// Output: -1
}
Earlier quoted context omitted.
You can't "remove all items from the slice"; you can only change the length to 0: "slice[:0]".
That _is_ removing all the items from it; my point is that if you pass a map with `n` entries to clear, you end up with a map with 0 entries. If you do the same with a slice with `n` elements, I'd imagine most people would expect to end up with a slice with 0 elements, but instead you have a slice with `n` copies of the zero value.
s := []string{"hello", "world", "foo", "bar"}
fmt.Println(s) // [hello world foo bar]
s = s[:0]
fmt.Println(s) // []
s = append(s, "XXX")
s = s[:2]
fmt.Println(s) // [XXX world]
This is why "delete(slice, n)" doesn't work and it only operates on maps.
I suppose clear(slice) could allocate a new array, but that's not the same behaviour as clear(map) either, and doesn't really represent the common understanding of "clearing a slice". The only behaviour I can think of that vaguely matches what "clearing a slice" means is what it does now.
[flagged]
It is interesting to see them add things like the "clear" function for maps and slices after suggesting to simply loop and delete each key one at a time for so long. Is this a result of the generics work that makes implementation easier vs. the extra work of making a new "magic" function (like "make", etc.)?
That `clear` on a slice sets all values to their type's zero value is going to be extremely confusing especially coming from other languages (Rust, C#, C++, Java, ...) where the same-named function is used on list-ish types to set their length to zero. Doubly-so when `clear` on a map actually seems to follow the convention of removing all contained elements.
I suppose it could have been x = clear(x) or clear(&x), but certainly if you understand Go semantics then seeing any function call do Foo(slice) already signals that the call can't modify the length since there's no return value.
Why is map copy "dst, src" vs "src, dst"?
Earlier quoted context omitted.
That _is_ removing all the items from it; my point is that if you pass a map with `n` entries to clear, you end up with a map with 0 entries. If you do the same with a slice with `n` elements, I'd imagine most people would expect to end up with a slice with 0 elements, but instead you have a slice with `n` copies of the zero value.
But it's not "removing items", at least not for all meanings of the word "removing". You can see this with something like: s := []string{"hello", "world", "foo", "bar"} fmt.Println(s) // [hello world foo bar] s = s[:0] fmt.Println(s) // [] s = append(s, "XXX") s = s[:2] fmt.Println(s) // [XXX world] Which will print back "XXX world" because it's using the same array, and nothing was ever "deleted": only the slice's l…
Earlier quoted context omitted.
Put the logger in the context
Isn't it considered bad practice?
the context stores request-scoped data, whether or not the logger is a request-scoped value is a grey area
and to reply to sibling comment, opentelemetry is basically a house of antipatterns, definitely do not look to it for guidance
Earlier quoted context omitted.
That `clear` on a slice sets all values to their type's zero value is going to be extremely confusing especially coming from other languages (Rust, C#, C++, Java, ...) where the same-named function is used on list-ish types to set their length to zero. Doubly-so when `clear` on a map actually seems to follow the convention of removing all contained elements.
Go slices are passed by value so there's no way for clear() to resize the underlying array without reassignment. I suppose it could have been x = clear(x) or clear(&x), but certainly if you understand Go semantics then seeing any function call do Foo(slice) already signals that the call can't modify the length since there's no return value.