Github Add :value macro capture designator by CAD97 · Pull Request #3106 · rust-...

Contributor

Can this be implemented using a proc macro?

I think the hard constraint on the feature is that the output of mac!() using the value matcher must be representable as a regular token stream.
(In this sense the "which cannot be directly implemented by just a desugaring of the macro_rules! invocation" part sounds a bit concerning.)

But if it can be represented as a token stream, then it should be implementable as a proc macro as well.

Author

What I'm trying to convey is that $:value cannot be implemented as a macro_rules! to macro_rules! transformation. The match trick has the exact semantics that we want here, so the semantics can be gotten by a simple token tree expansion (and thus by proc macros aware of the match trick). When I say this would be something macro_rules! has that proc macros don't, I'm specifically referring to the $:value shorthand, not any expressive power.

As an example,

macro_rules! sum_twice {
    ( $( $x:value ),+ $(,)? ) => ( 0 $( + $x )* $( + $x)* );
}

sum_twice( $a, $b, $c );

has no macro_rules! way to implement the desired semantics (due to the repetition), but can potentially expanded as

match $a { x$a =>
  match $b { x$b =>
    match $c { x$c =>
      0 + x$a + x$b + x$c + x$a + x$b + x$c
    ,}
  ,}
,}

(In practice I'm not sure how reasonable actually expanding to this or some other more compact MIR form would be.)

Not sure why there are so many new lines across the source. It makes it harder to read in non-rendered mode (which partially defeats the purpose of Markdown).

Member

A pattern I've seen is to use newlines after punctuation. The reasoning there is to reduce the diff noise of subsequent changes, as English prose often changes inside a clause, but less frequently between it. Using "arbitrary" newlines (e.g. at 80 columns) leads to a cascading series of diffs if you add enough words to an early line.

A smarter diff for Markdown in GitHub would be useful :)

Author

Yeah, and actually the rich diff does pretty okay at it. I probably did too much newlines in this document, but there's a happy medium somewhere. In any case, completely unwrapped text is worse than overly wrapped (in my opinion), and maintaining "reasonable" wrapping in a consistently updated document is annoying.

It also helps me pay attention to my clause length. If I'm just writing without thinking about it, I tend to get super long sentences, with (potentially many) levels of indirection, and it becomes difficult to read -- so I have ended up with some (kludgy but workable) workflow things to help balance it.[1]

[1]: yes this mess of a run-on was on purpose to illustrate the point

It would be best to explain those differences.

Author

I know and.... I'm not perfectly aware of what they all are, thus the sidestep here.

Is "function capture" accurate?

Spurious comment?

Author

This may or may not be useful, but it is intended, to indicate the context of when a guide/learner would be expected to explain/learn about $:value.

Spurious comment?

Author

This is less rationalized than the previous, but still intentional. It's basically just an explicit acknowledgement that one of the main motivators of the feature isn't even mentioned in the guide explanation.

Author

This comma is part of

asking for macros 2.0, which is still desirable, but still

so isn't it required here? (Does British English put the comma outside the quotes? I know the American English rules put the comma inside the quotes (and the Rust project generally prefers American English).)

Member

@CAD97 In technical writing, it's entirely normal to always put punctuation outside the quotes if it's not part of what's being quoted, following the British English quoting style even in otherwise American English writing.

I believe this is not quite accurate: You can't return/break/continue in an inline function from the calling scope, this only applies to closures passed to an inline function. I was told that Swift has the same feature.

Regarding prior art: Macros are usually used instead of functions when one of the following applies:

1. Want to bypass the type system
2. Closures are too restrictive
3. Writing it as a function would cause lifetime issues
4. Desire for more expressive syntax, like variadic, named or optional arguments

Kotlin's inline functions solve problem 2. Dynamically typed languages (and languages with more powerful type inference, like OCaml) solve problem 1. Many languages also have fancy syntax such as variadics or template strings, to reduce problem 4. Problem 3 is specific to Rust. I believe my point is that there is no prior art because most languages get by without macros (and if a language has a macro system it's rarely as advanced as Rust's).

Member

nit: this word is redundant -- "instead expand to [code] instead."