Should we remove the unary
+ operator? It always returns
self, so other than “purity” reasons I don’t see a strong reason to have it. Additionally, doing
[1, 2, 3].reduce(&.+) would then give a compile error.
What do you think?
It’s a breaking change so we could initially deprecate it by giving a compiler warning.
I’m against removing the operator from the language. It should be available for custom purposes where it might have different semantics than just identity.
We can consider removing the
#+ method from numerical types in stdlib. But even that, I wouldn’t really recommend. Having it even as a no-op isn’t bad. Let’s avoid potentially breaking changes for no reasonable gain.
Do you have some examples in mind? If it means something other than “unary plus” then I think that would be pretty confusing.
Yeah the meaning of the operator is obviously unary plus. But what the result of that would be, depends on the implementation. It does not necessarily have to return
I don’t have any concrete examples, sorry. But I don’t want to remove it just because. The cost of removal is much higher than the cost for keeping it (which is essentially zero since there is no real negative effect).
People trip over reduce with plus all the time. Someone just asked that in gitter. Some weeks ago someone asked that in Github. I wouldn’t say the cost of keeping it is zero, really…
But that’s caused by the stdlib method, not the operator. I associated your question with the operator as a language feature and my answer is about that.
Okay. Let me frame it differently: it seems that the only purpose of that method is to be there so that when users do
reduce(&.+) they get confused
Is there another use case for this operator?
There’s certainly a case to be made for code clarity (see below). I also generally like having a bunch of options for overloadable operators. That said, I really can’t think of a single instance in which having an overloaded unary plus would make sense.
Example of use for clarity:
rotation_matrix = [
[ +Math.cos(theta), -Math.sin(theta) ],
[ +Math.sin(theta), +Math.cos(theta) ]
Thanks, that’s a very good use case!
I’m not a huge fan of it, since it can cause some hard to understand behavior. If people really want to balance with unary negative, In my mind they can just use 0+ ? :)