Then what should return an array without any entry if not an error and not en empty string?
As I understand it, Xojo abstracts us from seeing “nil strings”. Perhaps they could be internally, in the framework, but for us and the “available language”, a “nil string” will always be an empty (“”) string (or perhaps a chr(0) one), but always not comparable to nil.
Therefore, returning a “nil array” hardly makes sense, IMO.
Well, I tried this:
Var dix As Dictionary, str() as String
dix = Nil
str = Nil
str.add ("wiggy")
which compiles but you get a NilException on the .Add().
str shows up as an empty array until it has Nil assigned to it.
Ok, that’s expected as you defined the string array with (), which means an empty array.
Just note I referred to an empty string, not an empty string array (or perhaps I missed your point?).
The first choice is often the right one 
I’d like all Xojo functions to be named like that!
Sorry, I can‘t see any logic here. Why do you expect an item in the array when there‘s nothing to split? The string contains nothing and the array contains nothing too; perfect match.
If the split function would return ‘nil’ instead of an empty array, that would be a bug.
And as Thom already wrote, it‘s too late to change this behaviour.
Because nothing is still a string ?? Its not nil, its empty string.
Just like if you got nothing in between then I still want to get element number 2 if its empty string.
1 Like
Only from the Xojo version that implement the change and forward.
This was already done wthout fear with API2…
Just add a WARNING in the Release Note entry and prepare yourself to answer questions here.
Of course, if you judge the cjange s worth that cost.
Yea I think it is very rare case that it will brake anything, same as it is rare case that this causes “gotya” issue right now. In the application I had there it had been there for 2 years before the case came up.
So it is a bit of a case if it is not changed then users can and will have such issues in their applications. And if its fixed then potentially some might need to look at their code though i would imagine its also very rare case there.
No it wasn’t. Nothing about API 1 was changed.
The bottom line seams to be “Chances are Xojo will not modify Split()”. But we developers can. Just write your own Split() function with the same signature, call it Split2(), and edit all calls to Split() to become Split2().
In Split2(), you may implement the function the way it fits you, buy providing ways to flag empty strings and other nonacceptable situations.
How about that ?
2 Likes
No API2 ? I am stoned !
That’s not what Tim wrote.
API2 was indeed created. But API1 didn’t change (in that regard).
Yes, I understand, but that is not what I wrote too 
To be crystal clear: one change here and there is OK (for me). But a so massive change at once…
You wrote:
Which I understand as “There’s no API2? Amazing!”.
What did you mean, if not this?
Breaking code was already done: look at API2 !
How does API2 break API1 code?
When you check your code with Xojo 2021r1.1 and go back to a pre API2 version but have added API2 code between (by error).
But I do not meant that at all.
I anwered to “this will broke code” by a change in Xojo 2021r2 or later. And I was saying that one change like that is nothing compared to API 2 changes.
One more taker ?
Yes
By saying “No API2? I am stoned!”? Strange way to say it.
split("|||", “|”) returns ["", “”, “”, “”] ← not controversial
split("||", “|”) returns ["", “”, “”] ← not controversial
split("|", “|”) returns ["", “”] ← not controversial
split("", “|”) returns [""] ← controversial for some reason
3 Likes