martisch

3 ms·

1. 1.▲
   by martisch 4y ago

   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 happenend with a or before a
2. 2.▲
   by martisch 4y ago

   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 notation is basicall
3. 3.▲
   by martisch 4y ago

   > 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: https://go-rev
4. 4.▲
   by martisch 6y ago

   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 represen
5. 5.▲
   by martisch 7y ago

   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 actually do