> On Jul 6, 2016, at 7:47 AM, Vladimir.S via swift-evolution > <swift-evolution@swift.org> wrote: > > On 06.07.2016 3:57, Jens Persson via swift-evolution wrote: >> Please feel free to ignore this naive attempt to engage in this discussion. >> >> My understanding of the history of Swift's tuples, argument lists, pattern >> matching, associated values, etc. in two steps: >> >> 1. Initial Idealism *: >> Simple powerful heavily reused general concept. >> >> 2. Iterative pragmatism / reality *: >> Complicated (exceptions to) rules. >> >> (* Inevitably not taking everything in to account.) >> >> Has there been any recent attempts to outline a more or less complete >> redesign for these things, returning to step 1 so to speak, but taking into >> account what has now been learned? >> >> >> As a side note (and supposedly trivial to most but me): >> >> Parentheses (parenthesized expressions in the grammar?) are used for all of >> these parts of the language, and they probably should be, but perhaps the >> similarities and differences between the language constructs can be made >> clearer to see by pretending that argument and parameter lists are written >> with eg ≪≫ and tuples with eg ⊂⊃, etc.? >> >> For example, I think most people agree that we should be able to use >> "sloppy/forgiving" parenthetical grouping in code such as: >> ((1 + (2 * 3)) * (x + (-5))) - y >> This is fine and can be used to express meaning for the person >> reading/writing, even though it means that some of the parens can become >> superfluous to a machine interpretation. >> >> AFAICS this need not have anything to do with tuples and/or parameter >> lists, but the fact that Swift is treating eg: >> func foo(x: ((((Int))))) { print(x) } >> as >> func foo(x: Int) { print(x) } >> and >> ((Int, Int)) >> as >> (Int, Int) > > If SE-0110 will be accepted, ((Int, Int)) will mean "1 tuple with Int,Int > fields" and (Int, Int) will mean only "list of two Ints in parameters"
((Int, Int)) would still be equivalent to (Int, Int). SE-0110 only concerns parameter lists in function types. -Joe > >> seems to suggest that it somehow does. >> >> Or maybe I have just forgotten the reasons for why there can be no such >> thing as (a nested) single element tuple (type). >> >> I also can't remember what the pros & cons of disallowing labeled single >> element tuples were. >> >> Happy to be corrected and pointed to relevant reading : ) >> >> /Jens >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution