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

[Andrew Bennett]

I'm surprised no one has said this yet, but nice work Joe for getting a
partial implementation we can start to play with! :)

I'm sure it will help to better understand the impact of the proposal and
how it relates to our code in a more concrete/practical way.

- *What is your evaluation of the proposal?*+1
- *Is the problem being addressed significant enough to warrant a change to
Swift?*Yes, I'm excited by the potential here, and once the idea has had
some real-world use I would like to see this pattern applied to more things.
- *Does this proposal fit well with the feel and direction of Swift?*Yes.
- *If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?*C# and Java have some
annotation systems, they are loosely related. I've used them and found they
add a lot of power to those languages, I've not tried to implement them
though so I cannot comment on that.
- *How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?*Only a brief look unfortunately, I've been skimming
the new posts, but other than reading the proposal I haven't had time to
look more thoroughly.


On Thu, Feb 18, 2016 at 4:18 AM, Joe Groff via swift-evolution <
swift-evolution at swift.org> wrote:

> If anyone wants to start playing with the feature, I now have some of the
> core functionality working in a branch:
>
> https://github.com/apple/swift/pull/1297
>
>
> I didn't want to waste time parsing a behavior declaration syntax while
> we're still painting the bikeshed, so behaviors are currently exposed as
> protocols with extension methods following a convention:
>
> protocol delayedImmutable {
>   // Type of the property.
>   associatedtype Value
>   // Storage required by the property.
>   var storage: Value? { get set }
> }
> extension delayedImmutable {
>   // Implementation of the property.
>   var value: Value {
>     // The property can only be read after it's been initialized.
>     get {
>       guard let theValue = storage else {
>         fatalError("delayedImmutable property read before initialization")
>       }
>       return theValue
>     }
>
>     // The property can only be written once to initialize it.
>     set {
>       guard storage == nil else {
>         fatalError("delayedImmutable property rewritten after
> initialization")
>       }
>       storage = newValue
>     }
>   }
>
>   // Initialization logic for the property storage.
>   static func initStorage() -> Value? {
>     return nil
>   }
> }
>
>
> Custom accessors and initializer expression bindings aren't handled yet,
> but there's enough there now to implement `delayed` initialization. Here's
> an example test case:
>
>
> https://github.com/jckarter/swift/commit/9da36f8e1e45564a61da4cfc9ed5327bf57862df
>
> -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/20160218/48eaf42b/attachment.html>