The @infix Annotation

Another example:

for {
  i <- 0 until x
  j <- 0 until y
} yield (i, j)

reads a bit nicer

for {
  i <- 0.until(x)
  j <- 0.until(y)
} yield (i, j)
1 Like

This isn’t quite a binary debate. There are enough variations of opinion flying around that it seems worth polling for what kind of solutions people find acceptable:

  • Disable altogether
  • Disable; libraries make exceptions via annotation
  • Disable; teams make exceptions via feature flag
  • Keep; integrate linting into scalac
  • Keep; encourage teams to use style checkers

0 voters

I just wanted to point to the issue on dotty. It already has plenty of discussion worth checking out, including unimplemented ideas and guiding motivation that didn’t make it to the dotty docs linked above.

In fact @sjrd had a really good write-up in the github issue. I’d be interested in reading his response to the feedback in this thread.

1 Like

I just want to highlight something that I think is a big mistake made in all these discussions – which mainly involve people who are already pretty comfortable with Scala.

We hear things from beginners like, “There’s too many ways to do the same thing in Scala!”. And some folks take that to mean that beginners suffer a “choice paralysis” as mentioned in the article that @stewSquared linked:

am I supposed to use += or append in my code that uses the collections? I don’t know. Choice paralysis.

I think this is flawed reasoning. Beginners don’t wrestle with whether to use += or append, and since both are equivalent they suddenly decide that “there are too many ways to do the same thing in Scala!” and ragequit. Programmers are used to (and fine with) the fact that there can be named methods that do the same thing as operator overloads (to use C++ terminology).

What they mean is that there are too many ways from a design perspective, not from a syntax and method-naming perspective. Should I make an immutable functional API? If I do, then OOP people won’t know what to do with it. Or, I could make an OOP-style mutable API, but then all the FP-people will judge me. That’s what the “too many ways” question really comes down to. And it won’t be solved by choosing arbitrary syntax features and unilaterally bludgeoning them. In fact, having “too many ways” to do things in this sense is kind of what defines Scala.

Scala 3.0 is not an opportunity to silence all haters. I’ve heard somewhere about what haters gon’ do, and it’s not going to change. There are always going to be a lot of people who have some kind of complex about FP, or the JVM, or whatever else there is, and of that minority there will always be a further minority who make themselves feel better by picking out edge-case abuses of syntax and pretending they are the entire language. It’s not going to get better. Beginners are seriously fine already – there are lots of them and they do OK. We’ve hired several of them who are now quite formidable with Scala. I’m sick of hearing the argument of “we have to take away this feature because beginners are dumb!!” I have yet to hear from a single beginner who can’t get implicits after reading the docs, or typeclasses or even monads with a little bit of guidance. Let alone freaking spaces instead of dots.

Beginners aren’t dumb and they don’t need the language to be crippled. Every single person on this forum was at one point a Scala beginner – and you’ve all figured it out, haven’t you? Ask yourself if a contains b makes your brain hurt before projecting that presumption upon an entire class of people that you probably haven’t even asked.

I apologize for my rudeness, but lately the large majority of threads here are threatening to remove some power from Scala for the benefit of these mythical beginners, and I’m really starting to worry that if all these proposals succeed then there won’t be anything left.


Well true, but its the choice that gives rise to the inconsistency. So I want one or the other. I don’t think infix is bad for simple cases, but I also don’t think it does make much of a difference. So then I rather go for non-infix. I don’t see how it is a code smell rather than a difference of opinion on style.

On the last point I don’t think we can do anything else than agree to disagree. I don’t like Go, and am not fond of Python either. But I do envy the fact that their communities prefer to use one style. I think it makes it much easier to get started on an unknown code base, get more consistent teaching material over a whole community, and makes confusion less likely.

That said, it is just syntax, I don’t care that much. I have said what I wanted to say and understand if people disagree. Now its up to the SIP comité to decide how to proceed.

In principle, yes. I often don’t mind infix, and match is a good example of where it is used nicely. Also it removes some burden from the developer and enforces more consistency than @infix.

That said, if you refactor a method from one argument to two, you not only need to change all call-sites to use that argument, you also need to the style. How would that work with two parameters where one has a default? Would you change style based on whether or not you override the second parameter?There are likely too many edge cases for this to work.

So all in all, yes I would be open for alternatives, even if it includes more infix notation. But I don’t think we have a good alternative yet.

I just want to weigh in here: whatever you do, please think of users of IDEs. If I try to find a method on an object, I type a „.“ and get hints. If a method is only allowed to be an infix method, that seems not to work anymore.

1 Like

I use them for the creation of vectors and integer coordinates.

val v44 = 4 vv 4
val v31 = -2.4 vv 54.6 vv 34.7
val v32 = 4 vv -5 vv 0
val c1 = 5 cc -96

v44 ==> Vec2(4, 4)
v31 ==> Vec3(-2.4, 54.6, 34.7)
v32 ==> Vec3(4, -5, 0)
c1 ==> Cood(5, -96)

Using a short alpha name seemed better than making up some arbitrary symbolic operator, on types that will already have many symbolic operator methods in scope. I’m fairly easy going about whether we need an infix operator, but I would strongly object to their removal.

1 Like