paulk-asert commented on PR #3020: URL: https://github.com/apache/groovy/pull/3020#issuecomment-6407704164
Thanks Daniel, and good question on point 4. Looking at it again turned up a regression, now fixed in the latest push. On ordering: the checker's bindName follows the runtime dispatcher exactly (Comprehensions.resolveMethodName): registry entries (Class-keyed, then name-keyed), then a structural single-arg flatMap, then @Monadic(bind=...). So a class with both a flatMap and @Monadic(bind='chain') binds via flatMap in both places. On point 3 and point 4: the bound type's position doesn't matter when the bind signature is readable. It's resolved from the bind function's input (`? super A`) whatever slot A occupies, which the @Monadic Tri<E, A, X> test shows. Position only matters in the fallback, used when the bind parameter names no input: a Closure, or a raw Function or fj.F. In that case, falling back to the last type argument regressed carriers like `Box<A, M>` with an untyped `flatMap(Closure)`, which compiled before this PR. The fallback is now the first type argument, as before, so this PR only changes typing when the bind signature gives the answer. New tests: - the fallback for a Closure bind and for a raw Function bind, with the bound type first (both fail with the last-argument fallback) - a bind declared as an interface default method, on a receiver whose type parameters are reordered - a wildcard receiver, Result<String, ? extends Integer> - a name-keyed fj.data.Validation<E, T> stub, as suggested on the JIRA The bind-input tests all fail against the checker before this PR. groovy-macro-library 62/0, groovy-typecheckers 376/0, lintGate clean. A Closure-typed bind with the bound type last, such as GRes<E, A>, still uses the fallback, as it did before. Static type checking already reads @ClosureParams for a direct call to such a bind, so DO should too. That's GROOVY-12531 for Groovy 7. It needs a decision on how @ClosureParams ranks against the bound-type information that GEP-23's carrier registration may add, so I've kept it out of this PR. This affects the 6.0.0 allow-list rows (Vavr Either/Validation, Functional Java Validation) and cherry-picks cleanly onto GROOVY_6_0_X, so I plan to backport it to 6.0.1. GROOVY-12485 (the Zazr rows) builds on it: Zazr Either and Validation bind on their last type parameter. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
