Am I the only one who always falls into the `"".sp...

# getting-started

[David Kubecka]

Am I the only one who always falls into the "".split(",").size == 1 trap? 😄

[Joffrey]

I'm not sure I understand which trap you mean. What would you expect to happen?

[Vampire]

Probably he expects size to be 0.
If so, for me tha answer is "no"

[David Kubecka]

Yes, I would expect that split on an empty string returns the empty list. If the answer for you is "no", could you please share your reasoning behind that?

[Vampire]

Same why "foo,".split(",").size == 2

[Joffrey]

Ah I see. Then no this doesn't surprise me. The reasoning: you have a string and want a list based on the , separator. Every element around , separators must be accounted for, empty strings are not special. When there is no separator, I wouldn't expect "a" to behave differently from "", I get one element which is the whole string.

[Joffrey]

I guess this boils down to the fact that empty strings aren't special

[Vampire]

It splits around the separator and gives all the split tokens.
"foo,".split(",") results in "foo" and "".
"foo,,bar".split(",") results in "foo", "", and "bar".
",".split(",") results in "" and "".
"".split(",") results in "".

[David Kubecka]

Ok. So the rule could be formulated as "the resulting list has the size equal to the number of separator occurecnces plus one"?

[Vampire]

Yes

[Joffrey]

Yes, and the nice thing is that it holds true, regardless of the emptiness of some segments/elements

[Joffrey]

Also, it has the nice consequence to play well with concatenation: no surprises if you do (s1 + "," + s2).split(","), or if you split s1 and s2 separately

[Klitos Kyriacou]

Be careful if you're used to Java. Java's split behaves differently.

[Vampire]

No it does not

[Vampire]

Or what do you mean?

[Klitos Kyriacou]

In Java, "one,".split(",") returns one element.

[Vampire]

Oh, right, there is this one strange special case with trailing delimiter unless you specify limit of -1, sorry, forgot about that.

[David Kubecka]

Well, it doesn't play well with joinToString 😞

listOf<Int>().joinToString(",").split(",").size == 1

[David Kubecka]

Intuitively, one would expect that joinToString and split are inverse to each other.

[Joffrey]

Fair enough, although I would argue that joinToString() is not injective (joining an empty list yields the same as joining a list of one element mapped to the empty string), so there is no way split() could be its inverse

[Vampire]

Yep, listOf<String>().joinToString(",").split(",") == listOf("").joinToString(",").split(",")

[Vampire]

They are not made to be inverse of each other, so they are not 🙂

[David Kubecka]

Yes, that's true for list of strings but that is kind of an edge case. I don't think you can make the same argument for list of ints for example.

[Vampire]

But joinToString is operating on list of strings.
If you don't give an explicit transform to make string out of it, it calls toString()

[Vampire]

The output of your split is not a list of ints, but a list of strings

[Vampire]

Another hint, that they are not "inverse"

[David Kubecka]

Yeah, surely they are not inverse in the strict sense. My point is that looking at this code

fun intListToCommaString(list: List<Int>) = list.joinToString(",")

fun commaStringToIntList(string: String) = string.split(",").map { it.toInt() }

I would think that those two functions are inverse. And indeed they are for every valid input except for the empty list case, which is kind of strange IMO. Or at least not obvious.

[David Kubecka]

I had this exact code in my JPA entity attribute converter and the behaviour around the empty list surprised me.

I understand, though, that "fixing" this particular case (i.e. making the split behaviour obvious wrt joinToString) might make other cases non-obvious.