[swift-evolution] [Discussion] Parentheses

[Vladimir.S]

On 06.07.2016 20:51, Joe Groff wrote:
>
>> On Jul 6, 2016, at 7:47 AM, Vladimir.S via swift-evolution <swift-evolution at 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.

Yes, I'm talking about parameter list in function. Perhaps I'm missing 
something... Quotation from proposal:

 >----------------<
To declare a function type with one tuple parameter containing n elements 
(where n > 1), the function type's argument list must be enclosed by double 
parentheses:

let a : ((Int, Int, Int)) -> Int = { x in return x.0 + x.1 + x.2 }
 >----------------<

Oh... Or do you(and Jens) mean that this:
let x : (Int, Int) = (1,2)
will be the same as this:
let x : ((Int, Int)) = (1,2)
? and about
func foo(_ x: ((Int, Int))) { print(x) }
vs
func foo(_ x: (Int, Int)) { print(x) }
?
In this case yes, sorry for misunderstanding, SE-0110 will not change this. 
I don't see any ambiguity here: foo will be called as
foo((1,2)) - clearly that tuple is sent as argument.

>
> -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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>