# Allow "+" to follow path fragments in declarative macros
**URL:** https://internals.rust-lang.org/t/allow-to-follow-path-fragments-in-declarative-macros/13676
**Category:** language design
**Created:** [December 25, 2020, 2:55am UTC](https://internals.rust-lang.org/t/allow-to-follow-path-fragments-in-declarative-macros/13676 "2020-12-25T02:55:43Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@ldr709](https://internals.rust-lang.org/u/ldr709)
#### Post date: [December 25, 2020, 2:55am UTC](https://internals.rust-lang.org/t/allow-to-follow-path-fragments-in-declarative-macros/13676/1 "2020-12-25T02:55:43Z")
When writing a macro to match a type parameter, I ran into the requirement that paths must not be followed by a `+` character. Ideally the bound on the type could be matched with `: $bound:path $(+ $bounds:path)*`, but this is not allowed. It seems like allowing a `+` to occur here should not make the grammar ambiguous, or open Rust to future ambiguity if paths get changed, because a `+` is already used to separate bounds in the Rust grammar. Am I missing some compelling reason why `+` should not be allowed in this position?
---
### Author:  [@steffahn](https://internals.rust-lang.org/u/steffahn)
#### Post date: [December 25, 2020, 3:32am UTC](https://internals.rust-lang.org/t/allow-to-follow-path-fragments-in-declarative-macros/13676/2 "2020-12-25T03:32:17Z")
It might be because something like `Fn() -> &dyn Error` is also considered a path (yeah, I know, not the most intuitive thing.. but try it out), and terminating that with a `+` might be confusing.
---
### Author:  [@ldr709](https://internals.rust-lang.org/u/ldr709)
#### Post date: [December 25, 2020, 3:37am UTC](https://internals.rust-lang.org/t/allow-to-follow-path-fragments-in-declarative-macros/13676/3 "2020-12-25T03:37:37Z")
That's a good idea! However, it looks like there's already a rule keeping it from being ambiguous.
```rust
macro_rules! check_if_path {
{ $a:path } => {}
}
check_if_path!{Fn() -> &dyn Error + 'a}
```
([Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=076f54c54f5c5961bc27e1271e8cc216))
Errors with:
```rust
error: ambiguous `+` in a type
--> src/lib.rs:5:25
|
5 | check_if_path!{Fn() -> &dyn Error + 'a}
| ^^^^^^^^^^^^^^ help: use parentheses to disambiguate: `(dyn Error + 'a)`
```
---
### Author:  [@jhpratt](https://internals.rust-lang.org/u/jhpratt)
#### Post date: [December 25, 2020, 3:54am UTC](https://internals.rust-lang.org/t/allow-to-follow-path-fragments-in-declarative-macros/13676/4 "2020-12-25T03:54:01Z")
At the risk of going off topic...why is that considered a path?
---
### Author:  [@CAD97](https://internals.rust-lang.org/u/CAD97)
#### Post date: [December 25, 2020, 5:06am UTC](https://internals.rust-lang.org/t/allow-to-follow-path-fragments-in-declarative-macros/13676/5 "2020-12-25T05:06:43Z")
`Fn(Args..) -> Ret` is syntax sugar for the type path `::core::ops::Fn::`. Writing the former would ideally be identical to writing the latter.
---
### Author:  [@jhpratt](https://internals.rust-lang.org/u/jhpratt)
#### Post date: [December 25, 2020, 6:19am UTC](https://internals.rust-lang.org/t/allow-to-follow-path-fragments-in-declarative-macros/13676/6 "2020-12-25T06:19:15Z")
Not sure I particularly agree with it, but at least there's a valid reason 😅
---
### Author:  [@ldr709](https://internals.rust-lang.org/u/ldr709)
#### Post date: [December 25, 2020, 6:58am UTC](https://internals.rust-lang.org/t/allow-to-follow-path-fragments-in-declarative-macros/13676/7 "2020-12-25T06:58:06Z")
Paths are used in the grammar to specify trait bounds, which include `Fn(Args) -> Ret` syntax. See [https://doc.rust-lang.org/reference/trait-bounds.html](https://doc.rust-lang.org/reference/trait-bounds.html) (the nonterminal is called TypePath).
---
### Author:  [@system](https://internals.rust-lang.org/u/system)
#### Post date: [March 25, 2021, 6:58am UTC](https://internals.rust-lang.org/t/allow-to-follow-path-fragments-in-declarative-macros/13676/8 "2021-03-25T06:58:25Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.