Would it be possible to get a link or two to explain why unary operators are bad? I can’t really find anything, and I can’t think of anything myself - I find them too convenient, I guess?
It adds another language features for literally three operations (!, -, ~) that could easily have been simple method calls. It’s pointless language complexity that could be better spent elsewhere.
Especially because languages still cannot decide on what’s the precedence:
Do -1.abs and let x = -1; x.abs return the same thing? It depends!
So replace !x and ~x with e. g. x.not, and -x with e. g. x.negate and be done with it, and never have to worry about it again.
Boolean.not was introduced precisely because Inko doesn’t have unary operators. I could’ve sworn I’ve seen isFalse/false?/etc being used in some other languages, but I might have made that thought up :)
This is a really cool idea!
It would look probably a bit different in the language I’m contributing to (
foo.not
→foo.isFalse
), but it’s a thought-provoking design!Nevertheless, all work toward removing unary operators is good work.
Would it be possible to get a link or two to explain why unary operators are bad? I can’t really find anything, and I can’t think of anything myself - I find them too convenient, I guess?
It adds another language features for literally three operations (
!
,-
,~
) that could easily have been simple method calls. It’s pointless language complexity that could be better spent elsewhere.Especially because languages still cannot decide on what’s the precedence:
Do
-1.abs
andlet x = -1; x.abs
return the same thing? It depends!So replace
!x
and~x
with e. g.x.not
, and-x
with e. g.x.negate
and be done with it, and never have to worry about it again.~x
would probably be better described by, e.g.,x.complement
—since~
is the bitwise complement operator.Boolean.not
was introduced precisely because Inko doesn’t have unary operators. I could’ve sworn I’ve seen isFalse/false?/etc being used in some other languages, but I might have made that thought up :)