Continuing the discussion from String indices : byte indexing feels wrong … The other day I had a somewhat clever idea for how to preserve the O(1) indexing benefits that Julia currently has, while making string indexing more intuitive. The idea is to define a StringIndex type like this: struct Stri…

[image] stevengj: s[1:nextind(s,4)] should be s[1:nextind(s,1,4)] perhaps? This correction should probably be a good argument…

[image] Dan: should be s[1:nextind(s,1,4)] perhaps? This correction should probably be a good argument… Right, fixed the typo. Again, if this were an important/common operation, I agree that a nicer syntax would be helpful. In fact, we do have using Unicode graphemes(s, 1:5) which is a l…

[image] stevengj: It still doesn’t seem to have much practical utility The one situation where I’ve come across this in my own packages is for pretty-printing tabular data including math-unicode to stdout . That is, the header including ∫gₐ(t)dt in the tabular output shown at the bottom of Opt…

[image] goerz: But as soon as I bring that feature over from the Python version, I’ll have to do string processing based on graphemes there as well to make sure everything lines up neatly in columns. That’s still wrong, because not every grapheme has the same width (even in “monospaced” fonts…

[image] stevengj: You really want to do string processing based on textwidth Fortunately, Julia already has just such a function, done correctly, the lpad function And this is why I love Julia, and I’m more than happy to have switched from Fortran/Python to Julia. It also demonstrates why …

[image] stevengj: s[1:5] is buggy code for an arbitrary s, certainly. But it seems more like a programmer/coding problem than a language one. “Give me the first five codepoints of a string” is possible to do properly in Julia right now, via s[1:nextind(s,1,4)]. Admittedly, that syntax is a litt…

[image] mnemnion: The idea here is to make it easier to write less buggy code, surely. Yes, but that’s the argument for an opaque StringIndex type, ala Restrict indexing into strings to a special `ByteIndex` or `StringIndex` type · Issue #9297 · JuliaLang/julia · GitHub as mentioned above. I…

I think the problem here might be that String is index-able at all. I think we would likely see fewer complaints if we instead had nth_char(::AbstractString, ::Integer) and nth_byte(::AbstractString, Integer), and getindex(::AbstractString, Integer) errored with a helpful error message.

I would expect a lot of complaints if you were unable to index a string, like you can in every single other programming language I’ve ever used. The issue is that there’s more than one sensible way to index into a string, and a String type has to support one of those, rather than several. There’s …

I don’t think anyone would object to a StringViews package with CodepointsView, GraphemesView, and TermColumnsView, each with their own indexing and iteration, and each defining v[i] as the appropriate SubString of the String they wrap. That sounds like a super useful thing!

StringIndex idea (Julia 2.0)

Internals & Design

Topic		Replies	Views
String indices : byte indexing feels wrong New to Julia strings , unicode	18	1615	December 5, 2023
Breakage due to changes in `String` slicing in v0.7 Internals & Design	35	2537	February 12, 2018
Indexing strings by Unicode code point instead of code unit? General Usage strings	14	2710	January 12, 2024
Substring function? New to Julia strings , unicode	42	4372	July 18, 2022
Performance of length(::String) Performance	24	4105	July 28, 2018

StringIndex idea (Julia 2.0)

Related topics