4 ms·
Hm, so I wrote Python for a decade before Scala (and I still write TypeScript & JS) and I'm deeply sympathetic to the 'passing around a callable' way of looking
by tekacs 9y ago
Hm, so I wrote Python for a decade before Scala (and I still write TypeScript & JS) and I'm deeply sympathetic to the 'passing around a callable' way of looking at things. That said, I find Scala's syntax more consistent.
I would regularly run into that 'wart' in Python, where changing something between a property and a method would completely change the downstream behaviour (property -> method makes downstream 'calls' eta-expand and method -> property makes downstream calls error, or call the eta-expanded function if the property happens to return a function, both of which are terrible IMO).
I guess more than caring either way about number-of-argument-lists, I just disagree (as does a sibling commenter) with automatic eta-expansion, because I think that 'people may forget to call `someFn _`' is unconvincing.
If you currently try to pass `someFn` bare, to something expecting a function, you get a very clear error (and in some cases you can actually do this and it's automatically handled, like in `.map(someFn)`).
On the other hand, I would find it deeply objectionable if the compiler started magically switching the type of an expression of mine based on the upstream's number of parens. If they change `def foo()` to `def foo` I don't expect the type of my `val x = foo` to change from `() => Int` to `Int` or vice versa.