New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't make signature part of a callable named parameter #4538
Conversation
PR needs one more change. Declarations like |
I have fixed the case when a signature-constrained named parameter results in There is a couple of notes on feasibility of making signature-constrained parameters optional. The primary problem about them is that the default value (which is There are possible workarounds. The first is to mixin a custom role into the parameter default with a The second is to add User-based solution for optional callable parameter within the approach taken by this PR would be UPD Optional constrained parameters are now implemented. |
There is a bug related to type captures: sub foo(::T, &bar:(T)) { ... } The constraining signature is not getting instantiated. Perhaps, instantiating post-constraints list would work as expected. If not then attaching the constraining signature onto the |
dc7d516
to
32703ba
Compare
When a named parameter is declared as `:&foo:(Int)` the name used for parameter binding was `foo:(Int)` resulting in falling back to parameter's default - `Callable`. A visible effect of this error was parameter checking to attempt calling `signature` method on `Callable` role.
A major change this commit introduces is relocation of signature object from inside a `where` block into an attribute of `Parameter::SignatureConstraint` role which is mixed into `Parameter` when necessary. Correspondingly, constraint is now checked as part of signature binding when and only when the signature is used in parameter declaration. This commit also introduces support for generic signature constraints. I.e.: sub foo(::T, :&fn:(T)) {...} now works as expected. 1 TODO in t/spec/S03-smartmatch/signature-signature.t is unlocked, but t/spec/S06-signature/closure-parameters.t is broken.
Mark multi-candidates with signature constrained parameters as `bind_check` and `constrainty`. Resolve ambiguous matching.
rakudo/rakudo#4538 makes signature constraints work in signature smartmatching.
Unfudge a now passing test. It needed to be corrected a little too because by default parameters are typed with `Mu`, not `Any`. Added tests to cover rakudo/rakudo#4537. Added tests for newly implemented support for generics. In support of rakudo/rakudo#4538
It was about wrong assumption that a new `Attribute` instance would be allocated per each instance of `Parameter`. No idea what's got over me when the idea came into my mind... `$!signature_constraint` is now a permement member of `Parameter` class.
As we now have access to this information, .raku output would better resemble the original declaration.
This PR is ready for merge. CI JVM failures are there on master, they are not caused by the PR. Signature constraint information has been relocated from inside a Aside of that, it should be possible now to consider the constraining signature in multi-dispatch deliberately, using it to better narrow down the selection of matching candidates. Unfortunately, I'm not sufficiently familiar with multi-dispatch guts to tweak them. I have not found a reliable way to determine if a named parameter, or an optional positional, was actually passed with a routine call or not. For this reason I deduct the fact of it being missing by comparing parameter variable value to parameter's default type. It would be totally OK with the default |
So far as RakuAST goes, my expectation is that we'll compile every kind of signature (including unpacks and destructuring), only using the slow-path binder for error reporting. |
When a named parameter is declared as
:&foo:(Int)
the name used forparameter binding was
foo:(Int)
resulting in falling back toparameter's default -
Callable
. A visible effect of this error wasparameter checking to attempt calling
signature
method onCallable
role.
Resolves #4537