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

[Hooman Mehr]

How about this:

Assuming behaviors are extensions of var (and maybe let in the future) and showing these extensions, just like file extensions appended with dot:

var.lazy foo = 1738

var extension lazy<Value> = initialValue {
  var value: Value? = nil

  mutating get {
    if let value = value {
      return value
    }
    let initial = initialValue
    value = initial
    return initial
  }
  set {
    value = newValue
  }
}

var extension resettable<Value> = initialValue {

  //...
  func reset() { /**/ }

}

// Declare valid composition, enforcing order or composition:
var.resettable extension lazy<Value> = initialValue {

  var.resettable value: Value? = nil
  //...
  override func reset() { /**/ }

}

var.lazy.resettable property1: Double = 3.1415927
var.resettable property2: Int = 123

property1.var.reset() // Not shadowed
property2.var.reset() // Not shadowed

property1.var.lazy.resettable.reset() // Full Path
property1.var.resettable.reset() // Full Path

property1.var._.resettable.reset() // Wild-card path
property2.var._.resettable.reset() // Wild-card path


This way we don’t have any new keywords or overloading symbols like # and @ with new meanings. The use of dot, I think seems the most natural. property.var.* creates a distinct namespace and since var is already a keyword, does not collide with anything. 

The same logic may also work for defining function decorators as func extension remote… (decorator/behavior declaration) and func.remote f() (function declaration) f.func.connect() (member invocation)

> On Feb 14, 2016, at 12:36 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 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
> 
> With no prefix at all, this limits our ability to introduce declaration modifiers in the future. For instance, if the people clamoring for a `local` access modifier win in Swift 4, anyone who wrote a behavior called `local` will be very sad.
> 
> The other problem is, with this declaration:
> 
> 	lazy var array = [1, 2, 3]
> 
> It offers no way to disambiguate between the two meanings of `lazy`:
> 
> 	array.lazy.reset()
> 	array.lazy.map { ... }
> 
> Personally, if we're not going to use the `[]` syntax, I think we should use the `@` prefix and think of all uses of `@` throughout the language as eventual targets for behavior-ization (even if we don't get around to most of them in Swift 3, or some of them ever). It would be nice to have a rational explanation for what `@` means. But I'm reasonably happy with the `[]` syntax.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> 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/20160218/0f551fab/attachment-0001.html>