[swift-evolution] [Proposal] Property behaviors

[Joe Groff]

> On Jan 18, 2016, at 8:58 AM, Wallacy <wallacyf at gmail.com> wrote:
> 
> Few questions:
> 
> 1 - This model has any optimization opportunities in mind? Like allow the compiler optimize calls over behaviors?

Yeah, the proposal is designed to avoid overhead for the behavior abstraction. By avoiding defining a type for behaviors, we avoid the runtime metadata cost of a generic type. By binding the initializers and accessors of the behavior specially, we avoid needing to store state in the instance of a type using a behavior to carry those parameters from initialization to access. For compile-time speed, we will likely need to generate functions and global data structures in debug builds, but these should all be inlineable in production builds.

> 2 - Will be possible compose behaviors and resuse, like:
> typealias lazyObserver = [lazy,observer]

Not as stated. We could add behavior aliases or compositions if we wanted to later.

> 3 - "var behavior" will make unusual create any other property called behavior. Its not better make behavior a reserved word like "protocol" and use then? protocol is also a valid identifier.

The 'behavior' keyword can be contextual, since 'var behavior <identifier>' isn't otherwise legal syntax. You could still name a property or function 'behavior'.

> 
> 4 - Will be provided any implementation of standard library of any other behavior like "lazy", "observer"?

I think we'll want to make 'lazy' and 'observer' into behaviors, but further standard library improvements should be discussed separately.

> 
> 5 - How to handle with behavior name collision? If two modules define the same behavior name, can be handled using full name (module.behavior)?

Yes.

-Joe

> Em sáb, 16 de jan de 2016 às 17:27, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> escreveu:
> 
>> On Jan 15, 2016, at 5:54 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> 
>>> 
>>> On Jan 15, 2016, at 7:45 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> 
>>>> On Jan 15, 2016, at 6:42 AM, plx via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> One more “how will this work?” question: optionals.
>>>> 
>>>> Specifically, consider something like this:
>>>> 
>>>> // annoyingly-long protocol:
>>>> protocol ControlExchanging {
>>>>   typealias Context
>>>>   func willTakeControlFrom(other: Self?, context: Context)
>>>>   func didTakeControlFrom(other: Self?, context: Context)
>>>>  
>>>>   func takeControl(context: Context)
>>>>   func cedeControl(context: Context)
>>>>   
>>>>   func willCedeControlTo(other: Self?, context: Context)
>>>>   func didCedeControlTo(other: Self?, context: Context)
>>>> }
>>>> 
>>>> var behavior exchangeState<Value:ControlExchanging where Self:Value.Context> : Value {
>>>>   var value: Value
>>>>   // here:
>>>>   set { 
>>>>     let oldValue = value
>>>>     // boilerplate-choreography begins:
>>>>     newValue.willTakeControlFrom(oldValue, context: self)
>>>>     oldValue.willCedeControlTo(newValue, context: self)
>>>>     oldValue.cedeControl(self)
>>>>     value = newValue
>>>>     newValue.takeControl(self)
>>>>     oldValue.didCedeControlTo(newValue, context: self)
>>>>     newValue.didTakeControlFrom(oldValue, context: self)
>>>>   }
>>>> }
>>>> 
>>>> // numerous extraneous details omitted:
>>>> class GenericSwitchboard<Delegate:ControlExchanging were Delegate.Context == Self> {
>>>> 
>>>>   private(set) weak var [exchangeControl] delegate: Delegate? = nil
>>>> 
>>>> }
>>>> 
>>>> …which presumably won’t actually work unless I’ve either:
>>>> 
>>>> - added an additional implementation that’s typed-as `Value?` 
>>>> - added a conditional-conformance for `ControlExchanging` to `Optional` (easy, but boilerplate)
>>>> 
>>>> ….both of which are workable, neither of which feels optimal (and for the latter, consider also that in many cases such conformances may generally be undesirable).
>>>> 
>>>> Is there a trick/detail I’m missing here?
>>> 
>>> No, I think you've got it. This seems like a general problem to me, though; it'd be nice if protocol conformances could be easily forwarded, for instance from Optional<T> to T.
>> 
>> Any thoughts about how that might work when requirements have a return value?  Or are you just referring to forwarding conformances when the protocol doesn’t have members  with return values?
> 
> I don't have a great answer in mind, unfortunately. You're right that it only really makes sense for "sink"-like protocols, where none of the requirements produce a value, or theoretically for protocols where all results are of associated types that could be optionalized. The sink protocol use case comes up all the time, though, especially with delegates and callbacks, and is one the places where ObjC's nil-messaging behavior feels legitimate.
> 
> -Joe
> 
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160118/01fefcc4/attachment.html>