> 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
> discussion?
For what it's worth, Greg Parker (Cc'ed) started a discussion back in
March that I think is relevant here:
https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160314/001424.html
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
suggestions welcome.
Today, each object stores 64-bits of refcounts and flags after the isa
field.
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.
Advantages:
…
* 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.
Ole
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
