That's actually a feature of Rust that I liked the moment I saw it. In particular, the forced '!' suffix makes macros stand out as something that might potentially introduce non-trivial control flow; for instance, the try! macro does an early-return of the containing function on failure. In C, putting control flow in a macro is generally considered poor form; in Rust, it becomes much more sensible precisely because of the macro naming convention.

I'm not sure I agree with this. Or at least, I'm not sure I think this will hold true once macros are used for more than control flow mechanisms, which are approximately half of the uses of the macros in the stdlib right now as far as I can see. After all, most C style guidelines do insist on some way of differentiating macros, commonly making them all-caps, but it makes it no less sketchy to throw a return into a macro.

> It makes macro invocation feel "wrong" or "special" in a subtle way and betrays a lack of confidence in the macro system

But a macro invocation is special. The syntax within a macro does not follow Rust rules, so if macros would not be marked properly it would be incredibly confusing for a user. Let alone that macro imports are different by the very nature of their behavior.

I think that the 'call-by-name' behaviour in Scala is confusing, because you can write something that you think will execute once but actually, it might execute multiple times and there's no obvious marker that it's special. When you have something that is potentially major, you generally don't want it to be invisible.

Not to mention it would be difficult, if not impossible, to parse in the first place (the contents of a macro invocation are stored as token trees within macro AST nodes, within the regular AST).

Macros have a freeform syntax, with the only restriction being that delimiters within have to be balanced. I don't see how an IDE could provide general syntax highlighting for them.

The IDE could parse the macro definition and highlight accordingly. (It would know where to expect an identifier and where to expect an expression etc.)

> (It would know where to expect an identifier and where to expect an expression etc.)

But that doesn't mean that what's in the macro should be highlighted like Rust:

    sql!("SELECT * FROM users WHERE name = $1");

is a macro provided by https://github.com/sfackler/rust-postgres-macros , and should be highlighted like SQL, not like a Rust string.

    sql!("SELECT * FORM users WHERE name = $1");

throws an error, because it's malformed.

I used to think so too, especially because very basic examples with `printf!()` look "odd", but I started to like it: it gives me confidence that regular function calls won't do anything bizarre.

It's a warning that there's "magic" going on. It makes it clear that there's a lot of quirky compile-time type checking trickery behind printf, it tells that regex is going to be precompiled, etc.

Macro invocation is special. It's significantly more readable to know whether you're calling a function or invoking a macro.

It was peculiar at first with me, but I think I like it now.

Felt nearly the same way with "recur" in "clojure", instead of calling the function name recursively and pray the compiler would do the proper tail call optimization (elimination), but recur forces you to always get it right.

It makes me thing it signals mutation.

Because that's the convention in lisp?

Technically, it's not the convention in Common Lisp, but rather Scheme and Dylan. But yes.

Both Lisp and Ruby all follow that convention. Probably other languages, too, but I'm too lazy to look... :)

In Ruby, it does _not_ mean mutation. It means 'danger.' Sometimes that's mutation, sometimes its other things, like throwing an exception rather than returning nil on error.

  > There is just a terrible mismatch between the use-case 
  > macros were originally intended for (embedding 
  > different languages) and how they are mainly used now 
  > (emulating varargs).

This is incorrect. I can't think of any macros that are used to paper over the lack varargs (`println!` certainly doesn't count, because even if Rust had varargs you'd still need a macro here to do typesafe compile-time string parsing).

In any case, varargs can already be trivially emulated using vectors (which afaict is essentially what Go does, but Go has sugar for it). Macros would be overkill for this use case.

  > This is incorrect.

Eh ... did you have a look at the "standard" library?

  > `println!` certainly doesn't count, because even if Rust
  > had varargs you'd still need a macro here to do typesafe 
  > compile-time string parsing

Yeah, but you could do it without exposing all the horrible mess to users.

The usual "OMG!!! Look at that random `!`. Stand back, I'm using a macro here and would like to warn you that semantics will be totally different!!!"-dance is just embarrassing, especially given the fact that you can design printf-like functionality without needing varargs in the first place.

With or without macros, if your API requires warning signs it just sucks, and you should fix it instead of using "hey, but I warned people!" as an excuse.

  > varargs can already be trivially emulated using vectors

Oh right! So how do we create a vector?

    vec![1, 2, 3, 4]

Oh well ...