Using Optional as a reference, it seems to me like we ought to be decorating our code accordingly now. I haven't seen any good guide on when or how, though, ever. I also have no idea how to verify the correctness of any annotations. From what I've seen so far, it seems to me like a code analysis tool ought to be able to automatically add them, perhaps necessitating unit tests for verification of intended usage?
If you're using them on copyable types (the default), they're just an optional performance optimization, so you'd verify them the same way as any other performance work: benchmarks and profiling tools (or examining disassembly/using @_assemblyVision to see that the copy you were attempting to eliminate is in fact gone).
If you're using them with non-copyable types, it won't compile if you have it wrong.
8 Likes
The "optional" is at the heart of what I'm asking…
The flexibility and intent is the first thing to be tested. It seems to me that not using annotations makes a strong statement about them. (I.e. "No, ~Copyables" are ~Allowed".) I don't see guidelines on when is this appropriate, and what general (potentially automated) practice should be on it—it seems like certain annotations ought to be default, rather than none.
I hope this does not come across as condescending or rude, but to me this is one of those topics where: "If you don't know you need it, you don't need it".
So, if you are asking "should I start annotating things because I see others doing it" the answer is pretty much "no". No worrying required.
If you are just interested under which circumstances these would apply, there is no single good answer (at least I don't have one) - this will be a bigger "learning project" about how things like ownership, memory, function calls, etc. "really" work.
If you have an actual performance topic to solve, you'll probably need to look at things more methodically anyway.
I can recommend learning a bit of rust - you can't really write rust without understanding a good chunk of it, so the swift ownership stuff (which is more hidden behind the scenes) will feel right at home afterwards.
4 Likes
All types default to be copyable, that’s automatic default for the Swift, since they are fine for majority use-cases. Non-copyable types is mostly can be seen as on-demand optimization technique where you don’t want to allow copies for some reason or that’s a generic wide-purpose library code.
If you don’t see how it can be applied in your code, great chances that you don’t need it (oh, @sliemeobn actually has already stated that, huh). Otherwise it would be clear what behavior you’d like to enforce on the type in your use case.
You see it in standard library definitions because they have to work in a large amount of cases without restricting usage. Like Optional type being generic over both copyable and non-copyable types, since it is just a wrapper around some user type.
2 Likes