Closed Eswcvlad closed 4 months ago
In all these cases, I lean toward a more strict interpretation of parameters rather than inferring behaviors from unexpected values. It's also simpler to implement.
contains("", "")
should return true
find()
We should document that it wants start >= 0
. Negative values should throw an error. I don't see a real-world scenario where allowing negatives is useful. More likely just confusing.
find("", "bab", X)
returning 0, regardless of the value ofX
.
If X
is greater than the length of the source, this should return null
left()
,mid()
,replace()
,search()
I'd prefer we be strict that integer parameters are >= 0
, rather than infer behaviors that are really unlikely to be leveraged by users
replace()
: if startPos is too big...
Then we shouldn't do any replacement -- as opposed to the current behavior where we append the string
search("*", "")
I think returning []
is correct. *
can be zero characters.
There is a quote missing ..
thanks!
Seems like there are some outside of BMP issues
Hmm. Yes there are. Bummer. it really means that the implementation likely can't leverage regex
search("*", "")
I think returning
[]
is correct.*
can be zero characters.
Well, yes, that's why I would expect [0, ""]
here :) . Similarly, if find("", "") -> 0
, then you would expect search("", "") -> [0, ""]
and same for search("*", "")
, which is a superset of the previous call.
Agreed on everything else.
I would expect
[0, ""]
... forsearch("*", "")
Hmm. Given: =SEARCH("*", "")
and =SEARCH("", "")
Excel fails to find a match in either case.
I suspect the general rule is that we never find anything in an empty string.
Oh, it is from OpenFormula. I assumed it was based on glob/regex... There you can find empty string in anything, usually.
Cleaning up the remaining items from this list.
substitute()
the 1-based which
parameter looked odd, so I will make it zero-basedfind()
is searching for an empty string, we'll allow an empty string to be found at any position -- including the end, but past the end we'll return null.@JohnBrinkman Do we leave search
with the empty string case as is? Just want to confirm.
Btw, I've did some checking, and it looks like there are corner case differences in OpenFormula implementations as well. In Excel =SEARCH("", "AB")
is 1
, but in LibreOffice Calc =SEARCH(""; "AB")
is #VALUE!
.
Most of this is not that important (expect for the
search
ones, those are pretty scary) and mostly related to the implementation.contains
contains("", "") -> false
, which looks unexpected. In most languages this would betrue
. It is also inconsistent, as at the same timefind("", "") -> 0
endsWith("", "") -> true
startsWith("", "") -> true
find
find
returns pretty odd results, whenstart
is negative:find("a", "bab", -1) -> -1
find("a", "bab", -2) -> -2
find("a", "bab", -3) -> -2
find("a", "bab", -4) -> -4
Maybe using the JS rule of clamping it to 0 would make sense here?
Another case would be
find("", "bab", X)
returning0
, regardless of the value ofX
. It seems odd, that it would return a value, less thanX
.JS rules for this seems a bit odd in a different way, as it doesn't return -1, if start is greater than string length.... Compared to behavior in Python, C++, ...
left
It is not specified in the spec what happens, if
elements
is negative. Maybe copy fromright
(i.e. return null) for consistency?mid
It is not specified in the spec what happens, if
startPos
orlength
is negative. Forlength
behavior now is pretty weird:mid("Fluid Flow", 0, -2) -> "Fluid Fl"
There is a quote missing in the example:
mid("Fluid Flow, 20, 5)
replace
It is not specified in the spec what happens, if
startPos
orlength
is negative. Also not clear, what should happen, ifstartPos
is too big.search
Similar to contains,
search("", "") -> []
andsearch("*", "") -> []
which is not expected with glob.On the other side,
search("", "012", 10) -> [10, ""]
, which is past the string end.Seems like there are some outside of BMP issues, as
search("A", "🙂A🙃") -> [2, "A"]
, instead of the expected[1, "A"]
.Regular expression based implementation is leaking, as
search("\\d", "A1B2C3") -> [1, "1"]
. I.e. beside globs, regular expression meta classes also works.Negative
startPos
is not mentioned in the spec and in the implementation it leads to some very weird results...search("A?", "B1-C3-A3", -8) -> [-2,"A3"]
As withfind
I would propose to just clamp negative values to 0.