From 00997d7ad202861dafad87e971891cf31ca8ac12 Mon Sep 17 00:00:00 2001 From: Jacob Pratt Date: Sat, 8 Oct 2022 01:47:57 -0400 Subject: [PATCH] Fix typos in RFCs 3251-3309 --- text/3289-source_replacement_ambiguity.md | 2 +- text/3307-de-rfc-type-ascription.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/text/3289-source_replacement_ambiguity.md b/text/3289-source_replacement_ambiguity.md index 032b039ac..976de9caf 100644 --- a/text/3289-source_replacement_ambiguity.md +++ b/text/3289-source_replacement_ambiguity.md @@ -63,7 +63,7 @@ error: crates-io is replaced: use `--registry replacement` or `--registry crates ### Change 3: credentials are only sent to the same registry If the `crates-io` source is replaced with another remote registry, the credentials for -`crates-io` are never sent to the replacement registry. This makes `crates-io` consistant +`crates-io` are never sent to the replacement registry. This makes `crates-io` consistent with alternative registries and ensures credentials are only sent to the registry they are associated with. diff --git a/text/3307-de-rfc-type-ascription.md b/text/3307-de-rfc-type-ascription.md index bd7e03ae4..dfeb3d0b0 100644 --- a/text/3307-de-rfc-type-ascription.md +++ b/text/3307-de-rfc-type-ascription.md @@ -27,7 +27,7 @@ Syntax isn't the only reason; while type ascription is probably a good idea, a f # Guide-level obfuscation [guide-level-obfuscation]: #guide-level-obfuscation -The `:` type ascription syntax would be removed from the nightly language. It is up to the compiler team whether they wish to remove it completely from the compiler (or perhaps just make it unparseable and use some magical unstable `ascript!()` macro in the meantime so that it is testable). +The `:` type ascription syntax would be removed from the nightly language. It is up to the compiler team whether they wish to remove it completely from the compiler (or perhaps just make it unparsable and use some magical unstable `ascript!()` macro in the meantime so that it is testable). This does not prevent future type ascription RFCs from happening, however they must propose the feature from first principles, and justify their choice of syntax. They are, of course, free to copy the work or text of the previous RFC.