[swift-evolution] [Proposal] Property behaviors

[Taras Zakharko]

I must say that I really love your idea of property behaviours! I think a facility of this kind would be a great enhancement to Swift. 

I probably will have some more comments after I study your proposal in more depth, but for now a very quick one. I am not overly fond of your syntax for accessing behaviour members. I would prefer something like foo(x).method() to x.[foo].method() that you suggest. 


> 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.

I’m not so sure about that… your suggestion can have some non-trivial impact on reflection and instance memory layout. 

— Taras

> On 25 Jan 2016, at 19:25, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Jan 24, 2016, at 1:16 AM, Thorsten Seitz <tseitz42 at icloud.com <mailto: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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160125/4cc6bb53/attachment.html>