Merge pull request #21 from lcnr/uwu-new-book

uwu a list of all the issues

SUMMARY.md

@@ -17,9 +17,14 @@
     - [📅 Roadmap for 2021](./vision/roadmap.md)
     - [❓How to vision doc](./vision/how_to_vision_doc.md) 
 - [🔍 Meetings](./meetings/README.md)
-- [📚 Design Documents](./design-docs/README.md)
-    - [Anon const substs](./design-docs/anon-const-substs.md)
-    - [Const eval requirements](./design-docs/const-eval-requirements.md)
-    - [Generic const param types](./design-docs/generic-const-param-types.md)
+- [📚 Design](./design/README.md)
+    - [❗ Constraining generic parameters](./design/constraining-generic-parameters.md)
+    - [❗⚖️🔄 Generic const parameter types](./design/generic-const-param-types.md)
+    - [❗🔙 Restrictions on const evaluation](./design/const-eval-requirements.md)
+    - [❗🔙 ⚖️ Structural equality](./design/structural-equality.md)
+    - [❗⚖️ Valid const parameter types](./design/valid-const-parameter-types.md)
+    - [❗ Valtrees](./design/valtrees.md)
+    - [❔ Exhaustiveness](./design/exhaustiveness.md)
+    - [❔🔙 Functions as const parameters](./design/functions-as-const-parameters.md)
 - [✏️ Draft RFCs](./draft-rfcs/README.md)
 s

design/README.md

