Which stdlib functions and types should be marked as `infix`?

Scala Standard Library
1

Scala 3.4 introduces warnings on alphanumeric method application in infix positioning if such methods are not explicitly marked with infix.

I think equals should be marked as infix, as it is naturally used in infix positioning.
Do you agree? What other stdlib functions/types do you think should be marked as infix?

Related issue:

3 Likes
2

I agree for equals, I’d also nominate zip and lazyZip, which I almost always use infix.

I also like to use union as infix.

In general operations that are symmetrical or associative, as there is no benefit to clarifying what are the operands.

Things like map, foreach, etc, I’d be against putting as infix

5 Likes
3

I think all kinds of things are naturally used in infix position. drop, append (on java.lang.StringBuilder), orElse on Option, to and until to create ranges, contains on sets and maps, etc. etc. etc…

I really don’t think the change is very well-conceived. Adding one bit of extra information to remember for every alphanumeric method is a bad way to solve the possible problem of people abusing the feature of infix method names. This is the kind of thing linters should cover, not the compiler. This is particularly true given that no general statement can be made about Java libraries. For instance "salmon" charAt 3 seems pretty bad to me, because charAt acts like apply and thus should look like it: "salmon".charAt(3). On the other hand, date plus duration reads far better than date.plus(duration).

For everything I control, I expect I will just sed 's/\(infix\)\{0,1\} def\b/infix def/' so I don’t have to worry about it, assuming I can’t just turn the warning off.

4 Likes
4

Agreed, particularly since (at least for me) the decision to use infix or not depends a lot on what’s going on where it’s called, rather than the details of the method itself.

I find this to be nice and readable:

list.reduce(_ foo _).bar // compared to list.reduce(_.foo(_)).bar

I find this significantly less so:

(a foo b).bar // compared to a.foo(b).bar

Counterpoint: I almost never use those methods infix :slight_smile:

I would be very hesitant to make any claims about what methods are more likely to be used infix, because wherever the cutoff ends up, it’s going to piss somebody off. To be honest, I kind of think having to explicitly annotate infix-capable method definitions solves a problem that isn’t actually a problem in practice.

5 Likes