Idea: elide parens/brackets on unparametrized macros

Could we syntactically eliminate the ()/{}/[] after “calling” an unparameterized macro? In other words:

macro_rules! foo {
  () => { ... }
}

could be invoked with foo! rather than foo!(). The motivation is primarily to avoid a paper cut.

I can imagine a few use cases that would become more ergonomic:

let my_vec = vec!; // vec![]`
println!; // println!()
ok! // Maybe shorthand for Ok(()) -- just an idea ?

I don’t see any obvious syntactic ambiguities that arise, and the change is purely syntactic, so the only part of the compiler that changes is the parser, I think.

Any thoughts?

2 Likes

macros without parameters rarely have very interesting effect, do they? It is unavoidably a knee-jerk reaction here, but I don’t think vec! is better than vec![] — then it even loses those brackets it has borrowed from the array or slice, to remind you of them.

4 Likes

What I don’t like a lot is both versions being accepted:

fn main() {
    let v1: Vec<u8> = vec![];
    let v2: Vec<u8> = vec!();
}

Often in programming languages I prefer the Python Zen “There should be one-- and preferably only one --obvious way to do it.”.

1 Like

unreachable! seems like a good use case for this. Similarly, unimplemented!

3 Likes

This looks kinda tempting.

If macros with ()/etc are “functions” and take arguments, then macros without () are “constants”.
It would be nice to use them for macros that actually unwrap into constants, kinda like

/* "Constant" macro */
#define CONST 10
/* "Function" macro */
#define FN(a, b, c) ((a) + (b) + (c))

in C.

I don’t think there are syntactic ambiguities or any similar technical problems, but I still have mixed feelings about the syntax, not sure why.

1 Like

I feel better about this for panic! variants than for vec!, but this seems like a very fuzzy feeling for which I don’t have a good justification.

2 Likes

TBH, I had the same hesitation. On introspection, here what I think I am feeling: Macros are great if you have some little piece of code that works the same way but with a few values changed. I don't think that macros should be used if other language constructs could be instead. Using a macro to insert the same constant AST in multiple places feels in some way like a violation of that intuition.

I would argue that this isn't a problem with this particular syntax though. Rather it's a choice of whether to use a macro at all for something.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.