Doesn't really seem worth the trouble to me. It is fine as it is. Other languages like Java and Scala allow this short hand and Swift allows it in closures. Not that I am that fussed since the brackets are no big deal. <span></span><br><br>On Saturday, 16 April 2016, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On Apr 15, 2016, at 2:47 PM, Joe Groff <<a href="javascript:;" onclick="_e(event, 'cvml', 'jgroff@apple.com')">jgroff@apple.com</a>> wrote:<br>
>> On Apr 15, 2016, at 11:43 AM, John McCall <<a href="javascript:;" onclick="_e(event, 'cvml', 'rjmccall@apple.com')">rjmccall@apple.com</a>> wrote:<br>
>>> On Apr 15, 2016, at 10:41 AM, Joe Groff <<a href="javascript:;" onclick="_e(event, 'cvml', 'jgroff@apple.com')">jgroff@apple.com</a>> wrote:<br>
>>>> On Apr 15, 2016, at 8:29 AM, John McCall via swift-evolution <<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a>> wrote:<br>
>>>><br>
>>>>> On Apr 14, 2016, at 10:50 PM, Chris Lattner <<a href="javascript:;" onclick="_e(event, 'cvml', 'clattner@apple.com')">clattner@apple.com</a>> wrote:<br>
>>>>> On Apr 14, 2016, at 10:40 PM, John McCall <<a href="javascript:;" onclick="_e(event, 'cvml', 'rjmccall@apple.com')">rjmccall@apple.com</a>> wrote:<br>
>>>>>>>> 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.<br>
>>>>>>>> The parentheses are grammatically unnecessary in most cases (by frequency of use in higher-use programming, not by feature count).<br>
>>>>>>><br>
>>>>>>> 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.<br>
>>>>>><br>
>>>>>> "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?<br>
>>>>><br>
>>>>> 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.<br>
>>>><br>
>>>> Default arguments are not allowed in the type grammar. Nor are different internal vs. external labels.<br>
>>>><br>
>>>>> As a concrete example, surely you aren’t arguing that we should support:<br>
>>>>><br>
>>>>> let x : Int… -> Int<br>
>>>>><br>
>>>>> are you?<br>
>>>><br>
>>>> No, but that's because the ... is a reference to the rest of the tuple and doesn't read correctly outside of one.<br>
>>>><br>
>>>>>>>> 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).<br>
>>>>>>><br>
>>>>>>> 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.<br>
>>>>>><br>
>>>>>> So we should require function argument labels in function types?<br>
>>>>><br>
>>>>> Uhm, yes, we already do. In:<br>
>>>>><br>
>>>>> let x : (a : Int) -> Float<br>
>>>>> let y : (Int) -> Float<br>
>>>>> let z : Int -> Float<br>
>>>>><br>
>>>>> x and y have different (but compatible) types. y and z have identical types (sugared differently).<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> 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".<br>
>>>><br>
>>>> The current language composes naturally here, and your proposal feels like an odd extra rule.<br>
>>><br>
>>> 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.<br>
>><br>
>> I don't see this syntax as an offshoot of the "functions always have one argument" model. I agree that that model is dead.<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>>> Changing the type grammar to reflect this seems good to me. I would think of it as changing the function type grammar to:<br>
>>><br>
>>> function-type ::= '(' (type (',' type)*)? ')' '->' type<br>
>>><br>
>>> which, since the argument list can containing 0, 1, or many individual arguments, makes the parens more grammatically necessary.<br>
>><br>
>> This is tautological.<br>
><br>
> I don't think it is just a tautology. Without encoding it in the grammar, there's an ambiguity between tuples and multiple arguments; () -> T could mean either "takes a single () argument" or "takes no arguments". We could "obviously" disambiguate in favor of the latter interpretation, but then you're introducing special cases in the other direction to keep the U -> T syntax working.<br>
<br>
This is a fair point, and one which would come up with (Int,Int) -> Float as well — maybe the user really does mean to pass a single value that's an (Int,Int) pair. I'm not sure this really works out to being a special case at the user level, though, since in either model the user trying to write a function that takes a single tuple-typed parameter simply has to introduce the extra parens: (()) -> Float or ((Int, Int)) -> Float. (Assuming that the type system preserves that structure in any way, of course.)<br>
<br>
John.<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote><br><br>-- <br>-- Howard.<br>