.byref always optimizes sink call into a bitwise memcopy if =sink is disabled

[ringabout]

closes #75
ref nim-lang/threading#79

Or only when =sink is disabled for byRef

[Araq]

I think the logic should be "it's .byref and also has its =sink disabled".

[ringabout]

make sense

[Araq]

This is still not correct as it can introduce leaks for code like var x = create(); x = create(). The idea here is that .byref types do not have any bitwise copies. We need to rethink this. It probably means the whole idea of =sink() .error is just wrong. =sink is fine and doesn't copy and shallow copies are prevented by .byref.

[darkestpigeon]

I usually use =copy() .error and =sink() .error for types that are used to communicate between multiple threads (perhaps some foreign) and the object needs to be pinned to a particular address. This both signals intent and prevents dumb errors (although moving an object by accident is rare). Will .byref cover this case correctly?

[Araq]

I think so, yes, but making =sink an .error just because you want to tie the object to a stack location is wrong regardless.