>.. To me, it feel like extra syntax where the -> is already making it
very clear that we're dealing with a function...
Can't agree with you.
I don't think it's "very clear" where the function and where is result type
here:
Int -> String -> Void -> Float
in compare to this:
(Int) -> (String) -> (Void) -> Float
Int/String/Void - are parameters, not result type, as first result type is
(String) -> (Void) -> Float
then
(Void) -> Float
then
Float
Also, as described in proposal, if we can omit parenthesis then we have a
question if
(Int, Int) -> Void
is a tuple->Void or func with 2 arguments? as we also can have
((Int,Int)) -> Void which is tuple -> Void
Please look at this code :
func foo(_ : (x: Int, y: Int)) -> Int {
return 1
}
typealias FooType1 = (Int,Int) -> Int // so, what does this mean?? tuple
to Int or 2 params to Int ?
typealias FooType2 = (((Int,Int))) -> Int
let bar : FooType1 = foo // ? will bar accept just tuple or just two params?
let bar2 : FooType2 = foo // ? the same question
let z = (1,2)
foo(z)
//foo(1,2) // ERROR : extra argument in call
bar(z) // no problems
bar(1, 2) // no problems
bar2(z)
// but
//bar2(1,2) // ERROR: extra argument in call
Were you confused by the FooType1 declaration?
On 24.04.2016 9:18, Chris Eidhof via swift-evolution wrote:
(Sorry to be hijacking a different subthread, but I only just subscribed
again to the mailing list)
I understand why the proposal has its benefits. Yet, if we look at the
SE-0009 rationale, we could apply much of that as an argument against this
proposal, e.g. "anything that is widely repeated becomes invisible.". To
me, it feel like extra syntax where the -> is already making it very clear
that we're dealing with a function. I can understand why people would want
to enforce parenthesised types in their code bases, but to me, it feels
like clutter. I don't have any other strong rationales, adding the
parentheses feels superfluous to me, but I'm sure that I can live with it, too.
--
Chris Eidhof
_______________________________________________
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
