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

Attribute to annotate functions that implement the for loop protocol #2505

Closed
bstrie opened this issue Jun 5, 2012 · 4 comments
Closed

Attribute to annotate functions that implement the for loop protocol #2505

bstrie opened this issue Jun 5, 2012 · 4 comments

Comments

@bstrie
Copy link
Contributor

bstrie commented Jun 5, 2012

It would be nice to be able to quickly determine which functions in a crate are intended to be used with for. Name could be something like #[for_protocol] or #[iterator]. I suppose this is something that could be detected automatically, but not every function that has the signature to be used with a for loop may be intended to be used with a for loop (if that makes any difference). This attribute could also automatically imply #[inline(always)], if that seems desirable.

@nikomatsakis
Copy link
Contributor

If it becomes a problem that functions are being used inappropriately, I would prefer to use types to enforce this constraint (for example, by returning a newtype'd boolean).

@catamorphism
Copy link
Contributor

I agree with @nikomatsakis fwiw. I'm going to be bold and close this, since we don't have enough data yet to know whether functions not-intended-to-be-used-with-a-for-loop getting accidentally used with a for loop is a problem. We can revisit this later if necessary.

@bstrie
Copy link
Contributor Author

bstrie commented Jun 7, 2012

I'm fine with closing this, but to be clear, I wasn't concerned with people using the wrong functions with for loops. I was more concerned with the documented discoverability of functions that were written with the for loop protocol in mind. For example, someone coming from another language might expect int::range(0, n) to return an array of integers, without having any clue why it takes a function as an argument, or why it behaves not at all as they expect. This is the exact opposite of what you were worried about: functions intended-to-be-used-with-a-for-loop-but-not. :)

@catamorphism
Copy link
Contributor

@bstrie Ah, ok. I think an external tool that's not part of the compiler could do this, since it's deducible just based on type signatures.

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
cope with rustc aborting due to a signal

`status.code().unwrap()` will panic when the process is aborted due to a signal.  Let's not do that.
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