Updated documentation
This commit is contained in:
@@ -100,7 +100,7 @@ Numeric ranges:
|
|||||||
The engine and the API differ from [regexp] in a number of ways, some of them very subtle.
|
The engine and the API differ from [regexp] in a number of ways, some of them very subtle.
|
||||||
The key differences are mentioned below.
|
The key differences are mentioned below.
|
||||||
|
|
||||||
Greediness:
|
1. Greediness:
|
||||||
|
|
||||||
This engine does not support non-greedy operators. All operators are always greedy in nature, and will try
|
This engine does not support non-greedy operators. All operators are always greedy in nature, and will try
|
||||||
to match as much as they can, while still allowing for a successful match. For example, given the regex:
|
to match as much as they can, while still allowing for a successful match. For example, given the regex:
|
||||||
@@ -116,7 +116,7 @@ Another, more subtle example is the following regex:
|
|||||||
While the stdlib implementation (and most other engines) will prefer matching the first item of the alternation,
|
While the stdlib implementation (and most other engines) will prefer matching the first item of the alternation,
|
||||||
this engine will _always_ go for the longest possible match, regardless of the order of the alternation.
|
this engine will _always_ go for the longest possible match, regardless of the order of the alternation.
|
||||||
|
|
||||||
Byte-slices and runes:
|
2. Byte-slices and runes:
|
||||||
|
|
||||||
My engine does not support byte-slices. When a matching function receives a string, it converts it into a
|
My engine does not support byte-slices. When a matching function receives a string, it converts it into a
|
||||||
rune-slice to iterate through it. While this has some space overhead, the convenience of built-in unicode
|
rune-slice to iterate through it. While this has some space overhead, the convenience of built-in unicode
|
||||||
|
Reference in New Issue
Block a user