How much would convenient method forwarding when wrapping change how desirable this feature is? I am hesitant to add storage to already allocated instances if we can avoid it.
On Sun, Oct 16, 2016 at 5:02 PM, Jay Abbott via swift-evolution < swift-evolution@swift.org> wrote: > Greg: > > I've CCed you in case you want to respond to my comments below about > potentially optimising "extensionIvar" access without using a dictionary. > See my response to Haravikk below. > > Benjamin: > > Implementation wise, weak does *not* currently have the effect of storing > associated values. It does however mean that any object with weak > references stays allocated after being deinited, until all the weak > references are evaluated and zeroed (they are not zeroed when the object > deinits, zeroing is done lazily. See https://www.mikeash.com/ > pyblog/friday-qa-2015-12-11-swift-weak-references.html for a detailed > discussion). > > However, this seems likely to change at some point when Greg's changes are > merged. Weakly referenced objects would cause a side-table to be allocated, > with the benefits that the object could be deallocated immediately after > deinit, and only the side-table would hang around (to service attempts to > access weak references, which would still be lazily zeroed). The small > disadvantage of this (which only applies to instances that actually have > had weak references) is that an extra pointer dereference is needed for > retain, release, and weak reference access (and some other things). But a > big advantage is that the side-allocation could be used for other things > too, like stored properties. > > Haravikk: > > It can be done efficiently using Greg's proposed changes. The current > implementation on his branch (https://github.com/gparker42/ > swift/tree/new-refcount-representation) does not have any extra space for > stored properties, but he has discussed "extensionIvars" before on > swift-dev, and proposed that the side-table structure contains a pointer to > a dictionary for these. However, I think with some dynamic loader magic > this could be implemented as a dynamic structure instead of a dictionary. > Each time a module is loaded, the side allocation for stored properties > could be extended and the offsets to the newly extended properties could be > fixed-up based on the current size. Existing instances could be handled by > using the structure size as a version number (stored at the beginning of > this area), it would check if the instance is at the current version and > migrate/update the structure as needed (realloc it and init the extended > area to zero, updating the size/version field). These checks would be less > overhead than a getter/setter function call, so using dot notation to > access the properties would not be deceiving programmers about the cost. > > Anton: > > Why should it matter where data is stored? Can you expand on any reasons > for wanting object data to be contiguous, or thinking that it shouldn't be > allowed for Swift classes? > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution