Odpowiedź.

Historia pytania:

W porównaniu z językami natywnymi (C/C++), Rust buduje bezpieczną pracę z ciągami dzięki ścisłemu rozdzieleniu typów referencyjnych (&str) i własnościowych (String). To eliminuje większość błędów związanych z niewłaściwą pamięcią, przekroczeniem bufora i double-free.

Problem:

W przeciwieństwie do dorosłych języków z GC, gdzie każdy ciąg żyje w zarządzanej pamięci, w Rust trzeba jasno rozumieć, kto jest właścicielem ciągu, jak długo on żyje i jak uniknąć dangling reference po modyfikacjach. Praca z ciągami UTF-8 wymaga ostrożności przy indeksowaniu i zmianach.

Rozwiązanie:

W Rust String to mutowalny, przydzielany na heapie ciąg, który jest właścicielem swojej zawartości. &str to niemutowalna referencja do ciągu bajtów z gwarancją UTF-8. W razie potrzeby można bezpiecznie konwertować (&str -> String i odwrotnie) za pomocą metod std.

Przykład kodu:

fn main() {
    let owned: String = String::from("Rust");
    let borrowed: &str = &owned;
    let primitive: &str = "Hello"; // literał zawsze jest &str
    // Konwersja &str -> String
    let s: String = primitive.to_string();
    // Konwersja String -> &str
    let st: &str = &s;
    println!("{} {} {} {}", owned, borrowed, primitive, st);
}

Kluczowe cechy:

Wyraźne rozdzielenie między własnością a referencją (heap vs slice)
Metody konwersji typu safety między String a &str są efektywne i przezroczyste pod względem cyklu życia obiektu
Literały ciągów zawsze mają typ &'static str, a nie String

Pytania z podstępem.

Dlaczego nie można indeksować ciągu jak s[1] lub s[i]?

Ciągi Rust są w UTF-8, dlatego indeksowanie nie jest dostępne bezpośrednio: s[i] nie zwraca i-tego znaku, a czasami prowadzi do panic przy dostępie do niewłaściwej granicy bajtów. Zamiast tego używaj metod .chars().nth(i) lub .get(start..end).

Czy można bezpiecznie modyfikować &str?

Nie można — &str jest zawsze niemutowalnym slice. Do modyfikacji używaj to_owned/to_string, lub korzystaj z String/Vec<u8>.

Czym zasadniczo różni się String::from("abc") od "abc".to_string()?

Te opcje są równoważne pod względem wyniku, obie tworzą String z kopiowaniem danych z &str. Różnica leży jedynie w stylu: na przykład to_string jest zrealizowane za pomocą trait ToString, podczas gdy String::from bardziej kontrastowo wyraża intencję "stwórz własność".

Typowe błędy i antywzorce

Próba indeksowania ciągu s[1] lub s[0] w celu uzyskania char
Niejawne konwersje bez określenia cyklu życia: zwracanie referencji do tymczasowych obiektów
Używanie String tam, gdzie wystarczy &str (zbędna alokacja)

Przykład z życia

Negatywny przypadek

Funkcja przyjmowała String i robiła niepotrzebne kopiowanie ciągu wewnątrz (clone), a następnie pisała slice w inną funkcję, zapominając przedłużyć okres życia źródła. Wynik: dangling reference & crash.

Plusy:

Analogicznie do znanych języków: można łatwo uzyskać "kopię" ciągu

Minusy:

Straty wydajności z powodu zbędnych alokacji
Możliwy wyciek referencji do tymczasowych wartości

Pozytywny przypadek

Funkcja przyjmuje &str, a jeśli potrzebne są modyfikacje — wewnętrznie wywołuje .to_string(), na zewnątrz cała logika pozostaje "zero copy". Okresy życia pod kontrolą, żadnych zbędnych alokacji.