Tracking issue for 1.0.0 release

[Aaron1011]

Current pre-release: 1.0.0-alpha.1

There haven't been any API changes since the #[project] attribute was deprecated. Since there are currently no open issues, I think it's a good time to release version 1.0.0.

Since this is a Semver-incompatible release, we could take the opportunity to remove the #[project], #[project_ref], and #[project_replace] attributes. Otherwise, I don't think any changes need to be made other than bumping the version number.

[taiki-e]

Sounds good 👍 If I remember correctly, there are basically only 3 changes required:

• remove helper attributes (remove project* attributes); done in Remove project, project_ref, and project_replace attributes #265
• remove Replace argument (Allow project_replace argument to be used without Replace #243 (comment)); done in Remove Replace argument #266
• change to define projection-type to inside const _: () = {} when the users don't name it; done in Do not expose unnamed projected types #268

[taiki-e]

Another likely change is to remove support for rust 1.34-1.36 and remove the build-script, but I have no particular strong opinion on this.

[taiki-e]

Released 1.0.0-alpha.1. I'll wait for a few weeks and then release 1.0.0 if we don't have any big issues.

[taiki-e]

Previously, I said "we need to decide on a policy when we release 1.0" in #219 (comment).
I think "at least support a year ago compiler, and MSRV bump requires minor version bump" is preferable at this time.
However, I think it is unlikely that we will rely on language features that really require MSRV bump from 1.37.

[taiki-e]

FWIW, here is a list of language features/changes that I think may affect pin-project(-lite) in the future:

• safe_packed_borrow become a hard error (repr(packed) allows invalid unaligned loads rust-lang/rust#27060)
  The currently applied safe_packed_borrow becomes unknown lint and Can bypass repr(packed) checking by using --cap-lints pin-project-lite#26 becomes fixed. There are no code changes on pin-project(-lite) side.
• proc_macro_def_site stabilized (Tracking issue for Span::def_site() rust-lang/rust#54724)
  We can use this via build script. (Perhaps actually proc-macro2 should handle it.)
• trivial_bounds stabilized (Tracking issue for RFC #2056: Allow trivial constraints to appear in where clauses  rust-lang/rust#48214)
  The existing code is not broken, so code changes on pin-project(-lite) side are not needed.
• Implemented & stabilized RFC 2145 private in public (Tracking issue for RFC #2145: Type privacy and private-in-public lints  rust-lang/rust#48054)
  We can use this via build script. Or the existing code is not broken, so code changes on pin-project(-lite) side are not needed.
• Implemented & stabilized RFC1598 generic associated types (🔬 Tracking issue for generic associated types (GAT) rust-lang/rust#44265)
  We can use this via build script. Or major version bump is needed (breaking change on public API)
• Implemented & stabilized inherent associated types (Tracking issue for inherent associated types rust-lang/rust#8995)
  We can use this via build script. Or major version bump is needed (breaking change on public API)

(There are many uncertainties, so this list does not include anything like significant changes in the existing macro system, unapproved RFCs, or pre-RFCs.)