Skip to content

Allow ifaces to refer to their own type #1661

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

Closed
marijnh opened this issue Jan 25, 2012 · 1 comment
Closed

Allow ifaces to refer to their own type #1661

marijnh opened this issue Jan 25, 2012 · 1 comment

Comments

@marijnh
Copy link
Contributor

marijnh commented Jan 25, 2012

It must be possible, when specifying methods, to refer to the type that the interface is implemented on. For example, an add method on iface num, which takes an extra parameter of the same type and returns a value of the same type, can't be expressed in the current system without adding a lot of noisy type parameters.

iface num {
  fn add(x: self) -> self;
  fn sub(x: self) -> self;
  /* etc */
}

impl of num for int {
  fn add(x: int) -> int { self + x }
  fn sub(x: int) -> int { self - x }
}

The self type is an implicit type parameter refers to the specialized type. An interface that uses it can not be cast to, since it'd be impossible to type its methods in the absence of a concrete self type.

@ghost ghost assigned marijnh Jan 25, 2012
@marijnh
Copy link
Contributor Author

marijnh commented Jan 25, 2012

So the way this ended up working, internally, is somewhat kludgy, which suggests it might not be the most well-designed feature. Constructive feedback welcome.

marijnh added a commit that referenced this issue Jan 26, 2012
@marijnh marijnh removed their assignment Jun 16, 2014
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
…unctions (rust-lang#1661)

Instead of having to manually wrap the code in `kani::spawnable_block_on` as in rust-lang#1659, this PR allows `#[kani::proof]` to be applied to harnesses that use `spawn` as well. For this to happen, the user has to specify a scheduling strategy.

Co-authored-by: Celina G. Val <[email protected]>
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

No branches or pull requests

1 participant