[swift-evolution] stored properties in extensions

[Jay Abbott]

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

 > 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 at swift.org

https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161011/059802b3/attachment.html>