When can you omit curly braces

You can omit for some stuff “curly braces” and use indentation.
But mixing “curly braces” and indentation makes ugly code.
For which stuff can you use indentation and for which stuff not ?

Note that that’s subjective – some of us actively prefer a balance of the two.

But assuming you’re talking about Scala 3, curlies are rarely necessary at this point. (This was one of the main language changes from Scala 2 to 3.)

1 Like

See where it says “there are two rules” and then lists a dozen rules.

You know you’re a real Scala 3 coder when you stop asking “can I omit braces here” and start asking “do I need a colon?”

2 Likes

While this is one of my favourite Scala 3 features, it often trips me up, so I hope they find a way to improve this feature.

1 Like

I think you still need them for function definitions:
def add(x:Int,y:Int):Int={ x+y }
And mostly we use functions.
Not needed with F#

No, that’s simply not true: here’s that same method showing not.

Out of curiosity, where are you finding something saying it’s mandatory? I’m concerned that you’re relying on bad information.

2 Likes

That was not true even in Scala 2 IIRC.

2 Likes

I like so see the return type of functions.
Mostly you can remove “curly braces” and use indentation. But sometimes you need an “=” and sometimes you need an “:”

I think it’s a typical case of “learning by Google” or something like that.
There are so many awful, old resources on Scala out there, still telling people to use scalac manually or run .class files manually and stuff…
For some reason, a lot of people (I’m not saying Alain) actively refuse to go to a language’s official page. In fact some people get angry and blame the language for being bad, if it’s not “learnable by just a few Google / Stackoverflow searches” or “learnable straight from API docs”. Is this “the Python effect” or something?
(Imagine learning a human language by just asking a few people around, or from a dictionary :laughing: )
Just to repeat myself from another thread, here are the official resources. To learn the ins and outs properly: Programming in Scala, to learn idiomatic FP+OOP: online courses

3 Likes

Well you can just add that as well:

def add(x: Int, y: Int): Int = x + y

BTW, note that is not FUNCTION, that is a METHOD.
A function would be:

val add: (Int, Int) => Int = (x, y) => x + y
// Or
val add = (x: Int, y: Int) => x + y

All these are things that are taught by any good tutorial.

2 Likes

whar"s the difference in the usage?

Functions are first-class objects that can be passed around and used like any other. Methods are a characteristic of an object (of a class, really), not something independent.

(In Scala 2, there were also a bunch of things you could only do in a method, not in a function. Scala 3 has enhanced things to reduce those differences.)

The difference is subtle, and the system increasingly converts between them automatically, so it’s easy to think of them as largely the same. But under the hood, they’re very different.

1 Like

https://docs.scala-lang.org/tutorials/FAQ/index.html#whats-the-difference-between-methods-and-functions

While as @jducoeur you can think of them interchangeable most of the time.
However, IMHO, understanding the difference is very important since is one of the most primitive things of the language, knowing what are values / objects and what are not.

1 Like

This could be a basic question. When should u use one and when the other.
To me they are both the same.

Very roughly speaking:

  • If it is contained within a class and needs to operate on the members of the class, use a method.
  • If you intend to pass it around to higher-order functions, favor using a function, all other things being equal.
  • Otherwise, it’s a matter of taste; folks tend to default to methods, but there’s often no solid reason to care one way or another.

In practice, the most common use of functions is anonymous lambdas, which are pretty much ubiquitous in idiomatic Scala code.

1 Like

They are mostly the same, and the internal representation is an implementation detail. The difference becomes relevant when they aren’t equivalent in expressive power.

For example, in Scala 2 you can’t express this method as a function:

def id[A](a: A) = a

This has mostly changed in Scala 3, although the feature still has some annoying limitations:

val id = [A] => (a: A) => a

Note that this has some implications. For example, for something like this:

def foo[A, B](a: A)(b: B): Either[A, B]

Scala 3 should be able to express that like this, and they aren’t equivalent because you shouldn’t have to initialize B when calling foo:

def foo[A](a: A): [B] => B => Either[A, B]

Also, Scala 2 was not able to express implicit params in function types, e.g.

def execute(implicit ec: ExecutionContext): Something = ???

But this now works in Scala 3:

val execute: ExecutionContext ?=> Something = ???

In other words, the type system was not able to fully express via function types what it could express in method signatures. Once these differences fade, so will the distinction between them.

TBH, I never cared for functions vs. methods, and you shouldn’t care much either. I only noticed that declaring functions via a val comes with some annoying limitations, after being spoiled by TypeScript. Thankfully, Scala 3 has been closing that gap.

2 Likes