Exactly, everything else is simply an excuse and nothing more. Tuple
destructuring is not even aligned to enum case patterns at all, because it only
uses the shorthand version and does not allow us to write the full explicit
version.
enum Foo { case a(b: Int, c: Int) }
switch Foo.a(b: 42, c: 0) {
case let .a(b: num1, c: num2): …
// Or the explicit longer version:
case .a(b: let num1, c: let: num2): …
}
Tuple destructuring do not support the latter, which in our previous example
would really be unambiguous.
let tuple: (x: Int, y: Int) = (3, 1)
// Short version:
let (x: Int, y: Double): (x: Int, y: Int) = tuple
// Not supported explicit version:
(x: let Int, y: let Double) = tuple
Why is that the case? Because tuple destructuring creates another tuple on the
left side of the same tuple type as the tuple on the right side of the
assignment operator.
Erica Sudan has a proposal, which could change that for guards and ifs (second
design):
https://github.com/erica/swift-evolution/blob/783fdf8d3723d51f350b917af23c207cebdd1ad7/proposals/9999-ifcaseguardcase.md
--
Adrian Zubarev
Sent with Airmail
Am 8. Mai 2017 um 07:16:50, David Hart via swift-evolution
([email protected]) schrieb:
On 7 May 2017, at 00:21, Xiaodi Wu via swift-evolution
<[email protected]> wrote:
To which human would it be misleading?
To the writer? No, because the compiler will warn you right away. By the time
you're done with writing the first line, it'll warn you that Int and Double are
unused variables. And if you try to use x and y, you get an error.
To the reader? Only if the writer knowingly wrote this misleading code. In
other words, it's a nice puzzle, but no reader will encounter this in
real-world code, unless they're being tormented by the writer on purpose.
IMHO, the fact that the compiler warns you does no change the fact that it's a
very confusing part of the language. It should not be an excuse for fixing it.
Consistency teaches us to expect a type after a colon.
On Sat, May 6, 2017 at 16:28 Brent Royal-Gordon <[email protected]> wrote:
> On May 5, 2017, at 11:06 PM, Xiaodi Wu <[email protected]> wrote:
>
> The identifier after a colon is *never* a type in any pattern matching, and
> there's no need of which I'm aware to support type annotations in pattern
> matching. We put colons after labels, and the current syntax is perfectly
> consistent here. What is the defect you're trying to cure?
The defect underlying this proposal: `let (x: Int, y: Double)` looks like it's
declaring `x` and `y` of types `Int` and `Double`, but it's actually declaring
`Int` and `Double` and binding them to `x` and `y`. Your code's meaning is
perfectly unambiguous to the compiler, of course, but it's misleading to the
human.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
