This line of thought suggests that allowing stored properties for same-module extensions is not only much more feasible to implement, but also makes more sense at the user level.
> On Nov 10, 2016, at 4:36 AM, Jay Abbott <j...@abbott.me.uk> wrote: > > Perhaps some types don’t lend themselves to being extended? > > Intuitively I would think any extensions should not affect the core behaviour > at all. So if I extended a type by adding a property x, two instances with > everything else the same and different values of x should still be considered > equal by a type-specific equality check. For example you would agree that 1 + > 1 = 2 but what if the numbers were coloured red, blue, and yellow > respectively, like fridge-magnets, should 1(red) + 1(blue) = 2(yellow)? I > think yes. The colour is an extension, it doesn’t change the fundamental > concept or behaviour of an integer number. > > I see extensions as a way to add functionality (and potentially data), but > without affecting the core behaviour. If you wanted to change behaviour then > you should use inheritance or composition to create something new. You can’t > then use your own type for instances created by a library, unless it gives > you a way to do that, the library would expect its own types to behave in a > predictable way, similarly they should behave the same way when extended. > > > On Thu, 3 Nov 2016 at 15:14 Thorsten Seitz via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Has anybody thought about the semantic issues of out-of-module extensions > with stored properties apart from the implementation issues? > > Such properties could potentially wreak havoc with the semantics of the type > being extended. How would these properties play nice with an existing > definition of equality, for example? How can it be guaranteed that their > value is consistent with the remaining state? And kept that way in case of > mutability? > > -Thorsten > > > Am 15.10.2016 um 03:01 schrieb Paul Cantrell via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: > > > > > >> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution > >> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
