[swift-evolution] [Proposal] Property behaviors

[Wallacy]

And how about:

instead that:

var behavior Foo: Int {
  // behavior body
}

that:

struct Foo<Int>: behavior{
  // behavior body
}



Or something like that....

Em ter, 19 de jan de 2016 às 02:03, Joe Groff via swift-evolution <
swift-evolution at swift.org> escreveu:

>
> On Jan 18, 2016, at 7:57 PM, davesweeris at mac.com wrote:
>
> Can we use “#” or something other than “.”, both to make it clear we’re
> referencing a behavior rather than a property, and so that we can avoid
> naming collisions when x has a property “lazy” *and* is declared with the
> lazy behavior?
> x.lazy.clear() // a property named “lazy” which has a clear() method
> x#lazy.clear() // the behavior named “lazy”
> I kinda like “#” (or whatever) for declaring them, too:
> var x #(lazy) = 6
>
>
>
> I’m a definite +1 on the concepts behind your proposal, but there are
> really two distinct things going on here: behaviors that mess with the
> type, and those that don’t. I mean, if you define your Lazy “behavior” like
> this:
> struct Lazy<T> {
>     private let closure: () -> T
>     private var storage: T? = nil
>     var value: T {
> mutating get {
>     if storage == nil { storage = closure() }
>             return storage!
> }
> mutating set {
>     storage = newValue
> }
>     }
>     init(_ closure: () -> T) {
>         self.closure = closure
>     }
> }
>
> then the only difference between
> lazy var foo = {
>     return 4
> }
> and
> var foo = Lazy {
>     return 4
> }
> is that in the former case, the property is implicitly accessed:
> var bar = foo
> foo = 10
> and in the latter, we have to access it explicitly:
> var bar = foo.value
> foo.value = 10
>
> If we expose the mechanism currently used by `T!` to convert between
> itself and T, and allow structs, enums, classes, and maybe even protocols
> to provide type accessors as well as property accessors, Lazy, Optional,
> and ImplicitlyUnwrappedOptional could then be implemented like this:
> struct Lazy<T> {
>     // or whatever the magic syntax is
>     mutating static get { () -> T in // $0 is an instance of Lazy<T>
> if $0.value == nil { $0.value = $0.closure() }
> return $0.value!
>     }
>     mutating static set { (newValue:T) in $0.value = newValue }
>
>     private let closure: () -> T
>     private var value: T? = nil
>     init(_ closure: () -> T) {
>         self.value = closure
>     }
> }
> enum Optional<T> {
>     // no need for a custom getter, since you have to manually unwrap
> optionals
>     mutating static set { (newValue: T) in $0 = .Some(newValue) } // $0
> is an instance of Optional<T>
>     mutating static set { () in $0 = .None }
>
>     case None
>     case Some(T)
>     init() { self = .None }
>     init(nilLiteral: ()) { self = .None }
>     init(_ value: T) { self = .Some(value) }
> }
> enum ImplicitlyUnwrappedOptional<T> {
>     mutating static get { () -> T in // $0 is an instance of
> ImplicitlyUnwrappedOptional<T>
>         switch $0 {
>         case .None: fatalError("Error unwrapping
> ImplicitlyUnwrappedOptional")
>         case .Some(let value): return value
>         }
>     }
>     mutating static set { (newValue: T) in $0 = .Some(newValue) }
>     mutating static set { () in $0 = .None }
>
>     case None
>     case Some(T)
>     init() { self = .None }
>     init(nilLiteral: ()) { self = .None }
>     init(_ value: T) { self = .Some(value) }
> }
>
> One of the stated goals of Swift 3 is to move stuff out of the core
> language and into the standard library, right? Well, this would get rid of
> all the “magic” behind Lazy, Optionals, and ImplicitlyUnwrappedOptionals
> *and* it’d let us implement our own type-related custom behaviors. It’s a
> win-win!
>
>
> Getting rid of magic is definitely a goal, but I think we want to go in
> the *opposite* direction. Implicit Optional promotion creates lots of
> problems, and ImplicitlyUnwrappedOptional's behavior can be hard to
> predict. We plan to reform the type system around both kinds of Optional
> soon. Behaviors also give us an opportunity to eliminate at least one case
> for IUO by modeling delayed initialization as a behavior. I'd prefer not to
> introduce more messy implicit promotions.
>
> -Joe
>
> _______________________________________________
> 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/20160119/6cd651c3/attachment-0001.html>