Make vec!() macro create a vector with precise capacity

[bkoropoff]

This seemed like a small but obvious optimization. Feedback questions:

• Is the count_args!() macro a good fit for libstd? It seems like it might be generally useful for macro writers.
• I can add a few unit tests, but where should I put them?

[lilyball]

I'll review the code later, but just going by the description, we haven't done this precisely because of the issue of introducing a new macro that isn't necessarily a good design. There's an RFC I filed (can't look up the number now) that modifies the macro system to, among other things, provide counting. I encourage you to find and read through it.

[lilyball]

This pattern looks weird, shouldn't it be ($e:expr, $(e_rest:expr),*)?

[huonw]

That doesn't work with one argument i.e. count_args!(foo).

[lilyball]

Ah. You can always add a one-argument case though. But I suppose if this pattern works, then it doesn't matter.

[lilyball]

Yeah, this is basically what I thought. It's a macro that only works for expr arguments, and produces a 1+1+1+1+... expression. And it requires being publicly exported.

The RFC I mentioned is rust-lang/rfcs#88, which introduces new syntax for counting repetitions directly into the macro parser. That avoids the need for a new macro (which is only useful to other macros), supports all nonterminal kinds, and produces a single literal instead of an expression.

[bkoropoff]

It's possible to avoid a separate macro by being a little creative:

/// Create a `std::vec::Vec` containing the arguments.
#[macro_export]
macro_rules! vec(
    ($($e:expr),*) => ({
        // leading _ to allow empty construction without a warning.
        let mut _temp = ::std::vec::Vec::with_capacity(vec!(c: $($e),*));
        $(_temp.push($e);)*
        _temp
    });
    ($($e:expr),+,) => (vec!($($e),+));
    // These syntactic forms are for internal use only
    (c: $e:expr $(,$e_rest:expr)*) => (1 + vec!(c: $($e_rest),*));
    (c: ) => (0);
    (c: $($e:expr),*,) => (vec!(c: $($e),*))
)

Of course, this requires consumers to abstain from using the internal syntactic forms themselves. I'm guessing this optimization is not pressing enough to justify a hacky interim solution pending the adoption of an RFC like the one you mentioned, so I'll close the PR.

[lilyball]

@bkoropoff Yeah that internal format is also something that's been suggested before. My personal belief is that it's not pressing enough to warrant doing things like that.

Hopefully the RFC will be accepted. If not, then we can consider workarounds.