-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Quest] switch statement as first class citizen #14
Comments
Some thoughts on more elaborate visual constructions involving nested regions: When looking at how pattern matching is usually have two parts:
In the match pattern you can also do deconstructing/mapping of the value being matched into other values that are the input for the corresponding expression. Let's say there was a match region containing case regions which each has two regions/parts - condition and expression, the condition decides if the expression will run.
Having a condition region above an expression region makes sense in a data flow way (data flowing down) but might make it harder/more cluttered to make links into the expression part. A case region with a condition part on the left and expression on the right would make it easier to cleanly have incoming links but make everything wider. (pictures needed) Somehow my above screenshot holds up quite well when trying to think of custom visual forms as long as can avoid needless execution of the node graph. In F# you also have exhaustive pattern matching which will warn you if your cases don't cover all of the input space if you don't have a default/wildcard. |
As switch-case constructs are a common and useful coding pattern, a way to have those represented in the language would be nice.
Imho this is mostly a quest on finding a good visual representation for that.
This is a way to patch such a pattern today, without such a language feature, but it is a) tedious and b) missing constructs like
default:
,goto
.when
(pattern matching)i'd say, one could work around all those things today with a chain of if's, but the patch gets more unreadable with increased complexity.
also, in C# 8.0 there's this new switch expression syntax which might be of interest in that context.
The text was updated successfully, but these errors were encountered: