> On 15 Oct 2016, at 02:01, Paul Cantrell via swift-evolution
> <email@example.com> wrote:
>> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution
>> <firstname.lastname@example.org> 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 determining the size of the type, just as if the
>> properties had been declared in the type. Declaring stored properties on an
>> extension outside of the type’s module results in a compiler error, exactly
>> as today. This would, without any performance drawbacks, solve one of the
>> big problems that people are hoping to solve via stored properties in
>> extensions—the ability to organize members by protocol conformance.
> Yes please! A big strong +1 to this from me. I can think of several specific
> chunks of problem code that this would clean up immensely.
+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