An empty string is a string containing no elements, regardless of the delimiter, and that’s what Split and ToArray return. This is exactly the behavior I would have expected. If you have a bottle crate with no bottles, the number of bottles is zero – it would be quite odd to claim it did contain one empty bottle.
Split has had this behaviour probably for as long as the Split function has existed. The oldest version of Xojo that I use is 2016v3, and it behaves the same way. So, as others have mentioned, changing how it works would likely break a lot of code. The one line workaround that I gave above solved the problem for me in all of my applications.
One possible fix, that is compatible, is for Xojo to add an optional boolean parameter to the Split function. If it’s false or missing, then it continues to work the same way as before. If it’s present and set to true, then it always returns an array with at least one element.
every developing language have it quirks.
but we are not speaking about a bottle crate.
its more like a (empty bottle) beside (other empty of filled bottle) and between is a book or not. you have 2 bottles apart or 2 bottles together. this bottles can not disappear.
empty string is a empty bottle somehow.
so “”+"" = “” ← the magic transform into one big empty
“”+","+"" = “”,""
and a feature request will end by design
My opinion,
Empty string “” is for me really EMPTY. There is nothing in this string.
So it can not give back anything when splitted (-1 seems correct for me)
String " " is a string including only a space and this will return one element in the array indexed 0.
Before doing the split, perhaps first do a ‘String.IsEmpty’ test.
Also, if you leave off the delimiter, Split returns an array of characters. “” contains no characters, so what should it return? An empty array seems like the correct value.
Where you have the wrong end of the stick is that “” is not nothing but essentially has a NULL character.
One of the biggest breakthroughs in Mathematics was the realisation that 0 is not simply nothing, but a number in its own right. In the same way “” is not nothing but an empty string.
Your view is equivalent to declaring 0 is nothing so we should disregard it and only do Maths with “real” numbers.
In the same way as 0 is not simply nothing but its own number, an empty string it not “nothing” but still a string.
“” <> chr(0) (null char) <> " " (chr(32)). The first contains zero characters, the other two contain one character each. Standard string comparison will treat them as different from each other.
Stepping back, I will say that there are valid arguments to be made for both results - empty array vs. array with one element, an empty string. But the current implementation goes way back to the beginning of RealBasic. As such, it’s not so much a bug as a feature/change request. This would be a good time to request it, as Xojo is making a lot of changes to functionality.
Honestly, it’s too late already. The change should have been made with API2’s String.FromArray. Now it’s too late.
I think maybe that could be deprecated in favor of a more intuitive .Join method on string arrays, but Xojo has seemed to fall on the side of an empty string being special, so they probably don’t want to change it.
Dim MyTab(-1) as String
MessageBox "'" + String.FromArray(MyTab) + "'"
MyTab.Add ""
MessageBox "'" + String.FromArray(MyTab) + "'"
The result is an empty string ‘’ in both case.
Then what should be the reverse splitting an empty string?
I notice that doing, on an empty array (LastIndex = -1) : MyTab.IndexOf("re")
return -1.
One solution would be to return an error (Nil objection or OutOfBound or …). As Join an empty Array which could return an error too.
A folderitem which is Nil return an error when we do MyFolderItem.Child(“MyName”).
Then to be clear, an empty Array could be considered as Nil then no mistake of what we expect between working on an empty array / working on an array of empty string.