In an argument conversion context, an argument value of type
(A, B...) -> () can be passed where a parameter type of
((A, B...)) -> () is declared (here I'm using A/B to denote any number of positional arguments, not a "variadic" argument type per se).
As a consequence of this rule, you're seeing
() -> () converting to
(()) -> (), which is just a special case with no arguments.
The rule does not apply in non-argument position, so
(Some) -> () -> () does not convert to
(Some) -> (()) -> (), since the function conversion is the result type of a function conversion in argument position, and the "top level" of an argument.
This came about because in Swift 2 and older,
((A, B...) -> () and
(A, B...) -> () were actually the same type. All function types had a single input, which could be a tuple, and furthermore, for any type T, T and
(T) were the same type. In Swift 3, a set of proposals were adopted that actually changed function types to conceptually take multiple arguments and not a single argument that may be a tuple. However the internal representation was not changed in Swift 3 because it was such a big change that touched all parts of the compiler. In Swift 4, we started adopting the constraint solver to use the correct representation, and that uncovered a number of cases where the compiler was allowing this "tuple splat" through. Because of community feedback we decided to formalize it as a language rule, but only in argument conversion position.
In Swift 5 the internal representation of function types now fully conforms to the updated understanding of the language semantics and this conversion exists as an explicitly-implemented part of the type checker.
I'm not totally happy it exists since it can create confusion, but overall the alternative of having poor ergonomics when, eg, mapping over a dictionary, was worse.