> On Apr 15, 2016, at 5:11 AM, David Hart <da...@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. -Chris > (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@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 >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution