> On Apr 16, 2016, at 10:10 AM, Patrick Gili <[email protected]> > 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. -Chris > > -Patrick > >> On Apr 15, 2016, at 1:38 PM, Chris Lattner via swift-evolution >> <[email protected]> wrote: >> >> >>> On Apr 15, 2016, at 5:11 AM, David Hart <[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? >> >> 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 >>>> <[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
