I've been using Go for years, of course I know about copy.
Someone did a writeup on this which is a perfect illustration of a general theme with Go: on the surface it looks fine, but the closer you look, the stranger things get:
Apologies for my tone, I didn't mean to insinuate you weren't experienced. I guess I was wondering what was wrong with copy(), thanks for the link!
IMO, copy() is well-designed and the semantics are sensible. I think the other examples in that article are not clear, and the semantics have me second guessing what they're doing.
> Drawback 1: if s is nil, the result sClone is not nil.
I can see how this particular semantic seems an issue, but I think its sensible. If your copy() returned nil and you wanted to use it, then you'd have to check if sClone is not nil first, so that if statement is unavoidable. Instead, it's often safer in practice to check ahead of time.
Sorry again for my tone, it's easy to appear rude on the internet on a late night.
kubb|4 years ago
Someone did a writeup on this which is a perfect illustration of a general theme with Go: on the surface it looks fine, but the closer you look, the stranger things get:
https://github.com/go101/go101/wiki/There-is-not-a-perfect-w...
exacube|4 years ago
IMO, copy() is well-designed and the semantics are sensible. I think the other examples in that article are not clear, and the semantics have me second guessing what they're doing.
> Drawback 1: if s is nil, the result sClone is not nil.
I can see how this particular semantic seems an issue, but I think its sensible. If your copy() returned nil and you wanted to use it, then you'd have to check if sClone is not nil first, so that if statement is unavoidable. Instead, it's often safer in practice to check ahead of time.
Sorry again for my tone, it's easy to appear rude on the internet on a late night.