Although I personally have no strong opinion on this proposal yet,
it is clear for me that something is wrong with function type sintax&Void&().
Right now we have such situation, when all the next code is OK, can be
compiled and run, but each fX has the same meaning:
typealias f1 = () -> ()
typealias f2 = () -> Void
typealias f3 = () -> (Void)
typealias f4 = () -> (())
typealias f5 = () -> ((((((()))))))
typealias f6 = Void -> ()
typealias f7 = Void -> Void
typealias f8 = Void -> (Void)
typealias f9 = Void -> (())
typealias f10 = Void -> ((((((()))))))
typealias f11 = (Void) -> ()
typealias f12 = ((((((())))))) -> Void
typealias f13 = (()) -> ((Void))
typealias f14 = ((())) -> (())
typealias f15 = ((Void)) -> ((((((()))))))
func f() -> Void {
}
let fv1 : f1 = f
let fv2 : f2 = f
let fv3 : f3 = f
let fv4 : f4 = f
let fv5 : f5 = f
let fv6 : f6 = f
let fv7 : f7 = f
let fv8 : f8 = f
let fv9 : f9 = f
let fv10 : f10 = f
let fv11 : f11 = f
let fv12 : f12 = f
let fv13 : f13 = f
let fv14 : f14 = f
let fv15 : f15 = f
Don't you think something is wrong with this?
Let's discuss ?
Personally I probably prefer to replace "()" with Void as a result of
function, and probably replace Void with "()" as parameters part. And don't
allow empty-tuple-in-tuple at least for function type declaration + don't
allow Void-in-tuple. I.e. in this case we'll have only this as alowed
declaration:
typealias ftype = () -> Void
IMO the only clear, explicit, often used variant.
On 19.04.2016 10:46, Radosław Pietruszewski via swift-evolution wrote:
Noooooo :(
I understand and appreciate the rationale, uniformity between declaration and
use site being a good thing, but IMHO the proposal just brings unnecessary
noise, far outweighing the small benefit of having the symmetry.
1. What I’m worried the most is the “parentheses blindness”. In higher-order functions, or just when I
take a simple callback closure, there are just a lot of parentheses (add to that generics, and there’s
a lot of angled brackets too). And it just becomes hard to instantly decipher. To me, `func blah(f: Int
-> Float) -> String` is easier to read that `func blah(f: (Int) -> Float) -> String`. Or
just notice how noisy `(f: () -> ())` is. This is why I like the convention of using `Void` for
void-returning functions. There’s less noise in `(f: () -> Void)`, and even better in `(f: Int ->
Void)`. I don’t have to mentally match parentheses, because whenever possible, there’s just one set of
parens around the main function declaration. When punctuation like parentheses is used sparingly, it
carries a lot of weight. Requiring parentheses around T in T -> U doesn’t seem to have a significant
reason aside from style/taste.
2. I’m not convinced at all that `(Foo) -> Bar` is immediately more obvious to
people. I don’t have data to back it up, but my intuition is that `Foo -> Bar` is
simple and understandable. “A function from Foo to Bar”, I’m thinking. I don’t have to
mentally parse the vacuous parentheses, just to conclude that there’s, in fact, just one
parameter. And when there is more than one parameter, the parentheses in `(Foo, Bar)
-> Baz` instantly carry more weight.
3. Swift has been really good at removing unnecessary punctuation. Parentheses in
if statements, semicolons, shortcut forms of closures, etc. This is a good thing.
As I said before, using punctuation only when it matters makes it stand out, and
in places where it doesn’t, by removing it we’re increasing the signal-to-noise
ratio. To me, parentheses in `(Foo) -> Bar` don’t matter. I can see why one
could argue for them, or prefer them, but it seems like a merely stylistic choice.
Let’s keep them where it matters, and leave this to personal preference.
Best,
— Radek
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
