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<B, C>(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<B, C>(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::<Bar>(1), self::foo::<Bar>(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.
