Skip to content

Allow borrowing an Enum variant as a plain tuple (Feat. Req.) #7407

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
bluss opened this issue Jun 26, 2013 · 4 comments
Closed

Allow borrowing an Enum variant as a plain tuple (Feat. Req.) #7407

bluss opened this issue Jun 26, 2013 · 4 comments

Comments

@bluss
Copy link
Member

bluss commented Jun 26, 2013

Allow borrowing an enum variant as a tuple of the same types, so that you can use methods already defined on a tuple with those types.

enum Pair<A,B> {
  Nothing,
  Two(A, B),
}

let p: Pair<A, B>;
match p {
   Two(a, b) => (a, b).iter_bytes()
}

This would allow dispatching methods without cloning the Enum variant.

Dispatching tuple methods allow enum impls to re-use functions that are already generically defined over tuples for all type combinations (for example IterBytes).

In a way, it's a simple way to manually do the work of the deriving directive, by reusing the tuple implementation.

@jdm
Copy link
Contributor

jdm commented Jun 26, 2013

Can you use tuple@Two(a, b) => tuple.iter_bytes()?

@bluss
Copy link
Member Author

bluss commented Jun 26, 2013

jdm, no. For the purposes of this example, Pair does not implement the trait we want to use. IterBytes is a convenient example because that trait exists in std. Of course for this particular trait we have an alternative -> deriving, but I think the tuple borrow would be generally useful.

@Aatch
Copy link
Contributor

Aatch commented Jun 28, 2013

I'm not sure what you're asking here, if it's to allow something like the pattern Variant(a,b,c) => (a,b,c).foo() to not copy a, b or c, that isn't possible since it would involve some very surprising behaviour and would not play well with pretty much every other feature of Rust. It would also force the compiler to look for such patterns, something that would be so fragile it would make the feature useless.

If you're asking to treat Variant(a,b,c).foo() as a call to (a,b,c).foo(), then that isn't possible because methods are resolved based on the type.

I'm going to close this as I cannot think of a realistic use case where you wouldn't just use a tuple anyway.

@Aatch Aatch closed this as completed Jun 28, 2013
@bluss
Copy link
Member Author

bluss commented Jun 28, 2013

it's not about pattern matching, but allowing to borrow a variant as a pointer to a similar tuple type. It could be a function.

flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 1, 2021
Don't suggest doc(hidden) or unstable variants in wildcard lint

Clippy's wildcard lint would suggest doc(hidden) and unstable variants for non_exhaustive enums, even though those aren't part of the public interface (yet) and should only be matched on using a `_`, just like potential future additions to the enum. There was already some logic to exclude a *single* doc(hidden) variant. This extends that to all hidden variants, and also hides `#[unstable]` variants.

See rust-lang#85746 (comment)

This PR includes rust-lang/rust-clippy#7406 as the first commit.

Here's the diff that this PR adds on top of that PR: m-ou-se/fork@std-errorkind...m-ou-se:doc-hidden-variants

---

*Please write a short comment explaining your change (or "none" for internal only changes)*

changelog: No longer suggest unstable and doc(hidden) variants in wildcard lint. wildcard_enum_match_arm, match_wildcard_for_single_variants
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

3 participants