|
|
|
|
@ -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 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
|
|
|
|
|
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,
|
|
|
|
|
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
|
|
|
|
|
rune-slice to iterate through it. While this has some space overhead, the convenience of built-in unicode
|
|
|
|
|
|
