Length, Indexing, and Immutability vs Mutability

Having established what strings are logically (ordered sequences of characters) and how they're stored physically (contiguously in memory), we now explore the practical concepts that determine how you actually work with strings in code.

Three concepts form the foundation of all string manipulation:

1. Length — How many characters does this string contain?
2. Indexing — How do I access the character at a specific position?
3. Mutability — Can I change this string after it's created, or must I create a new one?

These aren't just implementation details—they're fundamental properties that affect how you design algorithms, predict performance, and avoid bugs. Master these concepts, and you'll write better string code in any language.

The length of a string is the number of characters it contains. This seems utterly simple—and for ASCII strings, it is. But as we'll see, 'length' has surprising depth.

Basic properties of length:

• The empty string "" has length 0
• A single-character string "A" has length 1
• Length is always a non-negative integer
• Length is a property of the string itself—it doesn't change unless the string changes

The fundamental length equation:

For a string with indices 0: through n-1, the length is n. Equivalently:

length(s) = highest_valid_index(s) + 1

Or:

valid_indices(s) = {0, 1, 2, ..., length(s) - 1}

This relationship between length and valid indices is critical for loop bounds and boundary checking.

For ASCII strings, length is straightforward: one byte = one character = one unit of length. But modern strings introduce complexity.

The three meanings of 'length':

1. Byte length: How many bytes does the string occupy in memory?
2. Code unit length: How many encoding units (e.g., UTF-16 code units) does it contain?
3. Character/grapheme length: How many visible characters does a human perceive?

These can all be different numbers for the same string:

String: "héllo👋"

Byte length (UTF-8):       10 bytes
  h(1) + é(2) + l(1) + l(1) + o(1) + 👋(4) = 10

Code unit length (UTF-16): 7 units
  h(1) + é(1) + l(1) + l(1) + o(1) + 👋(2) = 7

Grapheme/visual length:    6 characters
  h + é + l + l + o + 👋 = 6 visible things

The combining character problem:

Some 'characters' are actually composed of multiple code points. The letter 'é' can be represented as:

• One code point: U+00E9 (LATIN SMALL LETTER E WITH ACUTE) — 1 unit
• Two code points: U+0065 (e) + U+0301 (combining acute accent) — 2 units

Both render identically, but one has 'length' 1 and the other has 'length' 2 depending on how you count.

The emoji problem:

Modern emoji can be composed of multiple code points:

• 👨‍👩‍👧‍👦 (family emoji) is actually 7 code points joined by invisible 'joiner' characters
• Different platforms might show it as 1, 4, or 7 'characters' depending on their length function

This isn't pedantry—these differences cause real bugs:

• Truncating a message at 'character 10' might break an emoji
• Splitting a string might split a character into invalid fragments
• Character-by-character iteration might visit 'partial' characters

Indexing is the operation of accessing a specific character by its position number. Given a string s and an index k, the expression s[k] retrieves the character at position k.

Index semantics:

String:   "ALGORITHM"
Indices:   0 1 2 3 4 5 6 7 8
           A L G O R I T H M

s[0] = 'A'  (first character)
s[4] = 'R'  (fifth character, zero-indexed)
s[8] = 'M'  (last character)

The valid index range:

For a string of length n:

• Valid indices: 0, 1, 2, ..., n-1
• Invalid indices: anything < 0 or >= n

Accessing an invalid index is an error. Different languages handle this differently:

• Python/Java/C#: Throw an exception (IndexError, IndexOutOfBoundsException)
• JavaScript: Return undefined (silent failure—dangerous!)
• C/C++: Undefined behavior (anything can happen—very dangerous!)

Some languages (Python, Ruby, Perl) support negative indexing: a convenient way to access characters relative to the end of the string.

String:   "ALGORITHM"
Positive:  0 1 2 3 4 5 6 7 8
Negative: -9-8-7-6-5-4-3-2-1
           A L G O R I T H M

s[-1] = 'M'  (last character)
s[-2] = 'H'  (second-to-last)
s[-9] = 'A'  (first character, same as s[0])

The conversion formula:

For index i where i < 0:
  actual_index = length + i

Example: s[-1] where length = 9
  actual_index = 9 + (-1) = 8
  s[-1] ≡ s[8]

Why negative indexing is useful:

1. Access the last character: s[-1] instead of s[len(s)-1]
2. Traverse from end: s[-1], s[-2], s[-3], ...
3. Slice from end: s[-3:] gets the last 3 characters

Beyond single-character access, most languages support slicing: extracting a contiguous subsequence (substring) by specifying a range.

Common slice notation:

s[start:end]  → Characters from position start to end-1 (inclusive)
                (end is exclusive—the character at 'end' is NOT included)

String:   "ALGORITHM"
Indices:   0 1 2 3 4 5 6 7 8
           A L G O R I T H M

s[0:4]  = "ALGO"   (positions 0, 1, 2, 3)
s[2:6]  = "GORI"   (positions 2, 3, 4, 5)
s[4:9]  = "RITHM"  (positions 4, 5, 6, 7, 8)
s[3:3]  = ""       (empty range)

Why exclusive end?

The half-open interval [start, end) has elegant properties:

1. Length formula: length(s[start:end]) = end - start. No +1 or -1.
2. Non-overlapping splits: s[0:k] + s[k:n] = s[0:n]. No gaps, no overlaps.
3. Empty range: s[k:k] naturally yields empty string.
4. Full string: s[0:len(s)] gives the whole string.

One of the most important properties of strings in many languages is immutability: once a string is created, it cannot be modified.

What immutability means:

• You cannot change individual characters: s[3] = 'X' is an error
• You cannot insert, delete, or replace characters in-place
• Every 'modification' operation creates a new string with the changes

Immutable by default:

• Java, Python, JavaScript, C#, Go, Ruby, Swift

Mutable by default:

• C (char arrays), C++ (std::string), Rust (String)

Example in Python:

s = "hello"
s[0] = 'H'    # TypeError: 'str' object does not support item assignment

# Instead, create a new string:
s = 'H' + s[1:]   # s is now "Hello", but this is a NEW string object

Visualizing immutability:

Before:
variable s ──────→ [Memory block: "hello"]

After s = 'H' + s[1:]:
variable s ──────→ [New memory block: "Hello"]
                   [Old memory block: "hello"] ← orphaned, will be garbage collected

The original string "hello" still exists (briefly) in memory—it wasn't modified. The variable s now points to a completely new string "Hello".

Immutability might seem restrictive—why prevent modification? The reasons are compelling and explain why most modern languages default to immutable strings.

1. Thread Safety

If a string can't change, multiple threads can read it simultaneously without locks. No race conditions, no data corruption, no synchronization overhead. In concurrent programs, immutable strings are inherently safe.

2. Security

Sensitive strings (passwords, file paths, SQL queries) can't be modified maliciously after creation. A function receiving a string knows it won't change unexpectedly.

3. Caching and Hashing

Immutable strings can be safely cached. Their hash codes can be computed once and stored. HashMap keys work correctly because the key can't change after insertion.

4. Sharing Without Copying

Multiple variables can safely reference the same string—no need to copy defensively. a = "hello"; b = a doesn't copy the string; both point to the same memory.

5. Reasoning and Debugging

When strings can't change, you can reason about code more easily. If you see a string created at line 10, you know its content at line 100 (assuming the same variable).