Improve stdlib stringSplit behavior for empty separator

[roman-khimov]

Summary or problem description
stringSplit("abc", "") returns ["abc"].

Do you have any solution you want to propose?
Nothing specifically bad about that, but Go library returns ["a", "b", "c"] in this case and I find this behavior somewhat more useful (how to make a character level split otherwise?), so this can be an improvement.

Related to #4584, nspcc-dev/neo-go#4367.

Where in the software does this update applies to?

• Native contracts

[shargon]

It's a weird split behavior, isn't it?

[shargon]

I always thought that split with empty string was the same string, but maybe I'm wrong, I vote for this option, but let's wait for others opinions

[roman-khimov]

On it's own it's nonsense, so the behavior of this case is purely a convention to me. Can be the same string, can be something else. Go strings library treats it as UTF-8 character split (https://pkg.go.dev/strings#Split) which is just a bit more useful (adds some possibilities where returning the same string does not). We don't have any other way to perform character-level split, so this can be a good addition. At the same time UTF-8 split can be a separate API, also a matter of convention. Or maybe we don't need it now (who is going to use this split?).

[cschuchardt88]

There is no single universal behavior for stringSplit / split with an empty separator across software development. Empty-separator semantics are a language/library convention, so both Neo’s current result and Go’s result are defensible.

Cross-language reality

Environment	Empty separator	Typical result / behavior
Neo stdlib (today)	stringSplit("abc", ")	["abc"] (identity)
Go strings.Split	empty sep	["a","b","c"] (UTF-8 runes) — docs
JavaScript	"abc".split(")`	["a","b","c"]
Python	"abc".split(")`	raises ValueError
.NET	depends on API / options	empty separators are often not treated as “split every character” in the Go sense

So it is not that one of us is “wrong about how split works in general”; runtimes simply disagree.

Addressing points raised here

@shargon — “weird” / “I always thought empty string split was the same string”
That intuition is common and matches several real-world APIs (and Neo today). Go/JS-style character split is also common. “Weird” is fair as a gut reaction either way; it is not uniquely weird relative to the industry—it is underspecified by convention.

@roman-khimov — pure convention; Go more useful for character-level split; optional separate API; maybe no demand
Agree on convention. The practical tradeoff is:

1. Change empty-sep to Go-like rune/char split

   • Pros: more useful if you need char-level split and have no other API; closer to Go / some other ecosystems.
   • Cons: semantic change for any contract that relied on identity; for native stdlib this is consensus-sensitive and should be treated as an intentional change (document + hardfork / version gate if applicable), not a silent “bugfix.”

2. Keep identity for empty sep; add a dedicated char/rune split method

   • Pros: no ambiguity overload of ""`; existing behavior stays clear; “how do I split by character?” has an obvious answer.
   • Cons: one more method to specify, implement, and document.

3. Keep current behavior and document it; do nothing else until there is real demand

   • Pros: lowest risk; matches Roman’s “who is going to use this?” if usage is rare.
   • Cons: still no first-class character split.

Preference

I would not frame this as fixing a universal correctness bug. If the goal is character-level split, I slightly prefer a dedicated API (or explicit hardforked change of empty-sep semantics with clear docs) over implying that empty-separator must mean Go’s behavior.

If we change empty-sep behavior, please document it and treat it as a compatibility decision. If we keep it, documenting ""→[original]` would remove a lot of the “is this weird?” confusion.

Happy to follow whatever the group prefers; mainly arguing we choose deliberately among valid conventions rather than assume one industry standard.