> On Apr 15, 2016, at 11:27 AM, David Owens II <da...@owensd.io> wrote: > > Hmm... I don't think this is clearer: > > let fn: (Int) -> (Int) -> Int > > I think it's much less readable and really, the () are syntactically > redundant: the -> is really what distinguishes this as a function. > > Also, this would look like a error now: > > let fn: (Int) -> () > > Did the user mean that it returns nothing, or did they forget the rest of the > function signature?
Hi David, I’m not sure what you’re saying here. The two types above are already valid, and this proposal doesn’t affect that. -Chris > > I'd like to see more consistency and less redundancy, including special > cases, in the language in general, but this change just seems to make it > different in another way, but still not consistent throughout the language > constructs. > > -David > > >> On Apr 14, 2016, at 9:57 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@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) -> () >> >> Thoughts? >> >> -Chris >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