@@ -0,0 +1,86 @@
+# 📚 Design
+
+For an explanation of how const generics currently works in the compiler,
+also check out the [rustc-dev-guide](https://rustc-dev-guide.rust-lang.org/constants.html).
+
+
+Const generics has quite a few deep rooted issues and design challenges.
+In this document we try to highlight some specific topics which are fairly
+pervasive while working on this feature.
+
+### 🔙 Backwards compatability
+
+Rust was not design with const generics in mind, and we've also made
+some unfortunate decisions even after work on const generics started.
+
+Future extensions of const generics must not cause substantial breakage
+to existing code, or if they do, this breakage has to be contained somehow.
+A possible solution to many such changes are editions.
+
+### ⚖️ No perfect solution
+
+There isn't just one *perfect* version of const generics we are working towards.
+Instead there are a lot of major and minor tradeoffs between learnability, expressiveness,
+implementation complexity and many other factors. As we can't perfectly tell how
+const generics will be used in the future, making these decisions can be especially
+hard. For any such issues we should try to reach out to the wider community before
+coming to a final conclusion.
+
+### 🔄 The query system
+
+Const generics mixes evaluation with typechecking which very quickly reaches the edge
+of what is possible with the query system. It might make sense to look at these issues in
+unison and consider whether there are some more fundamental changes to the compiler which
+provide a better solution to them instead of [adding more hacks](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.WithOptConstParam.html).
+
+### ❔ Optional extensions
+
+There are a lot of things which are nice to have but not strictly necessary or maybe not even
+desirable. This means that decisions which prevents them may still be the correct ones,
+i.e. these are not strictly a blocking concern.
+We should still try to find alternatives before blocking these though.
+
+## Const parameter types ([`adt_const_params`](https://github.com/rust-lang/rust/issues/95174))
+
+On stable, only integers, `bool`, and `char` is allowed as the type of const parameters.
+We want to extend this to more types in the future.
+```rust
+struct NamedType<const NAME: &'static str> { ... }
+```
+
+Additionally, we want to support generic const parameter types and must not stabilize anything
+which prevents the addition of that in the future.
+```rust
+struct WithGenericArray<T, const N: usize, const ARRAY: [T; N]> { ... }
+```
+
+This feature interacts with the following topics:
+
+- [❗ Constraining generic parameters](./design/constraining-generic-parameters.html)
+- [❗🔙 ⚖️ Structural equality](./design/structural-equality.html)
+- [❗⚖️ Valid const parameter types](./design/valid-const-parameter-types.html)
+- [❗ Valtrees](./design/valtrees.html)
+- [❗⚖️🔄 Generic const parameter types](./design/generic-const-param-types.html)
+- [❔ Exhaustiveness](./design/exhaustiveness.html)
+- [❔🔙 Functions as const parameters](./design/functions-as-const-parameters.html)
+
+## Generic constants in the type system ([`generic_const_exprs`](https://github.com/rust-lang/rust/issues/76560))
+
+- ❗🔙 🔄 Unused substs
+- ❗🔄 Self referential where clauses
+- ❗🔄 Evaluation without first checking where-clauses
+### Unifying generic constants
+
+- [❗🔙 Restrictions on const evaluation](./design/const-eval-requirements.html)
+- ❗ Do not leak implementation details
+- ❗ Splitting constants during unification
+- [❗ Constraining generic parameters](./design/constraining-generic-parameters.html)
+- ❔⚖️ Extending unification logic
+
+### Const evaluatable bounds
+
+ALL OF THIS
+
+## Repeat length backcompatability lint ([`const_evaluatable_unchecked`](https://github.com/rust-lang/rust/issues/76200))
+
+close this or wait until it's possible on stable.

design/const-eval-requirements.md

@@ -0,0 +1,22 @@
+# ❗🔙 Restrictions on const evaluation
+
+For generic constants in the type system to be sound, const evaluation must
+not be able to differentiate between values considered equal by the type system.
+Const evaluation must also be fully deterministic and must not depend on any external state
+when used in the type system.
+
+## Floats
+
+Using floats during CTFE is fully determinstic. So using
+them inside of the type system is fine. CTFE can however
+produce different results than what would happen on real hardware,
+but this is not a concern for const generics.
+
+## Dealing with references and allocations
+
+Other sources of non-determinism are allocations. This non-determinism
+must however not be observed during const-evaluation (TODO: link to const-eval).
+
+Any references used in a constant are considered equal if their targets are equal, which is also determistic.
+This is needed by [valtrees](./design/valtrees.html). The specific design of valtrees also adds some other
+additional constraints to const evaluation which are listed on its page.

design/constraining-generic-parameters.md

@@ -0,0 +1,27 @@
+# ❗ Constraining generic parameters
+
+Given an impl, the compiler has to be able to decide the generic arguments used by that impl.
+Consider the following snippet:
+
+```rust
+struct Weird<const N: usize>;
+
+impl<const A: usize, const B: usize> Weird<{ A + B }> {
+    fn returns_a() -> usize {
+        A
+    }
+}
+```
+
+When calling `Weird::<3>::returns_a()`, there is no way to restrict the generic parameters `A` or `B` so this has to error.
+If a generic parameter is used by an injective expression, then we should allow this. The most relevant case here are
+constructors:
+```rust
+struct UsesOption<const N: Option<usize>>;
+impl<const N: usize> UsesOption<{ Some(N) }> {}
+```
+Here it is very clear which `N` we should use given `UsesOption::<{ Some(3) }>`.
+
+## Current status
+
+**Blocked**: Before making any decisions here we should first figure out [structural equality](./design/structural-equality.md)

design/exhaustiveness.md

@@ -0,0 +1,15 @@
+# ❔ Exhaustiveness
+
+Whether we want to be able to unify different partial impls to consider them exhaustive.
+
+```rust
+trait ForBool<const B: bool> {}
+
+impl ForBool<true> for u8 {}
+impl ForBool<false> for u8 {}
+// Does `for<const B: bool> u8: ForBool<B>` hold?
+```
+
+## Status
+
+**Idle**: While not blocked, it may make sense to wait until we are able to [constrain generic parameters](./design/constraining-generic-parameters.html).

design/functions-as-const-parameters.md

@@ -0,0 +1,17 @@
+# ❔🔙 Functions as const parameters
+
+**[project-const-generics#7](https://github.com/rust-lang/project-const-generics/issues/7)**
+
+It would be nice to allow function pointers as const parameter types.
+
+```rust
+fn foo<const N: fn() -> usize>() {}
+```
+
+While they do have a sensible definition of structural equality at compile time,
+comparing them is not deterministic at runtime. This behavior might be fairly surprising,
+so it might be better to not allow this.
+
+## Current status
+
+**Planning/Blocked**: needs `generic_const_exprs` to be closer to stable before it makes sense to start working on this.

design-docs/generic-const-param-types.md → design/generic-const-param-types.md

@@ -1,4 +1,4 @@
-# Generic const param types
+# ❗⚖️🔄 Generic const parameter types
 
 We want to support the types of const parameters
 to depend on other generic parameters.
@@ -33,4 +33,8 @@ break stuff.
 
 Potential dangers include partially resolved types and projections.
 
-[WithOptConstParam]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.WithOptConstParam.html
+[WithOptConstParam]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.WithOptConstParam.html
+
+## Status
+
+**Blocked**: We should first stabilize `feature(adt_const_params)`.

design/structural-equality.md

@@ -0,0 +1,7 @@
+# ❗🔙 ⚖️ Structural equality
+
+We have to figure out which values and types can be sensibly compared at compile time.
+
+## Status
+
+**In progress**: [lcnr](https://github.com/lcnr/) is working on this.

design/valid-const-parameter-types.md

@@ -0,0 +1,9 @@
+# ❗⚖️ Valid const parameter types
+
+**[project-const-generics#6](https://github.com/rust-lang/project-const-generics/issues/6)**
+
+We have to decide which types may be used as a const parameter and whether there needs to be explicit opt-in.
+
+## Status
+
+**Blocked**: Waiting on [structural equality](./design/structural-equality.html).

design/valtrees.md

@@ -0,0 +1,11 @@
+# ❗ Valtrees
+
+A new representation for `ty::Const`.
+
+## ❗ Figure out how they interact with references wrt padding
+
+**[project-const-generics#20](https://github.com/rust-lang/project-const-generics/issues/20)**
+
+## Status
+
+**In Progress**: [b-naber](https://github.com/rust-lang/project-const-generics/issues/20) is working on this.