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?
> On Mar 28, 2017, at 8:49 AM, Elia Cereda via swift-users
> <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
> https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
