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

Update non-local-defns regarding parameterized traits and types #3581

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Directly put URLs in links rather than using footnotes/endnotes
  • Loading branch information
joshtriplett authored Apr 2, 2024
commit 426b048568cbf819da54d42e862341a23d18ec08
13 changes: 6 additions & 7 deletions text/3373-avoid-nonlocal-definitions-in-fns.md
Original file line number Diff line number Diff line change
Expand Up @@ -47,8 +47,10 @@ subsequent Rust edtion, tools will be able to rely on this as well.
# Explanation
[explanation]: #explanation

An "expression-containing item" is defined as any [expression] where an [item]
may be defined, for example:
An "expression-containing item" is defined as any
[expression](https://doc.rust-lang.org/reference/expressions.html) where an
[item](https://doc.rust-lang.org/reference/items.html) may be defined. For
example:
- Functions
- Closures
- The values assigned to `static` items or non-anonymous `const` items.
Expand Down Expand Up @@ -109,7 +111,8 @@ the signature without reflecting those properties in the signature.
[unresolved-questions]: #unresolved-questions

Should we flag these definitions in anonymous `const` items as well? This is
used in some macro expansions for [compatibility reasons][1].
used in some macro expansions for
[compatibility reasons](https://github.com/rust-lang/rfcs/pull/3373#issuecomment-1885307786).

Is the last rule regarding parameterized trait `impl` items viable to implement?

Expand All @@ -119,7 +122,3 @@ Is the last rule regarding parameterized trait `impl` items viable to implement?
If in the future Rust provides a "standalone `derive`" mechanism (e.g. `derive
Trait for Type` as a standalone definition separate from `Type`), the `impl`
produced by that mechanism would be subject to the same requirements.

[expression]: https://doc.rust-lang.org/reference/expressions.html
[item]: https://doc.rust-lang.org/reference/items.html
[1]: https://github.com/rust-lang/rfcs/pull/3373#issuecomment-1885307786