Imagine that melody had predefined patterns like
<date> matching a valid date,<datetime> matching a valid date and time,<float> matches a floating-point number, supporting scientific notation,<unixtime> matches the UNIX timestamp,<url> matches a valid URL,<ip> matches an IP address,
etc.
In such a case, it would offer not only a clear, easy-to-read, and maintain syntax, but also it would offer to remove a lot of boilerplate code from common expressions.
The hard part is that while for some of those (<unixtime> or <float>), the regexes would be simple, for others, they would not and there are whole StackOverflow threads on which regex is the more correct to match them, so the patterns would obviously be opinionated.
Looking at the code, adding them seems rather straightforward. Alternatively, such patterns could be provided as external libraries, but there is no such functionality.
Imagine that melody had predefined patterns like
<date>matching a valid date,<datetime>matching a valid date and time,<float>matches a floating-point number, supporting scientific notation,<unixtime>matches the UNIX timestamp,<url>matches a valid URL,<ip>matches an IP address,etc.
In such a case, it would offer not only a clear, easy-to-read, and maintain syntax, but also it would offer to remove a lot of boilerplate code from common expressions.
The hard part is that while for some of those (
<unixtime>or<float>), the regexes would be simple, for others, they would not and there are whole StackOverflow threads on which regex is the more correct to match them, so the patterns would obviously be opinionated.Looking at the code, adding them seems rather straightforward. Alternatively, such patterns could be provided as external libraries, but there is no such functionality.