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