I don’t feel that extensions are sufficiently unified with conversions, which can do exactly the same thing according to the docs. Either conversions shouldn’t allow you to call methods (i.e. a method call would not be a request to convert the type), or the unification should be clearer. In particular, all the extensions should be instances of Conversion.
I don’t like that def (foo: Foo)bippy is the same as def bippy(foo: Foo) but def bippy(foo: Foo) doesn’t create an extension method. If it’s the same, it should be bijectively the same. If not, make it different.
I also don’t like that the syntax is looking so much like C function pointers.
Also, the AnyRef thing on givens feels like a hack.
If it is important to be able to specify whether a leading parameter can be supplied on the left before a dot, I would instead use this to denote that:
def circumference(this c: Circle) = 2*math.Pi*c.radius
circumference(myCircle) // Fine because it's just a def
myCircle.circumference // Fine because you said this was cool too
Alternatively, just allow any leading parameter to be called, in any context!
import scala.math._
0.75.tan // Same as tan(0.75)
If you need to get a bunch of them in scope at once, stick the methods in an object and import the contents. If you don’t want to repeatedly name the parameter, just use a conversion. It already does the job. Yes, it’s got a bit more boilerplate. If that’s too much, I’d suggest that the problem is with givens and conversions, not with collective extensions.
(Alternatively, as I said, don’t let conversions happen automatically on method calls. If you want extension methods, use extension methods, not conversions.)