On Wed, 13 May 2026 19:52:05 +0000, Seifeddine Gmati wrote: > Hi Daniil, > > Thanks for the support. That matters a lot. > > > 1) Turbofish at callsite: this was already brought up before, while I > > understand the precedence issues that led to this choice, having written > > some rust myself, I *still* don’t like the syntax, and would very much > > prefer normal diamond syntax at callsite, like for declarations. > > I personally like Turbofish; however, I understand that some people > might not find it "pretty". But the reason it has to stay as turbofish > is parser-level: `[A(D)]` is ambiguous between a single-element > array calling generic A and a two-element array of comparisons, and > there's no context-sensitive disambiguation that works inside > attributes, array expressions, and ternaries without introducing rules > that bite at exactly the worst places. Forcing parentheses around the > call (`[(A(D))]`) was suggested earlier in the thread and is > uglier than turbofish; it also closes the door on tuple syntax I'd > like to keep open for a future RFC. Turbofish costs two characters and > keeps the parser non-context-sensitive, which is the trade I'd rather > take. > > The `[self::foo::(1), self::foo::(2)]` case genuinely looks > the worst. The same call without turbofish (`[self::foo(1), > self::foo(2)]`) reads fine and is what the vast majority of call sites > will look like, since turbofish is opt-in for ambiguity resolution > (because inference is hard), and most calls won't need it. > > > 2) -/+ for variant bounds: also brought up before, while it *can* be > > somewhat mnemonic (- consumes for input params, + produces for output > > params), in/out would indeed be much more descriptive IMO (or at the very > > least, both options could be provided at the same time). > > Secondary vote added on this. `+T`/`-T` vs `in T`/`out T`. I have no > strong preference; the vote will decide. > > > I will implement support for this RFC in Psalm immediately after the RFC is > > approved > > Side note: I'm optimistic ;) > https://github.com/carthage-software/mago/pull/1826 > > Thanks again for the careful read. > > Cheers, > Seifeddine.
Leaving-the-door-open-for-tuples is a good additional argument for using the turbofish syntax; I'd say it's important enough to mention in the RFC.
