Re: [swift-evolution] stored properties in extensions (was: associated objects)

This line of thought suggests that allowing stored properties for same-module extensions is not only much more feasible to implement, but also makes more sense at the user level. > On Nov 10, 2016, at 4:36 AM, Jay Abbott wrote: > > Perhaps some types don’t lend themselves

Re: [swift-evolution] stored properties in extensions (was: associated objects)

Perhaps some types don’t lend themselves to being extended? Intuitively I would think any extensions should not affect the core behaviour at all. So if I extended a type by adding a property x, two instances with everything else the same and different values of x should still be considered equal

Re: [swift-evolution] stored properties in extensions (was: associated objects)

Has anybody thought about the semantic issues of out-of-module extensions with stored properties apart from the implementation issues? Such properties could potentially wreak havoc with the semantics of the type being extended. How would these properties play nice with an existing definition

Re: [swift-evolution] stored properties in extensions (was: associated objects)

> On Oct 16, 2016, at 6:56 PM, Benjamin Spratling via swift-evolution > wrote: > >> 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

Re: [swift-evolution] stored properties in extensions (was: associated objects)

>> 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

Re: [swift-evolution] stored properties in extensions (was: associated objects)

T.J.: This would not replace the need for stored properties in extensions. For example: Imagine adding a property to UIView in an extension, then recursively traversing a view hierarchy and accessing the property. This thought experiment should quickly show you why wrapping and adding properties

Re: [swift-evolution] stored properties in extensions (was: associated objects)

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

Re: [swift-evolution] stored properties in extensions (was: associated objects)

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

Re: [swift-evolution] stored properties in extensions (was: associated objects)

Currently, we can expect that fields of a type are all collected in the same place. This expectation applies more for "static" and less for "dynamic" types. So I agree with the idea for @objc classes, strongly disagree for structs, and disagree for regular classes.

Re: [swift-evolution] stored properties in extensions (was: associated objects)

I’m haven’t read the implementation, but as I see it, “weak” has the effect of storing associated values. Can that mechanism be made generic? > +1 from me too for internal extensions; I think this is the logical place to > start for now so we can see how many use cases this actually covers. >

Re: [swift-evolution] stored properties in extensions (was: associated objects)

> On 15 Oct 2016, at 02:01, Paul Cantrell via swift-evolution > wrote: > > >> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution >> wrote: >> >> Let extensions introduce stored properties, but only in the same module as >>

Re: [swift-evolution] stored properties in extensions (was: associated objects)

+1 for me for "in-module" as a stop-gap, since I imagine it would be the quickest, and least disruptive, way to make this happen. I would add the caveat that if we do so, I really hope we commit to making stored properties available *everywhere* later. Even though it's more often than not

Re: [swift-evolution] stored properties in extensions (was: associated objects)

> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution > wrote: > > Let extensions introduce stored properties, but only in the same module as > the type’s definition. Then, the compiler can just take any extensions into > consideration when it’s

Re: [swift-evolution] stored properties in extensions (was: associated objects)

I was thinking for reference types we would probably want to use the extra space in the refcount field (as discussed earlier in the thread). For value types, we might want to have a single data structure (probably COW) holding all associated values for the value types on the stack frame. That

Re: [swift-evolution] stored properties in extensions (was: associated objects)

Karl, interesting point... perhaps a similar scheme could work for value types (using the COW refcount)? On Thu, 13 Oct 2016 at 16:02 Karl Wagner wrote: > That's great! I suppose the idea of allocating a bit of extra storage for > similar data in value types is some sort of

Re: [swift-evolution] stored properties in extensions (was: associated objects)

That's great! I suppose the idea of allocating a bit of extra storage for similar data in value types is some sort of heresy? Would there be a conceptual reason for that; which explains why it's okay for reference-types but not for values? Personally I feel like it's a kind of C legacy, due to

Re: [swift-evolution] stored properties in extensions (was: associated objects)

I agree Karl, especially the bit about the difficulty of implementation being the limiting thing here. 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

