> On Apr 15, 2016, at 1:07 PM, Chris Lattner <[email protected]> wrote:
>
>
>> On Apr 15, 2016, at 11:27 AM, David Owens II <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hmm... I don't think this is clearer:
>>
>> let fn: (Int) -> (Int) -> Int
>>
>> I think it's much less readable and really, the () are syntactically
>> redundant: the -> is really what distinguishes this as a function.
>>
>> Also, this would look like a error now:
>>
>> let fn: (Int) -> ()
>>
>> Did the user mean that it returns nothing, or did they forget the rest of
>> the function signature?
>
> Hi David,
>
> I’m not sure what you’re saying here. The two types above are already valid,
> and this proposal doesn’t affect that.
>
> -Chris
At the core, I guess it’s just a dislike of the different behaviors for
function declarations in the system in general. Your propose just exposes a
weirdness with empty parameter lists and the typealias for void: ().
It’s a bit odd that the () mean different things depending on the side of the
“->” they are on. The left side is an empty parameter list, the right side is a
void type.
Now, I get your argument is to get rid of the difference between:
let f: Int -> ()
let g: (Int, Int) -> ()
I guess I’m more of the opinion of David Hart, this change should also remove
the typealias for () being void.
let f: (Int) -> Void
let g: (Int, Int) -> Void
Overall, I think the change is ok, but doesn’t really add any significant
clarity to function declarations. I feel like there are already a lot of
weirdness in general around them.
See:
typealias Functor = (to: Int, from: Int) -> Int
let g: (hi: Int, bye: Int) -> Int = { $0 - $1 }
func sum(x: Int, y: Int) -> Int {
return x + y
}
func mult(x: Int, y: Int) -> Int {
return x * y
}
func f(n: Int, _ m: Int, _ c: Functor) -> Int {
return c(to: n, from: m)
}
f(1, 2, sum) // output: 3
f(1, 2, mult) // output: 2
f(1, 2, g) // output: -1
It’s weird to me that we can essentially erase the parameter names and fallback
to just the type signatures, but that can be a talk for another day.
-David
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
