> Well ... that's not my proposal. ;-)
@Araq, true, but that's why we are discussing it on the forum; you might change
your mind - I have been caused to change my mind several times in this
discussion ;-)
I did indicate that the {.shared.} is not in the current proposal.
> sink is only for routine parameters; channel's send operation would have a
> sink parameter. You use way too many explicit move's. Let the compiler infer
> them.
Thanks for the correction; I'm still getting used to the use of sink/move until
I get a chance to try them myself; also, although I suspected the compiler
would infer some moves, I added them anyway to make the code clear that moves
were taking place.
Questions:
1\. Is sink also still for local let/var's although you "are not sure of their
use" and if so what is the syntax to declare them?
2 Would the use of a local declared as sink be so that there is an implicit
move rather than a copy when assigned to?
3\. Am I correct from reading spec 2 that all function return values are
implicitly "lastReadOf" and therefore will be implicitly moved when first
assigned?
> My proposal does not have {.shared.}. Instead all allocations are shared by
> default.
But, as per the current source files, don't shared allocations all have the
overhead of acquiring and releasing a heapLock if threads is turned on?
Does this mean that all structures that are allocated shared by default also
have atomic accessors by default with their cost in performance when threads is
turned on?
My {.shared.} proposal would provide a means to bypass those overheads when the
lock/atomic behaviour is not required as when the said structures are only used
on one thread or have an overall lock on a mass of accesses. In order to save
the heapLock acquire/release time, it would still need a shared heap and a
local heap allocator however. My proposal would be a means of tuning
performance for those who know what they are doing; default would work fine but
just be slower.
