From 8dad941d6f08b7cd12032cef8b43d83559327285 Mon Sep 17 00:00:00 2001
From: Brian Anderson <banderson@mozilla.com>
Date: Wed, 11 Jun 2014 15:39:36 -0700
Subject: [PATCH 1/2] RFC for removing integer inference fallback

---
 active/0000-rm-integer-fallback.md | 73 ++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)
 create mode 100644 active/0000-rm-integer-fallback.md

diff --git a/active/0000-rm-integer-fallback.md b/active/0000-rm-integer-fallback.md
new file mode 100644
index 00000000000..5c4d63ca369
--- /dev/null
+++ b/active/0000-rm-integer-fallback.md
@@ -0,0 +1,73 @@
+- Start Date: 2014-06-11
+- RFC PR #: (leave this empty)
+- Rust Issue #: 6023
+
+# Summary
+
+Currently we use inference to find the current type of
+otherwise-unannotated integer literals, and when that fails the type
+defaults to `int`. This is often felt to be potentially error-prone
+behavior.
+
+This proposal removes the integer inference fallback and strengthens
+the types required for several language features that interact with
+integer inference.
+
+# Motivation
+
+With the integer fallback, small changes to code can change the
+inferred type in unexpected ways. It's not clear how big a problem
+this is, but previous experiments[1] indicate that removing
+the fallback has a relatively small impact on existing code,
+so it's reasonable to back off of this feature in favor of more
+strict typing.
+
+See also https://github.com/mozilla/rust/issues/6023.
+
+[1]: https://gist.github.com/nikomatsakis/11179747
+
+# Detailed design
+
+The primary change here is that, when integer type inference fails,
+the compiler will emit an error instead of assigning the value the
+type `int`.
+
+This change alone will cause a fair bit of existing code to be
+unable to type check because of lack of constraints. To add more
+constraints and increase likelihood of unification, we 'tighten'
+up what kinds of integers are required in some situations:
+
+* Array repeat counts must be uint (`[expr, .. count]`)
+* << and >> require uint when shifting integral types
+
+Finally, inference for `as` will be modified to track the types
+a value is being cast *to* for cases where the value being cast
+is unconstrained, like `0 as u8`.
+
+# Drawbacks
+
+This will force users to cast somewhat more often. In particular,
+ranges of unsigned ints may need to be type-hinted:
+
+```
+for _ in range(0u, 10) { }
+```
+
+# Alternatives
+
+Do none of this.
+
+# Unresolved questions
+
+* If we're putting new restrictions on shift operators, should we
+  change the traits, or just make the primitives special?
+
+There is some question about how to treat enum discriminants:
+
+```
+enum Color { Red = 0, Green = 1, Blue = 2 }
+```
+
+Currently these default to `int`, but we need to change the
+behavior. Niko suggests just making discriminants always `int`, but
+how does that interact with `repr`?
\ No newline at end of file

From c809a95280626b477993f0bfd85517502edf5dd6 Mon Sep 17 00:00:00 2001
From: Brian Anderson <banderson@mozilla.com>
Date: Tue, 17 Jun 2014 17:58:38 -0700
Subject: [PATCH 2/2] Add final description of enum treatment

---
 active/0000-rm-integer-fallback.md | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/active/0000-rm-integer-fallback.md b/active/0000-rm-integer-fallback.md
index 5c4d63ca369..886e488bcbe 100644
--- a/active/0000-rm-integer-fallback.md
+++ b/active/0000-rm-integer-fallback.md
@@ -44,9 +44,21 @@ Finally, inference for `as` will be modified to track the types
 a value is being cast *to* for cases where the value being cast
 is unconstrained, like `0 as u8`.
 
+Treatment of enum discriminants will need to change:
+
+```
+enum Color { Red = 0, Green = 1, Blue = 2 }
+```
+
+Currently, an unsuffixed integer defaults to `int`. Instead, we will
+only require enum descriminants primitive integers of unspecified
+type; assigning an integer to an enum will behave as if casting from
+from the type of the integer to an unsigned integer with the size of
+the enum discriminant.
+
 # Drawbacks
 
-This will force users to cast somewhat more often. In particular,
+This will force users to type hint somewhat more often. In particular,
 ranges of unsigned ints may need to be type-hinted:
 
 ```
@@ -61,13 +73,3 @@ Do none of this.
 
 * If we're putting new restrictions on shift operators, should we
   change the traits, or just make the primitives special?
-
-There is some question about how to treat enum discriminants:
-
-```
-enum Color { Red = 0, Green = 1, Blue = 2 }
-```
-
-Currently these default to `int`, but we need to change the
-behavior. Niko suggests just making discriminants always `int`, but
-how does that interact with `repr`?
\ No newline at end of file