add meeting notes

Author: lcnr

meetings/2021.03.02-near-future-stabilizations.md

@@ -0,0 +1,38 @@
+# cg meeting 2021-03-02
+
+What can we stabilize without having to supply generic params to anon consts?
+
+- loosen the ty/const param ordering restriction
+- const param defaults
+    - const evaluatable bounds?
+        - start out by not supplying any generic params?
+    - should we allow `const N: usize, const M: usize = N`,
+        - requires the hack already used for const args
+    - seems fine, requires stabilization report
+        - mention lazy norm backcompat
+- const param types
+     - what types are allowed? 
+        - structural match
+        - do we require explicit opt in? [pcg issue](https://github.com/rust-lang/project-const-generics/issues/6)
+            - consensus seems to be yes
+            - open question: are there worrying interactions with structural match?
+    - without val trees
+        - c like enums? seems quite helpful and should already work
+            - concern: might feel a bit arbitrary to users [msg](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/meeting.202021-03-02/near/228445035)
+    - val trees :sparkles: 
+    - generic param types
+        - requires changes to `WithOptConstParam`
+    - what types are allowed? 
+        - structural match
+        - do we require explicit opt in? [pcg issue](https://github.com/rust-lang/project-const-generics/issues/6)
+- `_` as array len and const argument
+    - rn always gets interpreted as a type
+    - add `hir::GenericArg::Infer`
+    - should we go ahead and solve this for paths/unit(`()`) at the same time?
+        - not neccessarily, if only `_` is easier
+# Not talked about during the meeting
+
+- inline consts
+    - typeck together with their parent
+    - const evaluatable bounds?
+        - require them to not depend on params after typeck for now?