> On Feb 22, 2017, at 3:14 PM, David Hart <da...@hartbit.com> wrote:
>
> Hi Matthew,
>
> Finally found time to read the proposal. Much better than the previous
> iterration. I’m not a huge fan of the proposed syntax either but don’t have
> the energy for bike shedding :)
The requirements I have for the syntax are:
* it must work with both bound instance method references and closures
* it must be reasonably concise
* it must have some relationship to `@guarded` arguments
The last requirement is the reason I opted for a prefix sigil. The closest
parallel we have is `inout` and that uses a prefix sigil. As soon as you
decide to use a prefix sigil `?` is the obvious choice for this behavior.
I am certainly open to hearing alternatives, but they should address each of
the three requirements listed above. (I mention this mostly in case anyone
else reading does have energy to bikeshed on this).
>
> As a side note, I’d like to say that I would not use this very often. I much
> more often use unowned capture variables when its clear that the closure
> can’t outlive the captured variable. For example, my code often looks like
> this:
>
> class MyViewController : UIViewController {
> var button: ActionButton!
>
> override func viewDidLoad() {
> super.viewDidLoad()
>
> button.addAction { [unowned self] in
> print("self: \(self)")
> }
> }
> }
Hi David. Thanks for replying! I’m glad you like this approach better. I
think I have finally hit on an elegant mechanism for providing safer default
semantics for callbacks arguments along with a much more concise syntax for a
very widespread pattern. I’ve been thinking about this problem ever since
Swift first came out and am pretty pleased with this approach.
That’s certainly a reasonable way for somebody who really understands what
they’re doing to write code. There is an overhead in the weak references and
the guards that isn’t necessary in this case. The good news is that this would
still be valid code within a guarded closure because the new proposal allows
you to override the guarded behavior using the capture list.
>
>> On 20 Feb 2017, at 18:01, Matthew Johnson via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>
>>> On Feb 20, 2017, at 8:33 AM, Florent Bruneau <florent.brun...@intersec.com
>>> <mailto:florent.brun...@intersec.com>> wrote:
>>>
>>>
>>>
>>>> Le 20 févr. 2017 à 06:35, Brent Royal-Gordon via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>>>>
>>>>> On Feb 19, 2017, at 2:57 PM, Matthew Johnson via swift-evolution
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>
>>>>> A guarded closure may be created by prefixing a bound instance method
>>>>> reference with the `?` sigil:
>>>>>
>>>>> ```swift
>>>>> let guarded = ?myObject.myMethod
>>>>>
>>>>> // desugars to:
>>>>> let guarded = { [weak myObject] in
>>>>> guard let myObejct = myObject else {
>>>>> return
>>>>> }
>>>>> myObject.myMethod()
>>>>> }
>>>>> ```
>>>>
>>>> I like this in principle, but I don't like the syntax. The `?` is cryptic
>>>> and looks pretty strange in prefix position. I think what I'd like to see
>>>> is:
>>>>
>>>> let guarded = weak myObject.myMethod
>>>
>>> I like the idea of weak closures even if this may conflict with the fact
>>> closures are already internally refcounted object. While we cannot have
>>> weak references to closure in the language, using `weak` might be
>>> misleading in some ways.
>>>
>>> In term of syntax, the `weak` keyword looks nice (much better than the '?'
>>> and @guarded once). The weak could be used on both sides.
>>>
>>> ```swift
>>> addAction(action: weak Action)
>>> addAction(action: weak myAction)
>>> ```
>>>
>>> However, I think this might still look weird with inlined closures, in
>>> particular in case you use the suffix syntax for closures:
>>>
>>> ```swift
>>> addAction() weak {
>>> /* */
>>> }
>>> ```
>>
>>
>> We wouldn’t want to use `weak` if this has the guarded behavior I proposed.
>> We could use `guarded` though.
>>
>> There are a couple of important things enabled by having the language
>> implement the guarded behavior.
>>
>> First, the implementation could release the entire closure context as soon
>> as one of the guarded captures is released. This is not possible if users
>> write the code out manually. Second, in the future directions I discuss
>> allowing libraries to detect that the guard has been triggered and the
>> closure has become a no-op. This is also not possible when users write the
>> guard out manually and would be quite desirable for libraries that want to
>> discard their reference to the closure after it becomes a no-op.
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
