on Fri Apr 15 2016, Brent Royal-Gordon <swift-evolution@swift.org> wrote:
>> 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? > > While it's technically correct, I agree with John's assessment that > this is "fussy". `T -> U` doesn't confuse people Do we have any data on this (in either direction)? Personally, it has always seemed obvious that T -> U being a function type would be quite novel to some people, considering the number of times I've seen in Haskell texts that (surprise!) you don't need parentheses to invoke functions. I guess those are invocations and we're talking about declarations here, but declaration-follows-use is a kind of principle the language tries to uphold. But that's just intuition. Data would be very interesting. > and doesn't confuse the compiler; removing it would require extra > punctuation for no particular reason. It would also become > inconsistent with the paren-less `{ param in … }` syntax, which I > think is very important for keeping usage sites simple and clean. > > What I think we *should* eliminate, however, is using `Void` to mean > "no arguments" in a closure type. `Void -> Int` should mean that the > type takes one argument which happens to be an empty tuple. If you > want no arguments, write `() -> Int`. Similarly, a typedef for a > 2-tuple (like `Dictionary.Element`) should be recognized as one tuple > parameter, not two singleton parameters. With that in place, `T -> U` > becomes merely a convenient shorthand for the canonical form, `(T) -> > U`. > > I mean, it's not that big a deal; if you remove it, everyone will type > extra parentheses and live with it. But recognize that doing so would > improve the language, not the end-user experience. -- Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution