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

[Charles Constant]

+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 "in-module" where I need this, the
fewer "exceptions to the rule" we have in Swift the better. It gets tricky
trying to plan things out when one has to juggle too many features that
work in one context, but not another.

So +1 with the hope that it doesn't stay "in-module" till the end of time.



On Fri, Oct 14, 2016 at 6:01 PM, Paul Cantrell via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution <
> swift-evolution at swift.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.
>
> Contra Karl in another message, it’s _in-module_ stored property
> extensions that I want most frequently. By far.
>
> It seems to me that Charles’s idea could be introduced as its own
> proposal. If out-of-module stored property extensions do eventually become
> feasible, then Charles’s proposal is a good stepping stone. If they never
> do, then his proposal has done no harm.
>
> I realize this probably falls into the post-ABI stability bucket, but I’d
> love to help write/support the proposal when its time comes.
>
> Cheers,
>
> Paul
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161014/1c99440e/attachment.html>