Feedback Case Number: 64915
String Split in API 2 behaves wrong if you try to Split empty string:
var str as String = “”
var result() as String = str.Split(",")
MessageBox result.LastIndex.ToString()
You would expect this to return one element (zero in the message box), but message box puts out -1.
Split should always return at least one part, if no delimiter is found then the one part returned is the original string even if it is empty string.
The documentation says that Split works the same as ToArray, what happens if you try it ?
Split (the deprecated one) seems to work the same way, so I’m not sure this will be considered a bug, but it’s definitely not what I’d have expected.
ToArray also gives -1. Again, not what I’d have expected.
I would say if they do not consider it a bug then there is something very much wrong at Xojo. Since there is no way in hell anyone can tell me that they sat down and decided it should be like this. Nor would it benefit any user, as is then it only gives users crashes they did not expect.
Remember also empty string is still a string, like if you have text like “1,2,3” if empty string was supposed to return no result, then what about the second element here ? should it be skipped ?
No of course it should not since its still a element of empty string.
I’d argue that it’s not a bug. There is no return if the string is empty, but if you set str’s value to “test”, then you do get a return with one array element (“test”).
How about you look at any other framework in the world and see what split returns there,
And also if you split “1,2,3” are you then going to return 2 as second element ? by your logic then you would have to do that. (should be 2 commas after 1, it d oes not show it here)
No. 0 is the first element in an array. result(1) would be 2. With the string “,2,” supplied, I would still expect result(1) to be 2. I don’t think passing an empty string should return an array with a single empty element. Decent way to validate input without comparing str to “”.
Just my opinion.
Its not drawing what I typed, I typed 1 comma comma 2 comma 3 comma, so you have empty string element in the middle
Right. But you’re not passing an entirely empty dataset sans delimiters.
Same logic still applies, you think evry other framework in the world did not have it correct for a reason ?, Why crash the user with the surprise for no reason ?
Arguing clear bugs for no good reason does not do Xojo any good you know.
I’m not arguing a clear bug. I’m saying that I think the current behavior won’t be considered a bug in Xojo, and I would understand. Not everything in Xojo will equate to every other language, just as there are differences in the way those other languages do things.
I ran into this problem a couple of years ago, with the old API, which behaves the same way. At first I thought that it didn’t make any sense to do it this way, but thinking about it some more, I could see valid reasons for doing it either way. Anyway, if you want it always to return an array with at least one element, it’s a simple one line addition.
var str as String = ""
var result() as String = str.Split(",")
if result.LastIndex=-1 then result.add ""Edit: Got my API-1 and API-2 array commands confused. Fixed now, I think.
I think it’s definitely a bug. If you pass it a string that does not include the delimiter, you get back a single element array with the passed string. That should be the end of the discussion. This is how most languages behave. The fact that the passed string is empty is irrelevant because it’s still a string which meets the “no delimiter” criteria. I don’t see why an empty string should be special cased.
I can see the merits of doing it either way, and the logic that probably went in to the current implementation. For instance, when I Split, I’m not getting back a String but I am getting back an array. Nil String in = Nil Array out, according to the current functionality. I’ll be watching where this one goes as it’s definitely one of those cases that’s worth seeing what direction the team goes with.
I did verify that this behavior is not new as it also appears as far back as 2017r3 (I didn’t test earlier than that).
Just to add some specific examples for the team to consider:
TypeScript
var str : string = ""
var result : Array<string> = str.split(",")
Result is an array with an empty string as the only element.
[""]
JavaScript
var str = "";
var result = str.split(",");
Result is an empty string.
Since changing this behaviour is likely to break existing code, how about a new function.
Something similar to ‘SplitList’ maybe?
That’s better than ‘SplitDelimitedCharacterSequenceIntoFieldsBeforeDumpingIntoArray’ which was my first choice! 
Going to add an extension method to my private library of goodies I think!
I would suggest that Split remain unaltered and String.ToArray match the experience of other languages.
Its very unlikely to brake users code since if they were not checking the result, then they would have crashed if getting for any reason empty string and then looped over the array.
And if they were checking the result then likely that code would catch the change.
Surely not. If you loop over the results and result.LastIndex is -1, then your loop is skipped.
That is good point, but I did have crash in a loop due to this bug. I will need to check that code again when I come home tonight. Makes little sense that it would even enter the loop as you say.