Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[ConstraintSystem][SE-0249] Key Path Expressions as Functions #26054
This builds on @brentdax's work in #23435 to handle optional chaining key paths as both KeyPath BGTs and as function types, and also does away with explicit disjunctions to determine which kind of type to turn the key path literal into, so ought to be more performant.
There is a single test diagnosis that gets worse here (a contextual type which matches root/value but specifies an incorrect writability is now ambiguous because the diagnostic path goes into the old CSDiag stuff, and the first step is to discard contextual type, and then the remainder is entirely ambiguous). The solution is future work to improve key path diagnoses in general, I think.
xedin left a comment
I left a couple of comments inline. But I really want for us to consider a meta-question here - should keypath handling be re-designed in a way where keypath type drives access to the components instead of components determining what access is going to be? That way it should be much easier to diagnose invalid writable calls and avoid creating all of the conversions from l-value result to r-value result types.
While generating constraints check whether there is a contextual type - if so, everything is easy, otherwise start with assumption that it's a
Solving keypath would mean solving all of the associated components so we no longer have to wait for overload choices to be made and re-generate the same constraint or iterate over components multiple times.