On 19.04.2016 17:11, Patrick Smith via swift-evolution wrote:
I think () reads nicer than Void, and has a sort of beauty that () literally looks like nothing, unlike some word. The fact that you can nest it is trippy in a kind of cool way.
In this case, why do we need Void at all in function type definition, and wider - in language ? And why do we need these ((())) as allowed parameters definition for functions?
Probably it is OK for me to have only () without Void, i.e.: f: ()->() But not all of these strange constructions like (((Void))) Opinions?
*Patrick Smith* * * On Apr 19 2016, at 11:28 pm, Vladimir.S via swift-evolution <[email protected] <mailto:[email protected]>> wrote: 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] <mailto:[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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] <mailto:[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
