Skip to content

reworded and clarified example code #2611

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.

Sign up for GitHub

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

Closed
cPlayIt wants to merge 3 commits into from
Closed

reworded and clarified example code #2611

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5c06bed
reworded and clarified example code
cPlayIt Jun 19, 2021
ddd4650
clarified example code and description.
cPlayIt Jun 19, 2021
fe86405
reworded
cPlayIt Jun 19, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 7 additions & 6 deletions doc/modules/language-guide/pages/pattern-matching.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,23 +23,24 @@ func fullName({ first : Text; mid : Text; last : Text }) : Text {

The input is an (anonymous) object, which is deconstructed into its three `Text` fields, whose values are bound to the identifiers `first`, `mid` and `last`. They can be freely used in the block that forms the body of the function. Above we have resorted to _name punning_ for object field patterns, their general form allows the binding identifier to be distinct from the field name, as in `mid = middle_name : Text`.

You can also use pattern matching to search for _literal patterns_, which look just like literal constants. Literal patterns are especially useful in `switch` expressions because they can cause the current pattern match to _fail_, and thus start to match the next pattern. For example:
You can also use pattern matching to declare _literal patterns_, which look just like literal constants. Literal patterns are especially useful in `switch` expressions because they can cause the current pattern match to _fail_, and thus start to match the next pattern. For example:

[source, motoko]
....
switch ("Adrienne", #female) {
case (name, #female) { "It's a girl! " # name };
case (name, _) { name # ", a boy!" };
case (name, #female) { name # " is a girl!" };
case (name, #male) { name # " is a boy!" };
case (name, _) { name # ", is a human!" };
}
....

will match the first `case` clause (because binding to the identifier `name` cannot fail and the shorthand variant literal `#Female` compares as equal), and evaluate to `"It's a girl! Adrienne"`. The second clause showcases the _wildcard_ pattern `_`. It cannot fail, but won't bind any identifier.
will match the first `case` clause (because binding to the identifier `name` cannot fail and the shorthand variant literal `#Female` compares as equal), and evaluate to `"Adrienne is a girl!"`. The last clause showcases the _wildcard_ pattern `_`. It cannot fail, but won't bind any identifier.

The last kind of pattern is the `or`-pattern. As their name suggests, these are two or more patterns that are separated by the keyword `or`. Each of the sub-patterns must bind to the same set of identifiers, and is matched from left-to-right. An `or`-pattern fails when its rightmost sub-pattern fails.
The last type of pattern is the `or` pattern. As their name suggests, these are two or more patterns that are separated by the keyword `or`. Each of the sub-patterns must bind to the same set of identifiers, and is matched from left-to-right. An `or` pattern fails when its rightmost sub-pattern fails.

.The following table summarises the different ways of pattern matching.
|===
|pattern kind |examples |appears in |can fail |remarks
|pattern type |example(s) |context |can fail |remarks

|literal
|`null`, `42`, `()`, `"Hi"`
Expand Down