From @matt1985's post it does look like <>
has the semantics of <..>
, if that were valid syntax: infer / use a placeholder parameter for each generic parameter (which is thus not the same as writing no turbofish, which gets to use default type parameters when available).
That being said, I find that behavior (on top of unintuitive) to be inconsistent and cause problems with some macros. Take, for instance, the following crate (of mine):
It works as follows: you #[with]
-annotate a function definition, say foo<T>
, and it converts that into a with_foo<R, F, T>
. Then, at call-site / usage-site, you also #[with]
-annotate a foo $(::<…>)?
call, and it converts that into a with_foo $(::<_, _, …>)?
to make sure the two added type parameters are inferred.
The fact that one can feed an "empty parameter sequence" into a turbofish site to express that all parameters should be inferred means that I now must special-case that pattern too (hence why it is inconsistent: it requires special-casing) to become:
foo $(::<$(…)?>)? -> with_foo $(::<$(_, _, …)?>)?
Granted, it's definitely a manageable inconsistency, but an inconsistency nonetheless. Could this kind of oversight(s) be removed in a future edition?
- That being said, it does bring into the table the topic of a syntax to explicitly elide all "remaining" (type?) parameters, which I think could be desirable in general (it could, for instance, make a
fn generic_with_anon_type_param<T> (f: impl …)
be fed a T
at call site: generic_with_anon_type_param<T, ..>
without requiring having solved the "can anonymous type parameters be explicitly fed" question).