Note that the "..." operator is unary, so there is no syntax conflict when
using two floats:
```
echo 0...1; // 00.1
```
However, in the case of the ".." operator, it is assumed to be a binary
operator, so problems with grammar ambiguity may arise:
```
echo 0 ..1; // 00.1
echo 0.. 1; // 01
```
* Note: The syntax you suggest is widely used in at least Ruby (
https://ruby-doc.org/core-2.5.1/Range.html ) and CoffeeScript.
* Note: There is also a `trim`, `ltrim` and `rtrim` functions
>Суббота, 9 июля 2022, 2:56 +03:00 от mickmackusa <mickmack...@gmail.com>:
>
>I've discovered that several native string functions offer a character mask
>as a parameter.
>
>I've laid out my observations at
>https://stackoverflow.com/q/72865138/2943403
>
>In a nutshell, not all character masks offer ranges via "double dot"
>syntax. Or should I refer to ".." as the "string spread operator" to avoid
>naming conflict with "..." -- the better known "spread operator" (array
>spread operator)?
>
>Rowan/@IMSoP informed me that the current division between the haves and
>the have-nots appears to be based on the source language from which PHP
>pulled. Essentially, if from C, the double dot does not represent a range.
>https://chat.stackoverflow.com/transcript/11?m=54864842#54864842
>
>Character ranges are not yet supported for:
>- strcspn()
>- strpbrk()
>- strspn()
>
>Before I fire off an RFC, I would like to know:
>
>1. Are there any reasonable objections to consistently implementing
>character range expressions for all character masks?
>2. Are there any native functions that I did not mention my Stack Overflow
>answer?
>3. Is it true that only single-byte characters can be used in all
>scenarios? If so, must it remain that way?
>4. Is there already an official or widely-used term that I should be using
>for the two-dot operator?
>
>I should also mention that I initially considered requesting that all
>character mask parameters be named $mask (instead of $separators, $token,
>or $characters), but I later resigned to the fact that changing to a name
>that describes the texture of the string would remove the more
>vital/intuitive purpose of the string. I suppose the best that can be done
>to inform developers is to explicitly mention in the documentation when
>character range expressions are implemented and demonstrate their usage in
>an example (not just as a user comment at the bottom; this isn't In-N-Out
>Burger -- put your offerings on the frickin' menu!).
>
>mickmackusa
--
Kirill Nesmeyanov
