Skip to content
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

is Type fails in parameters #5540

Open
alabamenhu opened this issue Mar 26, 2024 · 2 comments
Open

is Type fails in parameters #5540

alabamenhu opened this issue Mar 26, 2024 · 2 comments
Labels
consensus needed Needs a well-versed decision with justification, possibly from a core developer data types Arrays, lists, hashes, pair objects, etc. dispatching Routine dispatching feature request needs research NYI Features not yet implemented signatures/captures

Comments

@alabamenhu
Copy link
Contributor

The Problem

The trait form of specifying types does not work properly on parameters. This is particular problematic for containers as their container (or key, in the case of Associative) type cannot be specified any other way but for a clunky work around using multi subs.

Expected Behavior

sub foo(%s is Set) {  
    say %s.WHAT; # Set (or some subclass thereof)
}

Actual Behavior

sub foo(%s is Set) {  # compile time error, see output
    say %s.WHAT; 
}

Output

Can't use unknown trait 'is' -> 'unknown subtype' in a parameter declaration.
at -e:1
    expecting any of:
        rw
        readonly
        copy
        required
        raw
        leading_docs
        trailing_docs

Environment

All versions of Rakudo, error message changed in early 2019. See bisect output

@lizmat lizmat added NYI Features not yet implemented consensus needed Needs a well-versed decision with justification, possibly from a core developer needs research feature request data types Arrays, lists, hashes, pair objects, etc. dispatching Routine dispatching signatures/captures labels Mar 26, 2024
@lizmat
Copy link
Contributor

lizmat commented Mar 29, 2024

FWIW, I think the workaround of sub foo(Set $s) { } is not really an inconvenience?

@alabamenhu
Copy link
Contributor Author

FWIW, I think the workaround of sub foo(Set $s) { } is not really an inconvenience?

I mean sure, for sets. But we have sigils and I like to use them :) Also, assignment behavior is affected if someone were to want to assign into an associative/positional parameter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
consensus needed Needs a well-versed decision with justification, possibly from a core developer data types Arrays, lists, hashes, pair objects, etc. dispatching Routine dispatching feature request needs research NYI Features not yet implemented signatures/captures
Projects
None yet
Development

No branches or pull requests

2 participants