+1 to the proposal > On 15 Apr 2016, at 13:11, David Hart via swift-evolution > <[email protected]> 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? > > (Int) -> Float > (String) -> Void > () -> Void > () -> Double > > It looks more consistent to me.
Not sure about whether I’m a +1 to this; although I use Void everywhere already, I kind of get the rationale behind it being a zero element tuple, as single return types are basically one element tuples, and you can return tuples of any size you like. Also, as an aside, I kind of liked that all functions took a tuple as their sole argument; I only use variadic parameters where they’re required for literal conformance (and I’ve no idea how else you’d handle that), but I suppose that ship has sailed. >> On 15 Apr 2016, at 06:57, Chris Lattner via swift-evolution >> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
