Replace em dashes with en dashes

Author: TolikPylypchuk

docs/articles/expressions.md

@@ -13,10 +13,10 @@ A match expression can be created using the `Create` methods of the static class
 ### Adding Cases
 
 The `Match` classes include `Case` methods which are used to add a pattern and a function which is executed if the match
-is successful. Match expressions are immutable — `Case` methods return new match expressions; they do not affect the
+is successful. Match expressions are immutable – `Case` methods return new match expressions; they do not affect the
 ones on which they are called.
 
-`Case` methods are generic — they also contain information about the pattern's transformation type. Match expressions
+`Case` methods are generic – they also contain information about the pattern's transformation type. Match expressions
 can contain patterns of arbitrary transformation types without knowing about these types.
 
 ### Executing Match Expressions
@@ -31,7 +31,7 @@ which executes the match expression in the non-strict mode. It returns `MatchRes
 not be present.
 
 In the `Match<TInput>` class, the `ExecuteOn` method doesn't return anything, and also throws a `MatchException` if the
-match wasn't successful. This class also contains the `ExecuteNonStrict` method — it returns a boolean value which
+match wasn't successful. This class also contains the `ExecuteNonStrict` method – it returns a boolean value which
 indicates whether the match was successful and doesn't throw an exception if it wasn't.
 
 The `ToFunction` method and its variations are also available. They return a function which, when called, will execute
@@ -55,7 +55,7 @@ the expression will stop at this pattern and not go any further.
 `Match.Create` is also overloaded to take the default fall-through behavior.
 
 Matching with fall-through is lazy, i.e., it returns an `IEnumerable` and is only executed when this enumerable is
-enumerated. Because matching will fall-through is lazy, it doesn't have any modes of execution — the user must decide
+enumerated. Because matching will fall-through is lazy, it doesn't have any modes of execution – the user must decide
 whether to throw an exception or not if there were no successful matches.
 
 In the `Match<TInput, TOutput>` class, the `ExecuteWithFallthrough` method returns an `IEnumerable<TOutput>` which can
@@ -129,7 +129,7 @@ less readable because the case definitions are in a different place from the act
 
 ### The Solution
 
-There is a way to create static match expressions — expressions which will be initialized only once.
+There is a way to create static match expressions – expressions which will be initialized only once.
 
 The `Match` class contains the `CreateStatic` methods which allow the creation of static match expressions. Take a look
 at the modified example:
@@ -150,7 +150,7 @@ only once, and its initialization code is in the same place as its execution poi
 
 The parameter of the build action has the type `MatchBuilder<TInput, TOutput` or `MatchBuilder<TInput>`, depending on
 which type of match expressions you are building. This type has the same methods for adding cases as the `Match` classes
-and is mutable — the methods return the same builder instance.
+and is mutable – the methods return the same builder instance.
 
 `MatchBuilder` also has the `Fallthrough` method which specifies the default fall-through behavior. But this method
 specifies fall-through behavior only for cases that are defined after it. For example:

docs/articles/patterns.md

@@ -19,11 +19,11 @@ The `Match` method actually does two things:
 - Matches the input value with the pattern and returns a successful result if the match is successful.
 - Transforms the input value. The returned result contains the transformed value if it's successful.
 
-Since options are not supported natively in C#, a custom type — [`MatchResult<T>`](results.md) — is used.
+Since options are not supported natively in C#, a custom type – [`MatchResult<T>`](results.md) – is used.
 
 The definition of patterns is similar to F#'s active patterns.
 
-Descriptions for patterns are not terribly important, but can be useful for debugging. As such, they are optional — if
+Descriptions for patterns are not terribly important, but can be useful for debugging. As such, they are optional – if
 you don't want a pattern to have a description, it should be empty. A pattern's description should never be `null`.
 
 ## Null Values
@@ -59,7 +59,7 @@ All methods for getting predefined patterns are overloaded to take a custom desc
 The `Matchmaker.Linq` namespace provides several extension methods for patterns:
 
 - `Select` maps a pattern's result value if it's successful.
-- `Pipe` creates a pattern pipeline — the result of the first pattern is the input of the second pattern.
+- `Pipe` creates a pattern pipeline – the result of the first pattern is the input of the second pattern.
 - `Cast` casts a pattern's result to a specified type. It's the same as piping a pattern to the `Type` pattern. If the
 input is `null`, then the match will fail only if the destination type is a non-nullable value type.
 - `Bind` flat-maps a pattern's result. If a pattern's result is successful, it calls the specified function and passes
@@ -70,7 +70,7 @@ result is the final result.
 the input if successful.
 - `Compose` is the same as the three methods above, but the composition operator is passed to it as well.
 - `Cached` returns a pattern which matches the same as the specified pattern but caches its results in a `null`-safe
-hash table. Every input will be matched only once — if it's matched again, the result will be taken from the cache. The
+hash table. Every input will be matched only once – if it's matched again, the result will be taken from the cache. The
 caching process is not thread-safe.
 
 All extension methods for patterns are overloaded to take a custom description.
@@ -83,9 +83,9 @@ a combination of the Reader and Maybe monads.
 ## Immutability
 
 All predefined patterns, as well as patterns returned by `CreatePattern` and extension methods, are immutable. Calling
-an extension method on a pattern returns a new pattern — the old one is unchanged.
+an extension method on a pattern returns a new pattern – the old one is unchanged.
 
-An exception is the pattern returned by the `Cached` method, which is not immutable — it holds a mutable cache. But if a
+An exception is the pattern returned by the `Cached` method, which is not immutable – it holds a mutable cache. But if a
 pattern is referentially transparent (its `Match` method always returns the same result for the same input and doesn't
 have any side effects), then the caching pattern based on it can be thought of as immutable as well, because it doesn't
 matter how many times the base pattern's `Match` method is called.
@@ -109,7 +109,7 @@ There are also overloads which take a description.
 
 If you want something more complex than a single function, you can create a class which extends the
 `Matchmaker.Patterns.Pattern<TInput, TMatchResult>` class. This is a base class for patterns, and it implements the
-`Description` property which you don't have to use if you don't want — by default the description is empty, which means
+`Description` property which you don't have to use if you don't want – by default the description is empty, which means
 that the pattern doesn't have a description.
 
 You can also implement the `IPattern<TInput, TMatchResult>` interface directly. There is no reason to do that instead of

docs/articles/why.md

@@ -4,20 +4,20 @@
 
 Pattern matching as a technique was created to make code which operates on data more succinct, clear, and readable. I
 have to say, I'm not sure this library achieves this. There's no denying that this library is cumbersome, and some
-features are kind of convoluted. You can certainly use it if you want to — it's extensively tested. But this is more of
-an experimental effort — I wanted to see how powerful pattern matching can be in C#. In this article I'll try to explain
+features are kind of convoluted. You can certainly use it if you want to – it's extensively tested. But this is more of
+an experimental effort – I wanted to see how powerful pattern matching can be in C#. In this article I'll try to explain
 some reasons behind the features of this library. This is not documentation per se, it's more of a thought piece about
 this library and a recap of its history.
 
 Also, I should note that I haven't checked out any other pattern matching libraries for C#. I'm sure there are a lot of
-them — I can't be the only one who tried to bring this technique into C#. But I wanted to create something by myself and
+them – I can't be the only one who tried to bring this technique into C#. But I wanted to create something by myself and
 not get inspired by (read: steal) features from the other libraries as I'm sure there's not actually much space for
 stretching here. Some pattern matching libraries are probably better than this one and I'm okay with it.
 
 ## Background
 
 In the end of 2017, after studying F# and functional programming, I've decided to try to bring some functional features
-into C#. I've created a small library for C# and named it [CSX — C# Extensions](https://github.com/TolikPylypchuk/CSX).
+into C#. I've created a small library for C# and named it [CSX – C# Extensions](https://github.com/TolikPylypchuk/CSX).
 I worked on this library just for the fun of it and never intended for it to be anything serious. I've long since
 stopped doing anything with it, because I've realized that it required a lot of work. My implementations of functional
 data structures were quite naive, and I've decided that I don't want to invest time into optimizing them. Moreover, I
@@ -81,8 +81,8 @@ nor reflection. And to be honest, at that moment I felt dumb, because I haven't
 solution was obvious.
 
 In this version, I've also completely uprooted the pattern hierarchy and made working with them much easier. I've also
-added some primitive caching. I'm not an expert on caching — this can be an extensive topic of research — so I can't
-say that caching in this library is great — it's okay at best. If you need more extensive or better caching of match
+added some primitive caching. I'm not an expert on caching – this can be an extensive topic of research – so I can't
+say that caching in this library is great – it's okay at best. If you need more extensive or better caching of match
 expressions, you can create an issue (or better yet, a pull request) on GitHub. I will most definitely respond and will
 do my best to implement it.
 
@@ -104,7 +104,7 @@ it would break any actual code.
 After releasing version 2.1.0, I started working on version 3.0.0 which contains 2 major additions: support for nullable
 reference types and asynchronous pattern matching. Because of those additions, the .NET Standard version had to be
 bumped to 2.1 (sorry, .NET Framework). Asynchronous pattern matching will probably not be used often. I wrote it simply
-because I can, and why not — we have asynchronous enumeration, asynchronous disposal, asynchronous almost everything,
+because I can, and why not – we have asynchronous enumeration, asynchronous disposal, asynchronous almost everything,
 so why not asynchronous pattern matching?
 
 Five years after releasing version 3.0.0, I've decided to release version 3.1.0 which adds support for .NET Standard 2.0