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. > Personally I don't try to add functionality to types from other libraries, > and when I have to I try as much as possible to do it via wrapping; obviously > this doesn't cover the async type cases and others where it'd be hard to > re-wrap the values, but I think I'd like to know more about how common such > cases actually are. > > However, allowing stored properties in local extensions is an absolute must > for a first step, and would be very useful as a first step. > > > The problem I have with doing it for external types is that I just don't see > how it can be done efficiently; associated objects means looking up the > object to find what its associated values are, which isn't a negligible cost > if you're doing it frequently, and it makes me very uncomfortable to think of > hiding what is actually happening, as developers may think they're just using > a regular property without really appreciating the actual costs involved. At > the very least they need to handled through a .associated property or > whatever to make it much clearer that these aren't native properties in the > normal sense. > _______________________________________________ > 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
