Rust very deliberately treats parsing as an isolated step in compilation. The ASTs of {function + type parameter + arguments} and {value + indexing + call} are

Rust very deliberately treats parsing as an isolated step in compilation. The ASTs of {function + type parameter + arguments} and {value + indexing + call} are very different. At parse time, you don’t know what types and values are in scope—they’re resolved later. Some languages have been willing to compromise on this (C and C++ certainly do, and Perl is famously unparseable), but it always causes a great deal of pain, as you can’t build any sort of isolated tooling around the language any more, but must use an actual compiler to even try to parse the thing properly if you want to be robust; static analysis is thus made more difficult, especially as you must now look at entire projects and can’t properly look at individual files—and worse, you must be able to compile the project to be able to analyse it. So Rust has deliberately gone the other way: you can parse the language easily and completely, so any form of static analysis doesn’t need a real compiler to back it and can act on files in isolation. In short, Rust is philosophically obdurately opposed to needing to do disambiguation in the parsing phase. So it’s actually not really about the actual ambiguity, which might not even be a thing—I can’t remember whether {function + type parameter} would be looking up in the type or value namespaces, so my example might actually be wrong there—but rather that you can devise supporting code that would seem to make `a[b](c)` mean two different things, and that’s untenable for Rust, because it refuses to let scope contents influence the parse.