You have missed forest for the trees. Syntax sugar goal is not to make something more verbose and cryptic, but to make something easier to read and write. Macro which would implement auto-dereferincing in your fashion would be pretty useless since simple * would be replaced by much larger mostrosity.
a macro that wraps everything in an additional set of parentheses is trivial:
It's trivial and also completely useless. You are turning something ugly into something awfully ugly. Something like this:
emitter.imul((cx, dx, 5))
is much shorter and easier to read than
call!(imul_trait::imul, emitter, cx);
call!(imul_trait::imul, emitter, cx, dx);
call!(imul_trait::imul, emitter, cx, dx, 5);
First one looks close enough to syntax which 8086 used for last 40 years, 2nd one looks like something very cryptic, hard to understand and, most importantly, not similar to any kind of assembler at all.
And larger macro which wraps not just one call but large portion of Rust source would need to know if a given function actually accepts tuple or few separate arguments.
Not possible with current rust compiler AFAIK (which, is perhaps, a good thing, as you note below).
For this reason, "macro support" or "macro runtime" crates are a well-known design pattern in the Rust ecosystem.
This works when you want to simplify something big. Macro call needs at least 4 characters (name of macro, exclamation mark and some braces) which makes no sense when offending form already have only 2 “extra” characters: one additional-brace in the beginning and one in the end.
It would have been possible to use something like
foo.bar⦅1, 2, 3⦆ and do a simple search-end-replace in macro, but, unfortunately, Rust doesn't support characters like
⦆ (not even as argument of macro) thus such idea doesn't work either.
You probably can get away with passing a string and then turning it into a Rust source, but then you are, essentially, creating your own language in you macro and would need to add infrastructure to the rust-analayzer and other tools.
Not easier than changing the compiler, I'm afraid.
By the way, syntax and parsing should not depend on the type system, because that's disproportionately harder to parse for the compiler as well as humans. The need for global analysis is also highly undesirable for the exact same reasons, while, in addition, slowing down compilation times significantly by preventing incremental compilation. So those requirements are then two other arguments against having a feature like this.
I understand perfectly why macros are as limited as they are (hey, they are still more powerful than C/C++ macros!). I just point out that because of that limitation it becomes very hard to implement syntax sugar like autoderef or automatic tuples⇔multiple argument conversion as macro.