There is nothing consistent in the following example: let (x: a, y: b) = (x: 0, y: 1) Labels are not simple descriptors, they signal that the assignment for the RHS will happen to some constant associated with the label. The assignment direction is from right-to-left! Labeled tuple destructuring breaks this rule. Furthermore you’re not allowed to think of a and b as if they were some inout variables for the purpose of the assignment there.
The syntax is ambiguous to the rest of the language and also exactly the case why the following code is not only confusing but simply mentally wrong: let (x: Int, y: Double) = (3, 1) let result = Int + Double // 4 -- Adrian Zubarev Sent with Airmail Am 6. Mai 2017 um 08:06:30, Xiaodi Wu (xiaodi...@gmail.com) schrieb: 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? On Fri, May 5, 2017 at 22:42 Brent Royal-Gordon <br...@architechies.com> wrote: Sorry for wrecking the threading, but any chance we could change the syntax to: let (x myX: Int, y myY: Int) = ... That would ensure the identifier after the colon was always treated as a type. I suppose if you wanted to infer the type, it'd be: let (x myX, y myY) = ... -- Brent Royal-Gordon Sent from my iPhone On May 5, 2017, at 12:04 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote: If we ban reordering now, than I don’t see choosing different names in tuple destructuring as a strong argument of allowing labels there let (x: a, y: b). They’re literally the same as one would write comments inside the destructured tuple let (/* my x */ x, /* my y*/ y).
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
