[swift-evolution] stored properties in extensions
jay at abbott.me.uk
Tue Oct 11 18:54:51 CDT 2016
Wow, that's a very interesting post. Sounds a lot simpler to implement than
my idea about fixing up offsets in the linker and preserves binary
compatability just the same.
I got some complaints when I first started talking about this that the
runtime would have to track extra pointers and performance would be
affected because of additional levels of indirection, which I didn't fully
understand because it seems fairly trivial to me. Perhaps this twin-purpose
refcount/side-table pointer also suffers the same concerns?
On Wed, 12 Oct 2016 at 00:21 Ole Begemann via swift-evolution <
swift-evolution at swift.org> wrote:
> I think the language devs must have some idea how this will work, but
> don't seem to want to share/discuss it at the moment. I was hoping for
> some feedback about my implementation ideas - whether they are along the
> right lines, or way off, or not necessary (because the implementation
> strategy is already known). Perhaps this the wrong list for that kind of
For what it's worth, Greg Parker (Cc'ed) started a discussion back in
March that I think is relevant here:
Here's the relevant part:
"I am considering a new representation for Swift refcounts and other
per-object data. This is an outline of the scheme. Comments and
Today, each object stores 64-bits of refcounts and flags after the isa
In this new system, each object would store a pointer-size field after
the isa field. This field would have two cases: it could store refcounts
and flags, or it could store a pointer to a side allocation that would
store refcounts and flags and additional per-object data.
* Allows inexpensive per-object storage for future features like
associated references or class extensions with instance variables.
I don't know the current status of this idea (implemented? planned?
abandoned?). Also, it's worth noting that this would only apply to
classes, not value types.
swift-evolution mailing list
swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution