> On Apr 14, 2016, at 10:50 PM, Chris Lattner <clatt...@apple.com> wrote: > On Apr 14, 2016, at 10:40 PM, John McCall <rjmcc...@apple.com> wrote: >>>> To me, the unparenthesized style suggests that the input and output are >>>> peers, which feels more natural for the sort of value-to-value >>>> transform/predicate where this most commonly occurs. Parenthesizing the >>>> input feels fussier, which contributes to a sense that the argument is >>>> just one component to producing the result. >>>> The parentheses are grammatically unnecessary in most cases (by frequency >>>> of use in higher-use programming, not by feature count). >>> >>> I agree with your point that many simple higher order programming examples >>> (e.g. map, filter, etc) take a single argument. That said, I don’t agree >>> that this means that we should syntactically privilege this special case. >> >> "Special case" is a loaded phrase. Why is it a special case as a parameter >> if it isn't a special case as a result? > > Because, as I tried to explain in my original post, parameters *are* a > special case. The result type of a function is just a type. The parameter > list allows things that types do not: default arguments and variadics.
Default arguments are not allowed in the type grammar. Nor are different internal vs. external labels. > As a concrete example, surely you aren’t arguing that we should support: > > let x : Int… -> Int > > are you? No, but that's because the ... is a reference to the rest of the tuple and doesn't read correctly outside of one. >>>> I guess the flip side is that call and declaration syntax both require >>>> parentheses (unless the only argument is a trailing closure), but again, >>>> we had strong justifications for that: declarations would always be >>>> ambiguous without parens, and calls would have serious problems (and the >>>> style-wars factor would be much larger, especially now with mandatory >>>> keyword arguments by default). >>> >>> Right, but regardless of *why* we always require parens on Decls and >>> ApplyExprs, we really do (and that isn’t going to change). Being >>> consistent between func decls and function types is quite important IMO. >> >> So we should require function argument labels in function types? > > Uhm, yes, we already do. In: > > let x : (a : Int) -> Float > let y : (Int) -> Float > let z : Int -> Float > > x and y have different (but compatible) types. y and z have identical types > (sugared differently). When I said "function type", I was referring to this production in the type grammar, not the type signature component of function declarations. I'm not sure how I could've been clearer on that without actually using the names of grammatical productions. My point was that allowing a function type to be written as "(Int) -> Float" is already inconsistent with function declarations, because that is not legal function declaration syntax; you would have to write "(_ : Int) -> Float". The current language composes naturally here, and your proposal feels like an odd extra rule. John. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
