Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/rust-lang/rust/issues/34511 below:

Tracking issue for `impl Trait` (RFC 1522, RFC 1951, RFC 2071) · Issue #34511 · rust-lang/rust · GitHub

The basic feature as specified in RFC 1522 is implemented, however there have been revisions that are still in need of work:

• impl Trait in argument position
  • extend to cover traits
  • support elision Argument-position impl Trait requires a named lifetime #49287
• impl Trait in return position is basically implemented, but:
  • filter lifetimes
  • code accepts types with out-of-scope lifetimes 🚀 existential impl Trait allows lifetimes that would not be allowed by abstract type #46541
  • ICEs when interacting with elision impl Trait Lifetime Elision #43396
  • ICE combining universal and existential ICE combining universal plus existential impl Trait #46685
  • ICE with nested lifetimes Nested "impl trait" with lifetimes causing internal compiler error #46464
  • Infinitely recursive types not detected Infinite size checker doesn't see through impl Trait, leading to rustc overflow #38064
    • Better error message for infinitely recursive types Improve error message for infinitely recursive impl Trait type #47659 (fixed in Forbid recursive impl trait #56074)
  • do not accept nested impl trait described here (fixed in Fix nested impl trait lifetimes #48072)
• let x: impl Trait
• static and const T: impl Trait
• abstract type
  • preliminary refactoring possibility
  • in modules
  • in traits

There have been a number of RFCs regarding impl trait, all of which are tracked by this central tracking issue.

• Minimal impl Trait rfcs#1522
  • the original, which covered only impl Trait in return position for inherent functions
• RFC: Finalize syntax and parameter scoping for impl Trait, while expanding it to arguments rfcs#1951
  • settling on a particular syntax design, resolving questions around the some/any proposal and others.
  • resolving questions around which type and lifetime parameters are considered in scope for an impl Trait.
  • adding impl Trait to argument position.
• Named existentials and impl Trait variable declarations rfcs#2071
  • named abstract type in modules and impls
    • Finalize syntax ( Permit impl Trait in type aliases rfcs#2515)
    • Update RFC RFC: Associated type bounds of form MyTrait<AssociatedType: Bounds> rfcs#2289 to match that syntax if that RFC gets merged.
  • use of impl trait in let, const, and static positions
• mini-RFC: Finalize syntax of impl Trait and dyn Trait with multiple bounds rfcs#2250
  • Finalizing the syntax of impl Trait and dyn Trait with multiple bounds

The implementation has raised a number of interesting questions as well:

• What is the precedence of the impl keyword when parsing types? Discussion: 1
  • e.g., how to associate Send for where F: Fn() -> impl Foo + Send?
  • Resolved by mini-RFC: Finalize syntax of impl Trait and dyn Trait with multiple bounds rfcs#2250.
  • Implemented (?) in syntax: Lower priority of + in impl Trait/dyn Trait #45294
• Should we allow impl Trait after -> in fn types or parentheses sugar? [impl Trait] Should we allow impl Trait after -> in fn types or parentheses sugar? #45994
• Do we have to impose a DAG across all functions to allow for auto-safe leakage, or can we use some kind of deferral. Discussion: 1
  • Present semantics: DAG.
• How should we integrate impl trait into regionck? Discussion: 1, 2
  • Resolved in impl Trait Lifetime Handling #45701
• Should we permit specifying types if some parameters are implicit and some are explicit? e.g., fn foo<T>(x: impl Iterator<Item = T>>)?
  • Current behavior: An error to specify types
  • Other alternatives: treat impl Trait as arguments in the list, permitting migration
• Some concerns about nested impl Trait usage
• Should the syntax in an impl be existential type Foo: Bar or type Foo = impl Bar? (see here for discussion)
  • Settled by Permit impl Trait in type aliases rfcs#2515.
• Should the set of "defining uses" for an existential type in an impl be just items of the impl, or include nested items within the impl functions etc? (see here for example)

LooMaclin, aldanor, zen0wu, lord, yuval-k and 60 moreObject905, LooMaclin, pinkisemils, NotBad4U, discosultan and 14 morelambda-fairy, kaedroho, pthariensflame, Antti, ozkriff and 91 more

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4