Use 2021 Rust

text/0006-2021-rust.md

@@ -0,0 +1,72 @@
+- Feature Name: 2021-rust
+- Start Date: 2021-10-01
+- RFC PR: [fuel-labs/rfcs#0006](https://github.com/FuelLabs/rfcs/pull/0006)
+- Issue: [fuel-labs/rfcs#0005](https://github.com/FuelLabs/rfcs/issues/0005)
+
+# Summary
+[summary]: #summary
+
+Rust aims for [Stability as a Deliverable](https://blog.rust-lang.org/2014/10/30/Stability.html). Having that said, upgrades are seamless and the main concern lies on backwards compatibility. The 2021 edition is expected to land soon (Oct 21st) and will be the standard for the new crates of the ecosystem. By preemptively enabling Rust-2021 in our libraries, we can benefit from the improvements of the new edition and save the future effort of migrating the libraries.
+
+# Motivation
+[motivation]: #motivation
+
+The new [resolver standard](https://blog.rust-lang.org/2021/03/25/Rust-1.51.0.html#cargos-new-feature-resolver) improves the version and features resolution across the dependencies, and currently it needs to be enabled manually in [fuel-core](https://github.com/FuelLabs/fuel-core/commit/ae9f426f06200dfb0bb440a2944588d27d323a19#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542R3).
+
+Besides that, keywords that are prone to be reserved in the future are introduced as reserved keywords to reduce refactoring risks for libraries. Also, importing common traits and iterator implementations for common types (e.g. arrays) are included in the prelude of the library. If we develop under 2018 edition, we will need to refactor references `std::convert::TryFrom` and array iterators when 2021 becomes the standard.
+
+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+N/A
+
+# Reference-level explanation
+[reference-level-explanation]: #reference-level-explanation
+
+N/A
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+Rust2021 is currently protected by a feature in stable channel, and available in nightly/beta. Having that said, we need to enable either the feature or nightly/beta channels in our CI.
+
+By using nightly we need to pay extra attention during the PR reviews to evaluate trade-offs when using unstable features.
+
+Also, there is a chance the used features will have their API reworked, and this will imply code update. This may lead to the need of freezing the CI versions to some specific release while these updates are not done.
+
+The language tooling of Rust is well known to be very unstable with nightly. This impacts mainly `rustfmt` and `rls - Rust Language Server`. The community created [this panel](https://rust-lang.github.io/rustup-components-history/) to keep track of the available tools.
+
+# Rationale and alternatives
+[rationale-and-alternatives]: #rationale-and-alternatives
+
+Rust uses the release train strategy for its release cycle and benefits from a highly robust regressions test codebase. This way, the stable toolchain flags the API stability and not the functionality stability. For libraries under heavy development such as ours, the API is per nature prone to change. API stability brings small or no benefit compared to the benefits provided by the nightly features. As opposed to normal agile flows, the release train stable cycle relies on longer iterations. This means any codebase developed under stable will be, by definition, outdated.
+
+Traditionally, the libraries are developed under nightly in the Rust ecosystem, and only after the first major release do they consider switching to stable. The most classic example is Rocket - a four years old project that only recently is targetting stable.
+
+The main misconception about nightly regards the meaning of stable for Rust. Quoting the Rust book:
+
+```
+Rust uses a technique called “feature flags” to determine what features are enabled in a given release. If a new feature is under active development, it lands on master, and therefore, in nightly, but behind a feature flag.
+```
+[link](https://doc.rust-lang.org/book/appendix-07-nightly-rust.html)
+
+This means that features under development are protected in nightly and not available in stable. These features rely on compiler directives and cannot ever be used by accident. The implication of that is we have a reflection of stable as a subset of nightly where we do not have any unstable features flag. Hence, nightly ultimately supersede stable.
+
+The main advantage of nightly is we have our codebase updated for upcoming major - and important - changes in the Rust environment. The next major change is the [2021 release](https://blog.rust-lang.org/2021/05/11/edition-2021.html) that brings many benefits - especially the [new resolver scheme](https://doc.rust-lang.org/cargo/reference/resolver.html#feature-resolver-version-2).
+
+Besides that, nightly also makes available several small helpers that are very unlikely to contain inner instabilities such as [is_sorted](https://doc.rust-lang.org/std/primitive.slice.html#method.is_sorted). These helpers can significantly improve the coding efficiency without importing additional libraries or reimplementing classical algorithms.
+
+# Prior art
+[prior-art]: #prior-art
+
+N/A
+
+# Unresolved questions
+[unresolved-questions]: #unresolved-questions
+
+N/A
+
+# Future possibilities
+[future-possibilities]: #future-possibilities
+
+N/A