On Apr 14, 2016, at 10:40 PM, John McCall <[email protected]> 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.
As a concrete example, surely you aren’t arguing that we should support:
let x : Int… -> Int
are you?
>>> 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).
-Chris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
