newb question: why is println! a macro?

I apologize but I did try googling for this, and nothing good really came up.

https://github.com/rust-lang/rust/issues/17190#issuecomment-55372530

Which in my reading says it’s due to certain capabilities not being in the language. I figured I’d ask this community the same question.

Edit: Found this which is a bit better at explaining. https://users.rust-lang.org/t/newbie-why-macros-vs-functions/1012

---

Comments

hi_im_nate • 32 points • 2016-06-30

It’s so that you can use format parameters:

println!(“x is: {}”, x);

Since rust does not support varargs, this has to be implemented with a macro.

steveklabnik1 • 33 points • 2016-07-01

On top of that, it checks said format parameters at compile time, as well as secretly taking &x rather than just x.

lucidguppy • 8 points • 2016-07-01

Is it because varargs are unsafe? Or is it just a TODO?

minno • 14 points • 2016-07-01

I don’t think there are any plans to make functions able to take a different number of values or different types (except through generics), like with overloading, optional parameters, or varargs.

C’s implementation of varargs is horrifically unsafe and unwieldy, and I don’t think you could do a whole lot better with Rust. You would have absolutely no compile-time checking, and the runtime checks would make it really tedious to use. You’d end up with a long block of

if let Some(s) = try_get_next_vararg_with_type::<&str>() { // stuff } else if let Some(x) = try_get_next_vararg_with_type::() { // stuff }

looneysquash • 9 points • 2016-07-01

Are you aware of how C++11 can do it with vararg templates?

See here, search for tprintf.

hi_im_nate • 6 points • 2016-07-01

It’s because varargs require hidden runtime overhead, and that’s not something that Rust really tries to minimize.

[deleted] • 5 points • 2016-07-01

Parsing a format string at runtime has overhead compared to doing so at compile time, but I wouldn’t call that hidden. The overhead of simply using a vararg function in C is basically negligible.

mutabah • 9 points • 2016-07-01

The core of println! is format_args! which is a compiler-implemented “macro” (also known as a syntax extension) that parses the format string and converts it into the format needed to print at runtime.

[deleted] • 9 points • 2016-07-01

println!() does a couple of things that a regular function can’t do:

1. It parses the format string at compile time, and generates type safe code

2. It has a variable number of arguments

3. It has named arguments (“keyword arguments”)

4. It takes parameters by reference implicitly

looneysquash • 3 points • 2016-07-01

That begs the question, will they ever be able to?

Personally, I would vote yes on 1-3, and no on 4.

For 1., I got the impression that constexpr stuff was planned, and not really controversial.

While 2. and 3. and 4. are more things that people will argue about.

Named arguments don’t add any runtime overhead and aren’t unsafe, and don’t make the code harder to grep.

C style varargs are unsafe. C++ has vararg templates that are safe and use recursive expansion at compile time.

Java does varargs by implicitly converting the last arguments to an array, which requires that they all be the same type. I don’t think that actually adds runtime overhead though, and is safe.

Maybe someone could come up with another way entirely. Maybe the arguments could be treated as a tuple and the compiler could type check each call separately, like it was using generics.

protestor • 3 points • 2016-07-02

About named arguments, a convention is to make a struct with the arguments and pass it as parameter. One can even have optional arguments by using the Default trait.

Perhaps Rust could adopt a syntax sugar for named arguments that just convert them to a struct at compile time. For example:

#[derive(Default)] struct Point { x: i32, y: i32 }

fn draw_point(p: Point);

// explicit call draw_point(Point { x: 10, y: 10 });

// syntax sugar for the above draw_point(x = 10, y = 10)

// explicit optional parameter draw_point(Point { x: 10, … Default::default() })

// syntax sugar for the above

draw_point(x = 10)

Actually. This could be a RFC.

looneysquash • 3 points • 2016-07-02

I personally think Default::default() is ridiculously long even for it’s normal purpose. There needs to be a really short way to write that for all uses. Something that’s still grep able, but is short and easy to type.

It seems odd to use = instead of :, since you use : for the struct literal syntax.

But I’m just nitpicking, I like the general idea.

There really ought to be sugar for defining such a function too, not just calling it.

protestor • 2 points • 2016-07-02

The thing is that a: b is the syntax for type ascription (and used in an example: foo(x: &[_], y: &[_]);), which could lead to some ambiguity.

Yeah, Default is unfortunately too verbose. :/

edit: but actually the syntax f(a = b) is already taken too: a = b is a valid expression and has type ().

[deleted] • 1 points • 2016-07-04

When the type is concrete (specific type or type parameter), I’d use T::default() instead.

When the type should be inferred from context, just like in Default::default(), you can also use the syntax <_>::default() literally. For obvious reasons that’s not very popular.

looneysquash • 2 points • 2016-07-04

IMO, the word default, even once, is too long. I wish you could just say .... Maybe you could use ..... Or maybe dft, to match things like fn and let.

Uncaffeinated • 1 points • 2016-07-03

It’s a shame there’s no way to get rid of the redundant Point. Otherwise, the syntax would be pretty good already.

[deleted] • 1 points • 2016-07-01

.1. Is more than just constexpr instead code generation to use the correct trait for formatting. I don’t see a way to implement that in regular rust even with constexpr.

[deleted] • 1 points • 2016-07-01

In Crystal variable (splat) arguments are packed as a tuple in the method argument. For example:

def foo(*args) args end

result = foo 1, “hello” typeof(result) # ⇒ Tuple(Int32, String)

Making varargs be tuples is very convenient and type safe, as one can forward them between methods.

We do something similar with named arguments: one can captured them with **args, and their type is a named tuple: a tuple where every key and its type is known at compile time.

But since Rust requires type arguments in every method, I don’t know if that’s doable, probably not…