What unary operator could be added? So far I can see only $ free. The problem is that Elixir core does use most of ASCII characters and there is no much place here.
That would not happen. Firstly I did not saw anyone else needing this and because of it Elixir core team would most probably not accept it. Also at least for me it looks like you are trying to overcomplicate the problem and you should search for an easier solution to do same/similar thing.
The specifics matter here a lot though honestly. Your example is about operator overloading which really ought to be done very sparingly as it is not zero cost. Do you have other concrete examples where this is an issue? Are these your libraries or external ones?
$, ~ and all special forms being overridable operators (can’t tell if it is easily or anyhow doable though). Also, being able to define different arity for non-unary operators to become ones. PS. I am aware that ~ is used for sigils, but nevertheless.
It’s their right to decide whatever they want. I expressed my opinion and I think it’s valid.
Besides, do note that I am using macros and not functions there. It’s the only way to take precedence to re-interpret the otherwise special forms.
I agree that it comes at an additional cost unless there’s a way to quote the fallback to the original operator (which was my intention, btw).
In my example above the “OtherLibrary” is an external one that I don’t have an influence over. It’s a hypothetical library. My intention was (as the title suggests) to make my library (that overrides a unary operator) resilient and flexible to situations where the user is also using another such library that I do not know of. That’s all to it.
I’m less-opposed to custom operators than most, but IMO if you’ve got different overrides for the same operator overriding each other you may want to consider a different design.
Setting the specifics of operators aside, it sounds like what you want is something where you can import heads for one function from multiple modules:
# HYPOTHETiCAL: THIS CODE DOES NOT WORK - SEE NOTES BELOW
defmodule ImplOne do
def some_fun(x) when is_list(x), do: IO.puts("list!")
end
defmodule ImplTwo do
def some_fun(x) when is_map(x), do: IO.puts("map!")
end
defmodule Demo do
import ImplOne
import ImplTwo
def do_stuff do
some_fun([1,2,3])
some_fun(%{a: 1})
end
end
This currently complains:
** (CompileError) iex:11: function some_fun/1 imported from both ImplTwo and ImplOne, call is ambiguous
(elixir 1.14.0) src/elixir_dispatch.erl:149: :elixir_dispatch.expand_import/7
(elixir 1.14.0) src/elixir_dispatch.erl:119: :elixir_dispatch.dispatch_import/6
(elixir 1.14.0) src/elixir_expand.erl:567: :elixir_expand.expand_block/5
(elixir 1.14.0) src/elixir_expand.erl:40: :elixir_expand.expand/3
(elixir 1.14.0) src/elixir_clauses.erl:37: :elixir_clauses.def/3
(elixir 1.14.0) src/elixir_def.erl:197: :elixir_def."-store_definition/10-lc$^0/1-0-"/3
iex:6: (file)
TBH this style of importing reminds me of the worst parts of OO, where you end up playing “your method is in another castle” through twelve classes all named Base.
If you’re doing something like this codebase-wide, I’d recommend combining all the relevant plumbing into one module that gets used consistently. That module may not be pretty, but it will be centralized - the thing you want to avoid is having your codebase littered with slightly-different sets of operators etc in different modules.
I agree with you completely, but that’s not the point here. I explained my concerns here:
The question was what unary operator could be added - overriding is not adding. 
That’s important to say as you only repeat after me one character $, so in fact you confirm there is not much to add here and definitely not many things.
You need to understand that any overrides and multiple meaning of same operators is more confusing than helping especially when we are talking about % as every new developer would think about maps in first place. Also SpecialForms naming is not random. If you really want to write for example your own for special form then you would need to go outside Elixir.
But then those would no longer be operators. 
When starting with programming and Elixir I have also expressed many things and found myself that many of them does not makes sense at all only because I did not understand something.
Let’s go back to your question … If you really want to go this way then consider splitting your macros.
defmodule Example do
use First
use Second
import First, only: [-: 1]
# or
# import Second, only: [-: 1]
end
This is simplest way without going around. The developer could decide which function/macro should be imported. Also it’s highly recommended to prefer import in favor of use when everything you do is to import functions/macros.
I meant functionally ‘added’ not added in literal sense.
Personally, I had no intention of overriding for. The special forms that I was referring to are: ^, &, ., :, =.
Don’t agree with that. For instance ** can just as well be interpreted as a unary operator meaning same as x ** 2, to name one. Not to mention (Godforbid) the ++ and -- as used in C/C++. Not operators?
Me too. First in 1988 with C, then in 1998 with Java, then .., and then in 2019 with Elixir. Must say though that for Javascript at least, I still find many of my old remarks valid 
Yes, this is a valid approach, but I don’t like it (the “batteries not included” style). But that’s just me. Turns out I’ll be most likely writing that “cumbersome” (yet compile-time so it doesn’t count as much) piece of code that collects all not previously imported functions and macros only to exclude them along with the one for my operator.
I don’t get “functionally added”. They exists as a part of language. They are named “special” for purpose.
Special forms are the basic building blocks of Elixir, and therefore cannot be overridden by the developer.
It’s like you want to replace foundations of house and expect that nothing bad would happen. Special forms are not even macros like the ones you are writing. They are expanded by compiler and this is a completely different topic.
wait, wait
Non-unary operators like a = b have always 2 arity and you wrote about different arity. How do you see 3 or 4-arity operator?
The problem is that you would need to describe that weird behaviour to all developers using you library. The inspecting is only in examples. Most probably you would not log them and that would be extremely confusing.
The good practice is to write a code and be able to describe what it does even if you stop touching it for let’s say 6 months. In your case the developer would need to remind which macros are overriding operator and in which order. Now think that you decide to change behaviour of your library and this time you want to take operator from first macro. If so would happen nobody maybe except maintainers would follow the whole process.
Hiding everything is not always the best way and in some cases it may be seen as a bad practice.
Nope. Sounds like I am just challenging certain predetermined aspects of the current version of the language. So?
Where did I mentioned 3 or 4 arguments? I just wanted a little more freedom in overriding the operators. And if those special forms are implemented as they are now (in theory) it doesn’t mean they need to stay that way. It’s a software for God’s sake. Nothing is written in stone.
What do you mean by weird behavior? “If you’re using another library that overrides the operator X, just use this one after the import/use of the former and it will all work.” Is that a weird, hard to maintain behavior?
The only scenario in which my approach would not work is if the other library matched on the very same value patterns that my operator override matches and this would be documented. In your case, it would take turning one off to turn the other on even if there’s never such a case, only to accommodate the very fact that you’re overloading the same operator, while mine still leaves the same option to the user without mandating it to them for the 99.9999% of the cases => If my use just imports what it imports, then the user is also free to import it manually the way you suggest, but if I don’t make what I said I would, then it becomes the only option in spite of an ultra miniscule and still warned about chance of a conflict.
Yes, I agree with that. Part of the reason I went from OO to all-in functional.