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' (

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. :)