[swift-evolution] Proposal - Allow properties in Extensions

[Austin Zheng]

+1 for "[giving] same-module extensions to do anything that can be done in
the original type declaration", +1 for something akin to C#'s 'partial'.
I've often wanted to organize my code for a single type within several
files, grouping methods and properties by purpose, but have been stymied by
both the way access control works and by the restriction on stored
properties.

Best,
Austin

On Fri, Dec 18, 2015 at 3:58 PM, David Owens II via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Dec 18, 2015, at 3:34 PM, Joe Groff via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Dec 18, 2015, at 3:24 PM, Kevin Ballard via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> AFAIK there's no precedent today for extensions in the same module being
> able to do things that extensions in other modules can't do (beyond
> accessing `internal` members of course). I'm not completely opposed to the
> idea, but I would want to be very careful and make sure there's an
> extremely clear benefit to changing it so extensions in the same module can
> add extra storage.
>
> One potentially large downside is you can no longer look at a type
> declaration and find out how large it is. For example, I could define
>
> struct Foo {
>    var x: Int
> }
>
> and it looks like a tiny struct, but I could then add an extension in a
> separate file that bloats that out to some ridiculously massive struct, and
> that wouldn't be obvious from looking at it.
>
> That said, when looking at a definition imported from another module, you
> can't see which properties are computed and which are stored anyway, so
> it's maybe not a huge deal (although you can assume any property defined in
> an extension is computed). But it is still something to consider.
>
>
> True, this is a tradeoff. We've discussed moving in the direction of
> allowing same-module extensions to do anything that can be done in the
> original type declaration, to allow freedom of organization without
> arbitrary rules about what must go in the type, but sizing instances was
> one of our concerns. (You could always peek at the LLVM IR if you want to
> know for sure what's getting generated.)
>
>
>
> Have you considered using “partial” or “extendable" for these types of
> definitions (similar to C# partials) to reduce this confusion?
>
> extendable struct Foo {
>    var x: Int
> }
>
>
> When the keyword is there, all bets are off that the layout of the struct
> only contains a single member. Then extensions, defined within the same
> module, could add to it.
>
> -David
>
> _______________________________________________
> 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/20151218/0f309229/attachment.html>