2017-12-06 02:06:17 +01:00
|
|
|
# C# Language Design Notes for Nov 29, 2017
|
|
|
|
|
|
|
|
***Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!***
|
|
|
|
|
|
|
|
# Match expression
|
|
|
|
|
|
|
|
Current proposal:
|
|
|
|
|
|
|
|
- Infix vs prefix `switch`
|
|
|
|
- `switch` vs `match`
|
|
|
|
- curlies or parens for body
|
|
|
|
- `case` or not
|
|
|
|
- arrows?
|
|
|
|
- discards or defaults?
|
|
|
|
- also need to remember when clauses
|
|
|
|
|
|
|
|
If it's too similar to switch statements, then it sets certain expectations. If it's too different, it's not utilizing existing intuition.
|
|
|
|
|
|
|
|
Should it be a verb/command? Not many expression keywords are that (`select` is an exception, though).
|
|
|
|
|
|
|
|
`case` is heavyweight, but helps visually separate the issues.
|
|
|
|
|
|
|
|
``` c#
|
|
|
|
state = (state, action) switch (
|
|
|
|
(DoorState.Closed, Action.Open) => DoorState.Opened,
|
|
|
|
(DoorState.Opened, Action.Close) => DoorState.Closed,
|
|
|
|
(DoorState.Closed, Action.Lock) => DoorState.Locked,
|
|
|
|
(DoorState.Locked, Action.Unlock) => DoorState.Closed,
|
|
|
|
_ => state);
|
|
|
|
|
|
|
|
state = match (state, action)
|
|
|
|
{
|
|
|
|
(DoorState.Closed, Action.Open) => DoorState.Opened,
|
|
|
|
(DoorState.Opened, Action.Close) => DoorState.Closed,
|
|
|
|
(DoorState.Closed, Action.Lock) => DoorState.Locked,
|
|
|
|
(DoorState.Locked, Action.Unlock) => DoorState.Closed,
|
|
|
|
_ => state
|
|
|
|
};
|
|
|
|
|
|
|
|
state = switch (state, action)
|
|
|
|
{
|
|
|
|
case (DoorState.Closed, Action.Open): DoorState.Opened
|
|
|
|
case (DoorState.Opened, Action.Close): DoorState.Closed
|
|
|
|
case (DoorState.Closed, Action.Lock): DoorState.Locked
|
|
|
|
case (DoorState.Locked, Action.Unlock): DoorState.Closed
|
|
|
|
case _: state
|
|
|
|
};
|
|
|
|
```
|
|
|
|
|
2018-01-25 22:11:49 +01:00
|
|
|
The last one is subject to ambiguity-like situations between expression and statement `switch`.
|
2017-12-06 02:06:17 +01:00
|
|
|
|
|
|
|
We should also consider nesting of match expressions.
|
|
|
|
|
|
|
|
No matter what syntax we choose, we'll get requests for doing more things in expressions. We can live with that.
|
|
|
|
|
|
|
|
Parens look too much like a list of *expressions*.
|
|
|
|
|
|
|
|
Arrows make it look like lambda expressions.
|
|
|
|
|
|
|
|
## Decisions
|
|
|
|
|
|
|
|
We agree that we will not use the keyword `default`. You can use `_`, and in the rare case where that's defined, you can use `var _`.
|
|
|
|
|
|
|
|
We like curly braces for the grouping.
|
|
|
|
|
|
|
|
The rest is up in the air. We'll stay with the first version for now in the prototype, other than the curly braces.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Where and when can identifier appear?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Syntax for property patterns
|
|
|
|
|
|
|
|
Not urgent
|
|
|
|
|
|
|
|
``` c#
|
|
|
|
|
|
|
|
```
|