That is just the language definition. It is fine for an implementation to actually compare both at the same time as long as within the language you can not observe this happend. If we cant tell the read to be b…
Note that afaik [3]string(s) was not valid before go1.20 so no existing code should use it. The semantic equivalent had to be written as *(*[3]string)(s) which also copies the array pointed to by *[3]string)(s). The new…
> This for loop is less efficient than clearing a map in one operation For maps with keys that are reflexive with == the Go compiler already optimizes the range loop to a single efficient runtime map clear call:…
The reasoning is here: https://github.com/golang/go/issues/40255 Copy of part of it: 1) While 387 support isn’t a huge maintenance burden, it does take time away from performance and feature work and represents a fair…
I think this part "Step 1) is not needed with the append approach, as we just reserve a memory location but the previous values stay there until we write them in step 2. " is not what the Go gc implementation currently…
That is just the language definition. It is fine for an implementation to actually compare both at the same time as long as within the language you can not observe this happend. If we cant tell the read to be b…
Note that afaik [3]string(s) was not valid before go1.20 so no existing code should use it. The semantic equivalent had to be written as *(*[3]string)(s) which also copies the array pointed to by *[3]string)(s). The new…
> This for loop is less efficient than clearing a map in one operation For maps with keys that are reflexive with == the Go compiler already optimizes the range loop to a single efficient runtime map clear call:…
The reasoning is here: https://github.com/golang/go/issues/40255 Copy of part of it: 1) While 387 support isn’t a huge maintenance burden, it does take time away from performance and feature work and represents a fair…
I think this part "Step 1) is not needed with the append approach, as we just reserve a memory location but the previous values stay there until we write them in step 2. " is not what the Go gc implementation currently…