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