2 KiB
Milestone philosophy
Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!
7.3 is a bucket for next steps with pattern matching.
Non-exhaustive list
- recursive patterns
- non-null patterns
- switch expression
- negated if-condition
8.0 is for major language features
Discussion on how we get input
We should solicit problems, not just solutions
Triage
945
Could make it always prefer by-value as a tie-breaker.
933
Motivating scenarios:
- Hold on to the content variable in linked list elements
- assign one as a default and have an if overwrite it with another
Syntax! Should we be putting ref in front of the LHS, or just the RHS?
ref r = ref v; // or
r = ref v;
Not requiring ref lets us:
- Be more terse
- Work as an expression (because no expression starts with ref)
Requiring makes it syntactically clear whether you are assigning to r itself (in the ref space) or to the variable currently pointed to by r (in the value space). Also, what the hell does code mean if e.g. a ref-reassigning expression occurs as a ref or out argument?
M(out r = ref v); //What?
We'd just recommend parenthesizing the assignment, like we recommend everywhere else assignments are used as expressions.
There's a limit which is that there's no proper default, so we'd still always require initialization, picking up the lifetime from the initializer. This is a bit painful when you want it to have global lifetime (no good default to provide).
We should instead allow you to not have an initializer. We do definite assignment analysis. It has global lifetime.
ref readonly tmp = ref Get();
M(in tmp);
Annoying that there's sort of three different ways to talk about a ref readonly: ref readonly, ref and in.
Should we switch parameter to ref readonly? Allow choice.
No: Let's keep having only one way of doing it, and let's have that way be consistent with what you say at the call site.