> On Apr 14, 2016, at 10:28 PM, Chris Lattner <clatt...@apple.com> wrote: > > On Apr 14, 2016, at 10:21 PM, John McCall <rjmcc...@apple.com> wrote: >> >>> On Apr 14, 2016, at 9:57 PM, Chris Lattner via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> We currently accept function type syntax without parentheses, like: > >> 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? > In many places in the Swift grammar we aim for consistency, even if it means > a bit more punctuation in specific cases. This is not greatly in evidence. We have a lot of special-case syntax. >> Our grammar generally allows grammatically-unnecessary parentheses to be >> omitted (except the C-style for loop, until we killed it) — I guess you >> could count function call syntax, but we had strong reasons there that don't >> seem to apply here. We notably chose to deviate from C statement grammar >> specifically to allow unnecessary parentheses to be omitted. This would >> feel weirdly inconsistent with that. > > We allow parens to be omitted from control flow expressions, where they are > redundant with paren exprs. I don’t see how that translates to our type > grammar. The grammatical and semantic purpose of parentheses is identical in both grammars. >> 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? John. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
