@swift-ci create

I think this is correct-ish behavior, in that we consider it legal to convert a closure-returning-T to a closure-returning-Void. @xedin?

@belkadan are you sure? The inner

boxIt { 3 }

returns a Box<Int>, we can't just throw that away, make it Void and then return an EventLoopFuture<Void> from

boxIt { boxIt { 3 } }

Sure you can. The closure

{ result boxIt { 3 } }

has type () -> Box<Int>, then that gets converted to () -> Void by throwing away the result, and now you've made a Box<Void>.

@weissi @belkadan is right, there is an implicit conversion from `() -> T` to `() -> Void` for trailing closures which we support and because the type-checker is very smart it infers contextual `Void` as `T` (as only possible for this expression) and then converts result of `() -> Box<Int>` into `() -> Void`.

@xedin & @belkadan why does it do this implicit conversion? If I really wanted an implicit conversion I could write

boxIt { _ = boxIt { 3 } }

This is related to the behavior of the type-checker where it would try to find a solution based on the information given and if there is a possible implicit conversion, it would be taken but the score is going to get increased, so if there are solutions without such conversion they would be considered a "better" match. For single-expression closures we don't model `return` statement so both { return 42 } and { 42 } are equivalent which leads to this behavior.

thanks @xedin that makes sense. Isn't that a bug though? Where it caused trouble for us is the following in the NIO tests: (https://github.com/apple/swift-nio/blob/9f01374169e4f19785edfebdeda0bfef9ae44abf/Tests/NIOTests/SocketChannelTest.swift#L428-L437)

XCTAssertNoThrow(try channel.eventLoop.submit {
            channel.register().map { () -> Void in
                channel.connect(to: serverChannel.localAddress!, promise: connectPromise)
            }.map { () -> Void in
                XCTAssertFalse(connectPromise.futureResult.isFulfilled)
                // The close needs to happen in the then { ... } block to ensure we close the channel
                // before we have the chance to register it for .write.
                channel.close(promise: closePromise)
            }
        }.wait().wait() as Void)

the return value from channel.eventLoop.submit is EventLoopFuture<EventLoopFuture<Void>> which is odd quite unusual (outside of tests) but it makes sense: The outer future fulfils when inner operation channel.register()... has been started, the inner one completes when the channel has registered (we told epoll/kqueue about it) and is connected (TCP connection up). So for the tests it's crucial to write .wait().wait() here otherwise you'll have a race. And to communicate to the reviewers that I did the right thing I started adding as Void. Oddly enough with Swift != 4.1 I can remove one of the .wait() calls, still write as Void and sadly it will still compile. I found that highly surprising and unhelpful.

What is reason we allow implicitly converting a closure () -> T where T != Void to () -> Void ? Again, if the user actually wanted that, there's syntax for that: {{ _ = fn() }} no?

What is reason we allow implicitly converting a closure () -> T where T != Void to () -> Void ?

I don't think I follow this argument, in the minimized example as in this one the contextual type is Void. If there is no Void type in the context it would not be inferred e.g. `let _ = { 42 }` and `let _ = { return 42 }` would both return `() -> Int`.

@xedin but you could write `{ _ = 42 }` (if 42 had side-effects) to make it `() -> Void` if you really wanted. If I write `{ 42 }` I really mean `() -> Int` and I don't want it to be converted to `() -> Void`

Sure, but once again if your context requires () -> Void there is an implicit conversion for that, e.g.

func foo(_: () -> Void) {}
foo { return 42 }

This is very much intentional way the language works but only for `Void` and only single-expression closures. If this is good or bad aside, changing that would require evolution proposal.

@xedin wow, I did not know this would compile, I think that's really bad but you're right evolution is the place to sort that out.

--> https://forums.swift.org/t/remove-implicit-conversions-of-t-where-t-void-to-void-from-the-language/12110