Warts of Scala
&gt; ... methods should be called with as many sets of parentheses as they are defined with (excluding implicits), and any method call missing parens should be eta-expanded into the appropriate function value.<p>&gt; Notably, removing the &quot;optional parens&quot; thing would not stop you from defining &quot;property&quot; functions that are called without parens; it would just mean you need to define such functions without parens, as is already possible.<p>&gt; In other languages with first-class functions, like Python, this &#x27;works fine&#x27; [quotes mine]<p>I&#x27;m not sure how this behaviour could be seen as &#x27;more consistent&#x27;. If methods that <i>have</i> parens but are called with them stripped are eta-expanded but you can still define no-paren methods, you&#x27;d still have confusing behaviour where a no-paren method isn&#x27;t eta-expanded as expected (because it&#x27;s a property and so &#x27;special&#x27;).<p>Rather than more consistent, this behaviour is just &#x27;more like Python&#x27;[0], which has this inconsistency too[1]. Essentially the suggestion in the article would mean:<p><pre><code>    @ def x() = 1
    @ val y = x
    resXX: () =&gt; Int = $...

    @ def a = 1
    @ val b = a
    resYY: Int = 1
</code></pre>
It&#x27;s also worth noting that IntelliJ IDEA (and possibly Eclipse) warn you if you define a no-argument method with Unit return type (since `def action()`s should have parens and `def pure` values needn&#x27;t).<p>IDEA will warn you (and offer to correct) if you call a method with too few parens (`def x()` called as `x` will display a very visible warning), so maybe there&#x27;s some room to believe that this is a &#x27;problem&#x27;, but the solution involving automatic eta-expansion doesn&#x27;t seem like a particularly sane one.<p>Also, calling `getFoo` without parameters is &#x27;nice to have&#x27;, but calling `name()` as `name` and `color()` as `color` on imported Java APIs both comes across as more natural in Scala (since Java has no properties, they can&#x27;t be defined as properties upstream) and has allowed quite a few Java APIs to fit in naturally in Scala where they wouldn&#x27;t have otherwise, in my experience.<p>[0]: All the eta-expansion things in this post are to &#x27;be more like Python&#x27;, which makes sense given Haoyi is also behind <a href="https:&#x2F;&#x2F;github.com&#x2F;lampepfl&#x2F;dotty&#x2F;issues&#x2F;2491" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lampepfl&#x2F;dotty&#x2F;issues&#x2F;2491</a> and <a href="https:&#x2F;&#x2F;github.com&#x2F;lihaoyi&#x2F;Scalite" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lihaoyi&#x2F;Scalite</a> and (say) <a href="https:&#x2F;&#x2F;github.com&#x2F;lihaoyi&#x2F;macropy" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lihaoyi&#x2F;macropy</a>.<p>[1]: Properties in Python also have the underlying design of using descriptors, which are a whole other world of horror.