A modern programming language that makes developers happier.

kotlinlang

&gt; When overriding your operator overloads, you can omit `operator`:
(<https://github.com/JetBrains/kotlin-web-site/blob/f3096d05fdfbc29ec4a704f42112028cdc7f48b7/docs/topics/operator-overloading.md#L15-L21>)

Why? Isn't it a bit implicit to override an operator, but not mark it as being an operator? I mean: if you'd override an operator without the keyword, you'd have to check the super declaration whether or not it actually is an operator. In turn, that can be an override without the keyword, all the way to the topmost declaration. I guess this is a non-issue because you wouldn't do this often. Without the explicit keyword it might be difficult to discover that a function is actually an `operator`, so that you could use the operator syntax instead of a regular function invocation (e.g. `obj.invoke()` vs `obj()`).

can't you just immediately jump to the interface declaration of an override

Maybe, but that's not the issue. You'd still have to do it at least once, which is one too many :wink:

In any case there's really only two behaviors you can have here:
1. Make it an operator implicitly without the keyword.
2. Error if you override an operator, but don't have the operator keyword. This feels pretty awkward and unnecessary IMHO.

the third option, to have `operator` work the way it works everywhere else, isn't really acceptable

Current behavior is 1. I guess you want behavior 2?

Or were you thinking about the third option

2 doesn't seem too bad. It's also required for `override`, which is an improvement w.r.t. e.g. Java in which :java: `@Override` is optional :man-facepalming:

i don't think it's terrible but it's not especially amazing either. it's kind of just needless verbosity

if you buy the "once is too many" argument then you'll be disappointed at how often type annotations are optional too :slightly_smiling_face:

There's a difference between type inference and keyword inference

So the comparison might be better with the `public` keyword being the default, and therefore optional

Wasn't there a strict mode or something that can be configured, so that `public` and `Unit` return types become non-optional? Does that also require the `operator` keyword on overrides?

FWIW I agree with you, Erik, but I think there might be some 'magic' happening to allow Java methods to provide 'operator' functions? For instance, Gson's `JsonObject` has a `get(key: String)` method, which you can directly use from Kotlin in square brackets without needing to define an extension operator fun. I do think it'd be nice to be explicit in (some?) Kotlin contexts, though

I do believe there was a stricter compiler setting introduced, designed for libraries, that does require type annotations for public APIs.