Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <h2>Class definitions:</h2> <p><code>val</code> or <code>var</code> can be omitted from class parameters which will make the parameter private.</p> <p>Adding var or val will cause it to be public (that is, method accessors and mutators are generated).</p> <p><code>{}</code> can be omitted if the class has no body, that is,</p> <pre><code>class EmptyClass </code></pre> <hr> <h2>Class instantiation:</h2> <p>Generic parameters can be omitted if they can be inferred by the compiler. However note, if your types don't match, then the type parameter is always infered so that it matches. So without specifying the type, you may not get what you expect - that is, given</p> <pre><code>class D[T](val x:T, val y:T); </code></pre> <p>This will give you a type error <em>(Int found, expected String)</em></p> <pre><code>var zz = new D[String]("Hi1", 1) // type error </code></pre> <p>Whereas this works fine:</p> <pre><code>var z = new D("Hi1", 1) == D{def x: Any; def y: Any} </code></pre> <p>Because the type parameter, T, is inferred as the least common supertype of the two - Any.</p> <hr> <h2>Function definitions:</h2> <p><code>=</code> can be dropped if the function returns Unit (nothing).</p> <p><code>{}</code> for the function body can be dropped if the function is a single statement, but only if the statement returns a value (you need the <code>=</code> sign), that is,</p> <pre><code>def returnAString = "Hi!" </code></pre> <p>but this doesn't work:</p> <pre><code>def returnAString "Hi!" // Compile error - '=' expected but string literal found." </code></pre> <p>The return type of the function can be omitted if it can be inferred (a recursive method must have its return type specified).</p> <p><code>()</code> can be dropped if the function doesn't take any arguments, that is,</p> <pre><code>def endOfString { return "myDog".substring(2,1) } </code></pre> <p>which by convention is reserved for methods which have no side effects - more on that later.</p> <p><code>()</code> isn't actually dropped per se when defining a <em><a href="http://hestia.typepad.com/flatlander/2009/01/scala-for-c-programmers-part-3-pass-by-name.html" rel="noreferrer">pass by name</a></em> paramenter, but it is actually a quite semantically different notation, that is,</p> <pre><code>def myOp(passByNameString: =&gt; String) </code></pre> <p>Says myOp takes a pass-by-name parameter, which results in a String (that is, it can be a code block which returns a string) as opposed to function parameters,</p> <pre><code>def myOp(functionParam: () =&gt; String) </code></pre> <p>which says <code>myOp</code> takes a function which has zero parameters and returns a String.</p> <p>(Mind you, pass-by-name parameters get compiled into functions; it just makes the syntax nicer.)</p> <p><code>()</code> can be dropped in the function parameter definition if the function only takes one argument, for example:</p> <pre><code>def myOp2(passByNameString:(Int) =&gt; String) { .. } // - You can drop the () def myOp2(passByNameString:Int =&gt; String) { .. } </code></pre> <p>But if it takes more than one argument, you must include the ():</p> <pre><code>def myOp2(passByNameString:(Int, String) =&gt; String) { .. } </code></pre> <hr> <h2>Statements:</h2> <p><code>.</code> can be dropped to use operator notation, which can <em>only</em> be used for infix operators (operators of methods that take arguments). See <a href="https://stackoverflow.com/questions/1181533/what-are-the-precise-rules-for-when-you-can-omit-parenthesis-dots-braces-f/1182099#1182099">Daniel's answer</a> for more information.</p> <ul> <li><p><code>.</code> can also be dropped for postfix functions list tail</p></li> <li><p><code>()</code> can be dropped for postfix operators list.tail</p></li> <li><p><code>()</code> cannot be used with methods defined as:</p> <pre><code>def aMethod = "hi!" // Missing () on method definition aMethod // Works aMethod() // Compile error when calling method </code></pre></li> </ul> <p>Because this notation is reserved by convention for methods that have no side effects, like List#tail (that is, the invocation of a function with no side effects means that the function has no observable effect, except for its return value).</p> <ul> <li><p><code>()</code> can be dropped for operator notation when passing in a single argument</p></li> <li><p><code>()</code> may be required to use postfix operators which aren't at the end of a statement</p></li> <li><p><code>()</code> may be required to designate nested statements, ends of anonymous functions or for operators which take more than one parameter</p></li> </ul> <p>When calling a function which takes a function, you cannot omit the () from the inner function definition, for example:</p> <pre><code>def myOp3(paramFunc0:() =&gt; String) { println(paramFunc0) } myOp3(() =&gt; "myop3") // Works myOp3(=&gt; "myop3") // Doesn't work </code></pre> <p>When calling a function that takes a by-name parameter, you cannot specify the argument as a parameter-less anonymous function. For example, given:</p> <pre><code>def myOp2(passByNameString:Int =&gt; String) { println(passByNameString) } </code></pre> <p>You must call it as:</p> <pre><code>myOp("myop3") </code></pre> <p>or</p> <pre><code>myOp({ val source = sourceProvider.source val p = myObject.findNameFromSource(source) p }) </code></pre> <p>but not:</p> <pre><code>myOp(() =&gt; "myop3") // Doesn't work </code></pre> <p>IMO, overuse of dropping return types can be harmful for code to be re-used. Just look at specification for a good example of reduced readability due to lack of explicit information in the code. The number of levels of indirection to actually figure out what the type of a variable is can be nuts. Hopefully better tools can avert this problem and keep our code concise.</p> <p><sub>(OK, in the quest to compile a more complete, concise answer (if I've missed anything, or gotten something wrong/inaccurate please comment), I have added to the beginning of the answer. Please note this isn't a language specification, so I'm not trying to make it exactly academically correct - just more like a reference card.)</sub></p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload