I think the source breakage here, if any in actual codebases, is minor enough that the patch could go through.
~Robert Widmann > On Mar 8, 2017, at 2:11 AM, rintaro ishizaki via swift-dev > <swift-dev@swift.org> wrote: > > Hi all, > > I'm fixing #if condition processing in this PR > https://github.com/apple/swift/pull/7955 > <https://github.com/apple/swift/pull/7955> > > It resolves these issues: > > A) SR-3663 <https://bugs.swift.org/browse/SR-3663>: Precedence of '&&' and > '||' and short-circuit rule of them. > > #if false || true && false > print("true") > #endif > > This used to evaluate to 'true'. > > B) SR-4032 <https://bugs.swift.org/browse/SR-4032>: Version check with binary > operator. > > #if swift(>=5.0) && FOO > Some Swift 5 code here > #endif > > I believe, this block should not be parsed. > > C) SR-3663 <https://bugs.swift.org/browse/SR-3663>: Invalid condition after > short-circuit binary operator. > > #if true || true * This is not <acceptable>! > #endif > > This used to be accepted. > > D) SR-4031 <https://bugs.swift.org/browse/SR-4031>: Compound name in the > condition > > #if FOO(_:) > #elseif os(foo:)(macOS) > #elseif os(Linux(foo:bar:)) > #endif > > This used to be accepted. > > In the PR, I keep A) and B) behavior in -swift-version 3 mode. > However, as for C) and D), I don't think it's worth to keep them even in > Swift3 mode, because they are obviously wrong. > > What do you think? Do we need accept them in Swift3 mode? > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
