[swift-evolution] [Review] SE-0030 Property Behaviors

[Matt Whiteside]

> On Feb 19, 2016, at 10:53, Joe Groff <jgroff at apple.com> wrote:
> 
>> 
>> On Feb 19, 2016, at 8:30 AM, Matt Whiteside <mwhiteside.dev at gmail.com <mailto:mwhiteside.dev at gmail.com>> wrote:
>> 
>> Response inline below...
>> 
>>> On Feb 19, 2016, at 06:14, Haravikk via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>>> On 19 Feb 2016, at 02:56, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> In discussion with the core team, we've also strongly come in favor of applying behaviors to properties using attribute syntax, e.g.:
>>>> 
>>>> @lazy var x = 111
>>>> @delayed var x: Int
>>>> 
>>>> They're definitely attribute-like, and we think it makes sense for behaviors to be the first of hopefully many kinds of user-defined behaviors. What do you all think of this direction?
>>> 
>>> Are they though? We’ve been discussing this a lot in the thread on enforcing super method requirements; while my preference in that case is for an attribute, I feel it is appropriate there because they’re more like directives and informative, and will generate warnings (and possibly errors too) in the same way as @warn_unused_result does. A lot of other attributes are either informational or are produce some kind of restriction that the compiler warns us about (or errors on).
>> 
>> I think Haravikk makes a good point here.  Currently, the `@` symbol seems like a holding ground for miscellaneous compiler directives and backwards compatibility issues (e.g., @objc, @IBOutlet).  So from this view, putting behaviors, which are a forward looking, swift native idea, under the ‘@‘ symbol, seems debatable.
> 
> I don't think that was ever our long term intent for `@`. We always intended to open the space up to user annotations at some point. 
> 
>> The syntax Haravikk proposes below makes sense to me.  Does it cause big problems from a compiler implementer’s standpoint?
> 
> It could be made to work today. 'var' <identifier> <pattern>' isn't currently a valid production. It would however interfere with the potential future ability to destructure structs or classes in 'var' bindings; we could conceivably allow `var CGPoint(x: x, y: y) = point` or something like it in the broad future.

Thanks for explaining this.  I hadn’t thought of that use case.  

I’m not so much concerned with whether the `@` symbol is internal to the compiler, but rather with lumping together behaviors, which I could see becoming a very mainstream feature relevant to application code, with stuff like @inline, @asmname, @transparent, and other somewhat obscure compiler hints.

Matt
 
> 
> -Joe
> 
>> Matt
>> 
>>> 
>>> However, property behaviours are more like defining protocols for properties, which is clearly very different from an attribute, and IMO not really compiler magic either. I think a keyword makes most sense, such as behaviour(lazy), though personally I don’t see why we can’t just include the names directly, i.e:
>>> 
>>> 	var lazy x = 111
>>> 
>>> Isn’t ambiguous, because the right most token (x) is used as the name, var is an explicitly defined keyword, therefore everything else (lazy) can be looked up as a behaviour, in much the same way as types would be. I know there’s some risk of naming collision, but I don’t think it’s all that high, and if property behaviours are functional enough there should be no reason to add any new keywords for use on properties in future as they will be added as behaviours in the standard library. So long as they’re a way to disambiguate your property behaviours from any in the standard library (which will be needed anyway) then I think it’s fine, even when you’re dealing with stuff like:
>>> 
>>> 	static final internal var lazy synchronized x = 111
>>> 
>>> If we require the order to be:
>>> 
>>> 	[static, final, private|internal|public] [var|let] [behaviours…] [name]
>>> 
>>> Then I don’t think there should be any real problems. This may even already be how it is, I’m not sure as this is how I structure them anyway.
>>> _______________________________________________
>>> 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/20160219/72ad116b/attachment.html>