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

Implement user-defined type guard method #1501

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

tk0miya
Copy link
Contributor

@tk0miya tk0miya commented Feb 19, 2025

This implements the minimal version of user-defined type guard method. A user-defined type guard methos is a method defined by user that is able to guarantee the type of the objects (receiver or arguments).

At present, Steep supports type guard methods provided by ruby-core (ex. #is_a?, #nil?, and so on). But we also have many kinds of user-defined methods that are able to check the type of the objects.

Therefore user-defined type guard will help checking the type of these applications by narrowing types.

This implementation uses an annotation to declare user-defined type guard method.

class Example < Integer
  %a{guard:self is Integer}
  def integer?: () -> bool
end

For example, the following method Example#integer? is a user-defined type guard method that narrows the Example object itself to an Integer if the conditional branch passed.

example = Example.new
if example.integer?
  example  #=> Integer
end

In this PR, the predicate of type guards only supports "self is TYPE" statement. I have a plan to extend it:

  • %a{guard:self is arg}
  • %a{guard:self is_a arg}
  • %a{guard:self is TYPE_PARAM}
  • %a{guard:arg is TYPE}

Note: The compatibility of RBS syntax is the large reason of using annotations. I'm afraid that adding a new syntax to define it will bring breaking change to the RBS, and difficult to use it on common repository or generators (ex. gem_rbs_collection and rbs_rails).

refs:

@tk0miya tk0miya force-pushed the type_guard/self branch 2 times, most recently from 05bd3c7 to 1e9f080 Compare February 20, 2025 12:02
Comment on lines +752 to +762
def context_from(type_name)
if type_name.namespace == RBS::Namespace.root
[nil, type_name]
else
parent = context_from(type_name.namespace.to_type_name)
[parent, type_name]
end
end
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could not find such a helper method in Steep and RBS.
I'm not sure where the best place is.

This implements the minimal version of user-defined type guard method.
A user-defined type guard methos is a method defined by user that is
able to guarantee the type of the objects (receiver or arguments).

At present, Steep supports type guard methods provided by ruby-core (ex.
`#is_a?`, `#nil?`, and so on).  But we also have many kinds of
user-defined methods that are able to check the type of the objects.

Therefore user-defined type guard will help checking the type of these
applications by narrowing types.

This implementation uses an annotation to declare user-defined type
guard method.

```
class Example < Integer
  %a{guard:self is Integer}
  def integer?: () -> bool
end
```

For example, the above method `Example#integer?` is a user-defined
type guard method that narrows the Example object itself to an Integer
if the conditional branch passed.

```
example = Example.new
if example.integer?
  example  #=> Integer
end
```

In this PR, the predicate of type guards only supports "self is TYPE"
statement.  I have a plan to extend it:

* `%a{guard:self is arg}`
* `%a{guard:self is_a arg}`
* `%a{guard:self is TYPE_PARAM}`
* `%a{guard:arg is TYPE}`

Note: The compatibility of RBS syntax is the large reason of using
annotations.  I'm afraid that adding a new syntax to define it will
bring breaking change to the RBS, and difficult to use it on common
repository or generators (ex. gem_rbs_collection and rbs_rails).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant