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)
2 Likes
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
1 Like
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
+=orappendin my code that uses the collections? I donât know. Choice paralysis.
â @sjrd
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.
7 Likes
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