> On Mar 28, 2017, at 11:21 AM, Michael Ilseman <milse...@apple.com> wrote:
>
> CC Doug Gregor, who git blame tells me wrote this part.
>
> Doug, this slightly predates noescape-by-default. Is this a bug or as
> intended?
It’s a bug; the point here is that we can do recovery asynchronously, so it
should be @escaping. We missed the annotation when noescape-by-default landed.
- Doug
>
>
>> On Mar 28, 2017, at 8:49 AM, Elia Cereda via swift-users
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>
>> Hi Dennis,
>>
>> Thanks for your answer. I can see that my message needs some more context:
>> RecoverableError is a protocol in the standard library that can be
>> implemented to opt in to the error recovery mechanism available on macOS.
>> attemptRecovery(optionIndex, resultHandler:) is one of the methods that have
>> to be implemented to conform to the protocol.
>>
>> Here you can find the other ones:
>>
>> /// Describes an error that may be recoverable by presenting several
>> /// potential recovery options to the user.
>> public protocol RecoverableError : Error {
>>
>> /// Provides a set of possible recovery options to present to the user.
>> public var recoveryOptions: [String] { get }
>>
>> /// Attempt to recover from this error when the user selected the
>> /// option at the given index. This routine must call handler and
>> /// indicate whether recovery was successful (or not).
>> ///
>> /// This entry point is used for recovery of errors handled at a
>> /// "document" granularity, that do not affect the entire
>> /// application.
>> public func attemptRecovery(optionIndex recoveryOptionIndex: Int,
>> resultHandler handler: (Bool) -> Swift.Void)
>>
>> /// Attempt to recover from this error when the user selected the
>> /// option at the given index. Returns true to indicate
>> /// successful recovery, and false otherwise.
>> ///
>> /// This entry point is used for recovery of errors handled at
>> /// the "application" granularity, where nothing else in the
>> /// application can proceed until the attempted error recovery
>> /// completes.
>> public func attemptRecovery(optionIndex recoveryOptionIndex: Int) -> Bool
>> }
>>
>> As you can see, there are two attemptRecovery methods. In my mind the first
>> one was meant to be used for asynchronous operations, where you run some
>> recovering code in background and then report its result back to the caller.
>>
>> The problem is that the handler is not marked as @escaping and as such it
>> can only be used inside the body of attemptRecovery. I was wondering if this
>> was an oversight from the stdlib team or if this was a deliberate design
>> decision.
>>
>> I just saw that the method is still not marked as @escaping in master
>> (https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSError.swift#L105
>>
>> <https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSError.swift#L105>),
>> so I’d like to know what its intended use case is, since the obvious one
>> (asynchronous recovery) is prevented by the missing annotation.
>>
>> Thanks,
>> Elia Cereda
>>
>>> Il giorno 28 mar 2017, alle ore 17:33, Dennis Weissmann
>>> <den...@dennisweissmann.me <mailto:den...@dennisweissmann.me>> ha scritto:
>>>
>>> Hey Elia,
>>>
>>> I'm currently on mobile and don't really know what you're talking about
>>> (what is RecoverableError?) but you say it's a block, and if the closure is
>>> optional, it is @escaping by default.
>>>
>>> Did you see
>>> https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160905/003185.html
>>>
>>> <https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160905/003185.html>
>>>
>>> - Dennis
>>>
>>> Sent from my iPhone
>>>
>>> On 23. Mar 2017, at 10:07 AM, Elia Cereda via swift-users
>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>
>>>> I'd like to bump this issue, since it has been some time and it hasn't
>>>> been addressed.
>>>>
>>>> Thanks,
>>>> Elia Cereda
>>>>
>>>> Il giorno 03 mar 2017, alle ore 21:33, Elia Cereda <eliacer...@gmail.com
>>>> <mailto:eliacer...@gmail.com>> ha scritto:
>>>>
>>>>> I’m wondering why the resultHandler block on
>>>>> RecoverableError.attemptRecovery(optionIndex, resultHandler:) is not
>>>>> marked @escaping?
>>>>>
>>>>> I’m trying to invoke some recovering code that executes asynchronously,
>>>>> then reports if it was successful or not and I thought that this was the
>>>>> right strategy. As far as I can tell, without @escaping that method loses
>>>>> all it’s purpose and becomes essentially equivalent to
>>>>> attemptRecovery(optionIndex:).
>>>>>
>>>>> So, I’d like to ask.
>>>>> 1. Is it a bug or that method is non-escaping on purpose?
>>>>> 2. If it is a bug, is there a workaround that can be applied pending a
>>>>> fix in a future version of Swift?
>>>>> 3. If it was a deliberate decision, what's the supported method of
>>>>> asynchronously invoking error recovery code?
>>>>>
>>>>> Seeing that this wasn’t changed in Xcode 8.3b2, I think it unlikely that
>>>>> this was an oversight.
>>>>>
>>>>> Thanks,
>>>>> Elia Cereda
>>>>>
>>>> _______________________________________________
>>>> swift-users mailing list
>>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-users
>>>> <https://lists.swift.org/mailman/listinfo/swift-users>
>>
>> _______________________________________________
>> swift-users mailing list
>> swift-users@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users
>
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