Re: [swift-evolution] stored properties in extensions (was: associated objects)

> On 10 Oct 2016, at 21:15, Charles Srstka via swift-evolution > wrote: > > Right. The question is whether we *need* to add stored properties > out-of-module, and what the use case for that is. To me it seems that adding > them in-module is by far the more common

Re: [swift-evolution] stored properties in extensions (was: associated objects)

Yes, there are valid use cases. For example, in case of many UI elements, you do not have control over their instantiation and need to associate a "help description" with them as an example. Which can be done by an additional property helpDescription added to NSView/UIView. Another example

Re: [swift-evolution] stored properties in extensions (was: associated objects)

Right. The question is whether we *need* to add stored properties out-of-module, and what the use case for that is. To me it seems that adding them in-module is by far the more common use case, for the purposes of implementing protocols. At any rate, the rewrite option would be a great

Re: [swift-evolution] stored properties in extensions (was: associated objects)

> On Oct 10, 2016, at 1:13 PM, Jay Abbott wrote: > > I understand Charlie. A few points though: > a) I'm talking about pure Swift, this is absolutely nothing to do with > Objective-C; Sure, but in either case you will need to somehow solve locking of the structure holding

Re: [swift-evolution] stored properties in extensions (was: associated objects)

I understand Charlie. A few points though: a) I'm talking about pure Swift, this is absolutely nothing to do with Objective-C; b) If you read back on the AO thread you'll see that initially I was thinking "I want AO because it will give me stored properties in extensions" when really I should have

Re: [swift-evolution] stored properties in extensions (was: associated objects)

No, I've also suggested how it would be implemented. It would, as I've described, require support from the compiler and runtime - the protocol conformance would tell the compiler to include an extra space in the instance layout for [AnyHashable : Any], which would get to be used by the runtime

Re: [swift-evolution] stored properties in extensions (was: associated objects)

Charles, That would be good. It is a nicer way to write what is already possible to achieve, but it's not a way to 'implement' stored properties in extensions. On Sun, 9 Oct 2016 at 21:45 Charles Srstka wrote: > *Replace both instances of “class C: P” with just “class

Re: [swift-evolution] stored properties in extensions (was: associated objects)

*Replace both instances of “class C: P” with just “class C” since the conformance comes in the extension. That’s what I get for writing this quickly. Charles > On Oct 9, 2016, at 3:43 PM, Charles Srstka wrote: > > protocol P { > var foo: String { get } >

Re: [swift-evolution] stored properties in extensions (was: associated objects)

How about a 5th way? 5. Let extensions introduce stored properties, but only in the same module as the type’s definition. Then, the compiler can just take any extensions into consideration when it’s determining the size of the type, just as if the properties had been declared in the type.

Re: [swift-evolution] stored properties in extensions (was: associated objects)

Charlie, What you suggest defines how you would use it from your code, not how it would be implemented in the language. If you look at my AO implementation it does what you say: https://github.com/j-h-a/AssociatedObjects/blob/develop/AssociatedObjects/AssociatedObjects.swift i.e. has a protocol

Re: [swift-evolution] stored properties in extensions (was: associated objects)

There is a 4th way. Introduce an internal protocol Associatable, which would tell the compiler to add an additional (hidden) field to the object which would include the "dictionary" of key -> value associated values. (It would be off-limits to extensions, of course). This way: - it won't be

Re: [swift-evolution] stored properties in extensions (was: associated objects)

I have been thinking further on this and in addition to my previous two thoughts about implementation, I have had another idea... 3. If there is a bit spare in the object header somewhere (that is currently always zero), this could be used to signify the presence of an additional struct that

Re: [swift-evolution] stored properties in extensions (was: associated objects)

Are stored properties in extensions already being discussed elsewhere? Is this one of those deferred-but-not-indexed-anywhere subjects? I wonder how stored properties could potentially be implemented, I can only think of two ways: 1. An extra pointer per instance (with resulting ABI