This affects reductions with --> in Madness, because where Swift 1.1 would have inferred this:
let alternation = %"x" | (%"y" --> { _ in 1 })
to have type Parser<String, Either<String, Int>>.Function, in Swift 1.2 it has type Parser<String, String?>.Function (due to the overload of | which drops ignored parses on its right-hand side).
If we replace () with some Ignored type in the relevant API, then we’re insulated from any changes to the semantics of () in future releases of Swift.
Any extant reductions by closures taking advantage of the existing overloads to cause input to be dropped will be broken; however, this is bad behaviour anyway, and too easy to trigger by accident due to Swift’s preference for statements over expressions.
Swift 1.2b1 prefers an overload taking
… -> ()
to one taking… -> T
, and thus type inferencing will produce the incorrect type when using closure literals. While this is clearly a bug, there’s no telling whether it’ll be fixed in Swift 1.2, or at all.This affects reductions with
-->
in Madness, because where Swift 1.1 would have inferred this:to have type
Parser<String, Either<String, Int>>.Function
, in Swift 1.2 it has typeParser<String, String?>.Function
(due to the overload of|
which drops ignored parses on its right-hand side).If we replace
()
with someIgnored
type in the relevant API, then we’re insulated from any changes to the semantics of()
in future releases of Swift.Any extant reductions by closures taking advantage of the existing overloads to cause input to be dropped will be broken; however, this is bad behaviour anyway, and too easy to trigger by accident due to Swift’s preference for statements over expressions.