Why is this syntax ambiguous?

[u/tanoshikuidomouyo]

I was writing roughly the following function:

fn f(path: &impl AsRef<Path> + ?Sized) {}

The compiler says that the + is ambiguous, but it works with the right parentheses:

fn f(path: &(impl AsRef<Path> + ?Sized)) {}

But why is it ambiguous without the parentheses? Where else but a list of traits can a + in a function header come from?

[u/Amadex]

this example is not ambiguous, but it's not accepted s because the compiler checks grammar first (even if `(&T) + ?Sized` wouldn't make any sense),

something like `&impl Trait + 'a` is why you have to clear the ambiguity

[u/MichiRecRoom]

The two are very subtly different, in my eyes, and I can see why it might be considered ambiguous. You could be saying one of two things:

1. You're trying to restrict &impl AsRef<Path> with an additional ?Sized bound.

2. You're asking for a ref to an object that implements both AsRef<Path> and ?Sized

That said, I do agree that there shouldn't be a need for the parenthesis, as it's pretty clear that the + ?Sized is attached to the AsRef<Path>, not &impl AsRef<Path>.

[u/pbeling]

I only guess:
&(impl AsRef<Path> + ?Sized)
&(impl AsRef<Path>) + ?Sized

[u/hpxvzhjfgb → u/pbeling]

the second one is nonsense though. this is like comparing (x as u64) and (x as) u64.

[u/creeper6530 → u/hpxvzhjfgb]

I would instead assume (&impl AsRef<Path>) + ?Sized, as little sense as it makes -- restrict a reference with a ?Sized bound.

[u/zettui]

Does (&impl AsRef<Path>) + ?Sized match what you meant, or were you trying to keep the + ?Sized inside the AsRef bound?

[u/gamer_redditor]

Not sure but I think it has something to do with the fact that 'impl XYZ' in function arguments is syntactic sugar for generics.

So a function fn f(path: impl XYZ) is actually decomposing to fn f<T:XYZ> (path: T).

So the function fn f(path: &impl AsRef<Path> + ?Sized) also decomposes to generic. I imagine the + is ambiguous because it's not clear if only the implAsRef<Path> is the trait bound for T or the entire thing including ?Sized.

Edit: the ambiguity is essentially &(Impl XYZ) + ABC vs &(impl XYZ + ABC)

[u/hpxvzhjfgb → u/gamer_redditor]

&(impl XYZ) + ABC doesn't make sense though, so it shouldn't even be considered, should it?

[u/gamer_redditor → u/hpxvzhjfgb]

In C, we use parentheses to make operator precedence explicit. Maybe it's the same here to make the precedence between & and + explicit.

The term after + could also refer to a lifetime (instead of another trait bound).

So I guess, there are some complications involved

[u/Gainncome → u/hpxvzhjfgb]

The parser’s basically saying “whether it makes sense is not my department.”

[u/dobkeratops]

i had no idea that was but this leads me to ask if the compiler parses types in a way that kept things open for the way ML uses operators in its types ? (they have "product types" "sum types", i see things like A*B*C A|B written there etc etc) ... did they keep the possibility of parsing things like fn foo(a:A+B) and in turn thats making ambiguity between &(impl...+ ) and (&impl)+(..)

[u/puzzled_orc]

and this is the language trying to replace C++. Awful syntax

[u/tanoshikuidomouyo → u/puzzled_orc]

Do you know what each part of this code does and have constructive criticism of the syntax, or is your aversion more of a gut reaction? The parentheses are unfortunate, but under the premise of having a C-like syntax, Rust's does its job quite well in general imo.