So I suppose you feel this case is different from the (unsafe) implicitly
unwrapping of optionals with the “!” operator.
Why do you feel the situation is different?
I agree that it's a somewhat similar situation, at least if the function
declaration were made explicit with a `@nonescaping` ke
> On Oct 9, 2016, at 5:07 PM, Jean-Denis Muys via swift-users
> wrote:
>
> Here is a contrived reduction of my problem
>
> func mainFunction(closure:(Int) -> Int) -> Int {
>
> func closureDoubled(_ n: Int) -> Int {
> let result = closure(n)
> return 2*result
> }
>
>
So I suppose you feel this case is different from the (unsafe) implicitly
unwrapping of optionals with the “!” operator.
Why do you feel the situation is different?
> On 10 Oct 2016, at 17:34, Ole Begemann wrote:
>
>> When I declare my closure as @noescape, (the default), I explicitly tell
When I declare my closure as @noescape, (the default), I explicitly tell
the compiler that, despite the fact closing over it *may* allow it to
escape, I, the programmer, guarantee that it will not.
I would understand a warning, but I don’t understand that the compiler
insists on putting out an er
Thanks Ole,
You are perfectly right regarding the error message. For some reason, I misread
it. I am sorry about that.
The actual error message, as you point out, makes much more sense!
The rest of your explanation makes sense too, except:
When I declare my closure as @noescape, (the default),
Thank you, Ole. Your reply teaches me a lot.
Zhaoxin
On Mon, Oct 10, 2016 at 6:52 PM, Ole Begemann via swift-users <
swift-users@swift.org> wrote:
> The line "let result = closure(n)" is refused by the compiler with the
>> error message "declaration over non closing parameter may allow it to
>>
The line "let result = closure(n)" is refused by the compiler with the
error message "declaration over non closing parameter may allow it to
escape".
First off, while I know what an escaping or a non-escaping closure is, I
find this error message utterly impossible to understand. To begin with,
t
> It is just like there were two ways to do the job, you thought it worked
in this way, but it chose the other way. Both ways lead to the same result.
I think it is because the compiler **flatten** your inner function instead
of calculated the result.
The variable scope of `closure` is outside th
It seems to me you are shooting while blindfolded.
> I changed you code `let result = closure(n)` to `let result = closure(1)`. I
> thought that should eliminate the error. It didn't. The compiler asked me to
> change the whole code as below:
Why did you expect changing which argument to send
I changed you code `let result = closure(n)` to `let result = closure(1)`.
I thought that should eliminate the error. It didn't. The compiler asked me
to change the whole code as below:
func mainFunction(closure: @escaping (Int) -> Int) -> Int {
func closureDoubled(_ n: Int) -> Int {
Here is a contrived reduction of my problem
func mainFunction(closure:(Int) -> Int) -> Int {
func closureDoubled(_ n: Int) -> Int {
let result = closure(n)
return 2*result
}
let temp1 = closure(1)
let temp2 = closureDoubled(1)
return temp1+temp2
}
The
11 matches
Mail list logo
