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

[Matt Whiteside]

I’m sorry if this has already been discussed, but what are the drawbacks of putting the variable's behaviors before the ‘var’ keyword?  Like this:

lazy synchronized var x:SomeType

That seems pretty ideal from a readability standpoint.

Matt

> On Feb 14, 2016, at 05:05, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> • Angle brackets already appear in var declarations for generic types; that means there are two different meanings for angle brackets in the same construct.
> Isn't the same true when you declare an array (or a closure)?
> 
>> • When we eventually allow you to apply multiple behaviors to a single property, that will also mean that *commas* are used in both of those angle bracket constructs, but with different meanings (one means "chain these", the other means "fill these two slots").
> True, but imho also no deal breaker; I would like to have labeled generic parameters anyway ;-)
> Afaics, it isn't decided how multiple behaviors will be handled yet.
> 
>> These are not fatal errors, but they're also completely unforced—either `[]` or `{}` would not have this problem. So why choose the option that has the problem?
> Because those have a similar (and imho bigger) problems:
> Grouping blocks of code or declaring arrays are things that are tightly coupled with "their" braces, and for me, "<>" causes the smallest disruption… arrays, capture lists and blocks have little in common with behaviors, but property behaviors could be expressed using generics*
> 
> Tino
> 
> * thinking of something like
> 
> protocol Behavior {
> 	typealias ValueType
> 	var value: ValueType { get set }
> }
> 
> class DefaultBehavior<T> {
> 	typealias ValueType = T
> 
> 	var value: ValueType
> 
> 	init(value: ValueType) {
> 		self.value = value
> 	}
> }
> 
> class Sample {
> 	var<DefaultBehavior> content: Int?
> }
> 
> Here, "var" would create a container whose behavior is determined by a generic parameter; access of "content" would be mapped to that container.
> I know behaviors are supposed to work slightly different, but that doesn't destroy the mental model of a parameterized container.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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