[swift-evolution] stored properties in extensions

Ole Begemann ole at oleb.net
Tue Oct 11 18:21:07 CDT 2016


 > 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


More information about the swift-evolution mailing list