3 ms·

I don't really buy the "what if the upstream author changes their signatures and downstream code behaves differently". Upstream signatures change all the time,

I don't really buy the "what if the upstream author changes their signatures and downstream code behaves differently". Upstream signatures change all the time, and downstream has to deal with it. That's not unique to the act of adding parentheses to a function. What if the upstream author makes their functions return `Option`s? Should we auto-unbox `Option`s with `.get` so downstream users won't need to change their code? Of course not, and if you submitted a PR with an implicit conversion that did that, you'd probably get yelled at. So why are we happy auto "unboxing" `() => T` functions using exactly the same logic?

tekacs 9y ago
I guess what you see as 'unboxing', I see as 'leaving intact'. In turn that is, I find your suggestion of automatically eta-expanding to be 'doing something' (auto boxing) and so 'why are we happy auto-boxing?' As you've said about callables in your sibling post, you see 'doing something' to be changing what is rightly a callable into something not-a-callable (immediately calling the function) and I see it the opposite way (why are we turning what is a value into a function?) This is why I say we're going from one inconsistent approach to another (from Scala-style inconsistency to Python-style inconsistency). The difference is Scala-style inconsistency makes it harder to introduce type errors since all it does is force you to add `_` when you want to eta-expand. The case that bothers me the most with your approach (again from a static safety perspective) is this: @ def foo = () => 1 // There exist less weird examples of this. @ val x = foo().toString resXX: String = "1" @ def foo() = () => 1 @ val x = foo().toString resYY: String = "$...identifier" // No compile error Now you could argue this is more a problem that functions and `Int`s have any methods in common at all (toString, equality, etc.). With some more time to think maybe I could come up with an example that doesn't rely on that (I've seen a lot more of this error in Python than in Scala, since Python is dynamically typed). But I find it odd here that the compiler changed the type in response to upstream paren count. Edit: since I can't reply below - thanks for the discussion - as you say, this is probably just different mental models. :)
- lihaoyi 9y ago
  > Now you could argue this is more a problem that functions and `Int`s have any methods in common at all (toString, equality, etc.) Now that's something that I should have put in the post! But it was already too long... Anyway, I think we already fully understand each other's views, and there's not much new to be said. Cheers and thanks for the discussion!

tekacs 9y ago

I guess what you see as 'unboxing', I see as 'leaving intact'. In turn that is, I find your suggestion of automatically eta-expanding to be 'doing something' (auto boxing) and so 'why are we happy auto-boxing?' As you've said about callables in your sibling post, you see 'doing something' to be changing what is rightly a callable into something not-a-callable (immediately calling the function) and I see it the opposite way (why are we turning what is a value into a function?) This is why I say we're going from one inconsistent approach to another (from Scala-style inconsistency to Python-style inconsistency). The difference is Scala-style inconsistency makes it harder to introduce type errors since all it does is force you to add `_` when you want to eta-expand. The case that bothers me the most with your approach (again from a static safety perspective) is this: @ def foo = () => 1 // There exist less weird examples of this. @ val x = foo().toString resXX: String = "1" @ def foo() = () => 1 @ val x = foo().toString resYY: String = "$...identifier" // No compile error Now you could argue this is more a problem that functions and `Int`s have any methods in common at all (toString, equality, etc.). With some more time to think maybe I could come up with an example that doesn't rely on that (I've seen a lot more of this error in Python than in Scala, since Python is dynamically typed). But I find it odd here that the compiler changed the type in response to upstream paren count. Edit: since I can't reply below - thanks for the discussion - as you say, this is probably just different mental models. :)

lihaoyi 9y ago
> Now you could argue this is more a problem that functions and `Int`s have any methods in common at all (toString, equality, etc.) Now that's something that I should have put in the post! But it was already too long... Anyway, I think we already fully understand each other's views, and there's not much new to be said. Cheers and thanks for the discussion!