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.
Patrick Smith On Apr 19 2016, at 11:28 pm, Vladimir.S via swift-evolution <[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]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
