> On Apr 15, 2016, at 10:41 AM, Joe Groff <jgr...@apple.com> wrote: >> On Apr 15, 2016, at 8:29 AM, John McCall via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> 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. > > I feel like the current language no longer represents our reality, though (or > at least, our current ideal vision for reality). We've pretty thoroughly > broken the "functions have one argument" model.
I don't see this syntax as an offshoot of the "functions always have one argument" model. I agree that that model is dead. However, I don't think users require its death to be underlined and written in bold; it only ever surfaced to them in bugs anyway. But many functions do, nonetheless, have only one argument; and because of another change to the model, where argument labels are becoming part of the function's name and not its type, that argument can be written as just a type. So to me, this question is whether we add a weird special-case rule that mandates the use of parentheses because they're required in a bunch of more complex but less common situations. > Changing the type grammar to reflect this seems good to me. I would think of > it as changing the function type grammar to: > > function-type ::= '(' (type (',' type)*)? ')' '->' type > > which, since the argument list can containing 0, 1, or many individual > arguments, makes the parens more grammatically necessary. This is tautological. John. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution