[swift-evolution] [Proposal] Property behaviors

[Joe Groff]

> On Jan 24, 2016, at 1:16 AM, Thorsten Seitz <tseitz42 at icloud.com> wrote:
> 
>> 
>> Am 23.01.2016 um 20:30 schrieb Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>>:
>> 
>>> 
>>> On Jan 23, 2016, at 8:14 AM, Thorsten Seitz <tseitz42 at icloud.com <mailto:tseitz42 at icloud.com>> wrote:
>>> 
>>> 
>>>> Am 23.01.2016 um 01:33 schrieb Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>>>> 
>>>>  changing the proposed syntax for behavior member lookup to 'property.[behavior].member', as suggested by Tal Atlas and others. I think this has a nice symmetry with the `var [behavior]` declaration syntax, and doesn't occupy any new sigils. On the other had, Curt Clifton and others have raised the point that it could be mistaken for a subscript at a glance.
>>> 
>>> As a minor issue I’m not very fond of the behavior member lookup syntax because of the similarity to a subscript. The symmetry with the declaration syntax will break down a little bit as soon as the declaration syntax allows a list of composed behaviors.
>>> 
>>> 
>>>> To reduce the complexity of the initial feature review, I've also removed many of the bells and whistles from this initial version for separate consideration. For now, I'm saying initializer requirements are always "eager" (can't refer to self) and always inline-initialized. This imposes some inconvenience on some use cases, but is an additive feature. I've also left behavior composition, extending behaviors, overloading behaviors and […] as future extensions
>>> 
>>> I think behavior composition should be included right from the beginning as this might require breaking changes otherwise.
>> 
>> Practically speaking, I think there are inevitably going to be breaking changes here once we get some experience with the feature. 
> 
> That’s a fair point :-)
> 
>> It won't ship until 3.0 at the earliest. Many of the other features I've cut, including the initialization generalizations and extensions, would also be ABI-breaking changes at the implementation level.
> 
> Ok, thanks! But doesn’t this collide with the goal of Swift 3.0 of a stable ABI?

I hope we'll have the feature stabilized by then, of course. However, it's a strong goal for this feature to be "zero-cost" with little or no runtime footprint. If we're successful at that, there should be more or less no ABI impact, since behaviors would just be compile-time sugar.

-Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160125/a577ead7/attachment.html>