Proposal for Swift Actors and performance concurrency futures

[Lantua]

@johnburkey

it would be interesting to see if the mother objects connection to it causes ARC traffic anyway

I think you've already handled a very similar situation. You seem to be avoiding ARC by using unowned references extensively, which should also be applicable here. If that's not enough, we can also separate the allocator from the allocated data, and have deallocation be supplied with the allocator, i.e.,

$x.deallocate(allocatedBy: .defaultAllocator)

@johnburkey

And bigger picture, I think its important we advocate here for simplicity ahead- a way to use ARC ideas without global-ness, ((alloc from global cross thread heap), locks) but preserving the "GC"-ness of the way its used.

If the feedback would be that it's good but the deallocation at the end is easy to miss, then we're probably on the right track for the syntax. I said this because it's not the only syntax and granularity out there. It could be a scope declaration, declaration annotation, or even type annotation:

local(zone) {
  ...
}
local(zone) var x = ...

local(Zone) class { ... }

Starting with something a little unsafe would be a good testing ground for that.

Even then, I think the safe annotation would at best be an optimization hint (albeit error if the value is not actually local). The compiler stands to gain if the variable is local, so it would already be trying to prove its locality anyway.

@johnburkey

you would think scalable async programming would be more front and center.

If the async chain are treated (and optimized) as a long local context, then we'd also be able to use what we learnt in a single thread environment too. So perhaps they're (async SIL) on to something.