[swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"
clattner at apple.com
Sat Apr 16 22:48:01 CDT 2016
> On Apr 16, 2016, at 10:10 AM, Patrick Gili <gili.patrick.r at gili-labs.com> wrote:
> As an alternative, could we require the parens on the return. For example:
> (Int) -> (Float)
> (String) -> ()
> () -> ()
> () -> (Double)
> This looks cleaner, improves consistency, and simplifies the syntax (i.e., no need to remember when parens are necessary).
-1 from me. And the rationale that I provided for this pitch doesn’t support it: unlike arguments, return types really are just types, they don’t align with other syntactic productions that have magic argument behavior.
I’ll write up a formal proposal for more discussion.
>> On Apr 15, 2016, at 1:38 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>>> On Apr 15, 2016, at 5:11 AM, David Hart <david at hartbit.com> wrote:
>>> If the original rationale is gone, shouldn’t we also get rid of the empty tuple-type and replace it by a full-blown Void instead of Void being a typealis for the empty tuple?
>> This could be done, but it would make the language larger and less consistent. It would require introducing a new concept (a first class Void type). Further, at some point we may have the ability to define algorithms over arbitrary width tuples (e.g. perhaps like C++ variadic templates) and that benefits from having the empty tuple as a base case.
>>> (Int) -> Float
>>> (String) -> Void
>>> () -> Void
>>> () -> Double
>>> It looks more consistent to me.
>>>> On 15 Apr 2016, at 06:57, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>>>> We currently accept function type syntax without parentheses, like:
>>>> Int -> Float
>>>> String -> ()
>>>> etc. The original rationale aligned with the fact that we wanted to treat all functions as taking a single parameter (which was often of tuple type) and producing a tuple value (which was sometimes a tuple, in the case of void and multiple return values). However, we’ve long since moved on from that early design point: there are a number of things that you can only do in a parameter list now (varargs, default args, etc), implicit tuple splat has been removed, and the compiler has long ago stopped modeling function parameters this way. Beyond that, it eliminates one potential style war.
>>>> Given all this, I think it makes sense to go for syntactic uniformity between parameter list and function types, and just require parenthesis on the argument list. The types above can be trivially written as:
>>>> (Int) -> Float
>>>> (String) -> ()
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>> swift-evolution mailing list
>> swift-evolution at swift.org
More information about the swift-evolution