Hi Erica, thanks for restarting the discussion—I hope that it will be
considered on topic for stage 2.
I agree that the part with preventing let .case(existingVar, newVar) should
be moved out of the proposal, because these issues are orthogonal. So the
options with ~= and := will differ only in that the former overloads an
existing custom operator.
I prefer the version with keywords instead of operators, because
overloading any custom operator can be confusing.
I think that pattern should be on the right, because that’s the order of
computation: first the expression, then pattern matching. That’s also how
switch looks: first expression, then patterns.
// That's what current if-case looks like. Counterintuitive!do {
case .success(let value): …
case .failure(let value): …
} switch computeResult(foo(frobnicate), bar)
Examples with matches and is, for extra brevity:
if computeResult(foo(frobnicate), bar) matches .success(let value) { … }
if computeResult(foo(frobnicate), bar) is .success(let value) { … }
I also considered using ->. It would never be ambiguous in this context,
but keywords still look better IMO:
if computeResult(foo(frobnicate), bar) -> .success(let value) { … }
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
