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

[Haravikk]

> On 19 Feb 2016, at 02:56, Joe Groff via swift-evolution <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).

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160219/73413e30/attachment.html>