The Promise of Rust

References avoid this:

    fn show(s: &String) {
        println!("s = {s}");
    }
    
    fn main() {
        let s = String::from("hiya");
        show(&s);
        show(&s);
    }

That should feel weird because it is inefficient & unnecessary

Yes, and the video is available in full right now. That’s my current business model. (I’m the author but I didn’t post the article here — I would expect older articles to show up)

Same as @conradludgate's answer, but stated differently. If you say you need &String in your function, then you can pass only &String in a function call. But if you say you need &str in your function, then you can pass either &str or &String. Rust will automatically convert the &String to &str using a mechanism called 'Deref coercion'.

And if you are wondering what the difference between &String and &str is, you need to start with a regular String. Strings are utf-8 encoded strings that may be modified at runtime. They are made of 2 parts in the memory. The first part is on the heap memory - a memory buffer of specific size that is filled partially or fully with utf-8 encoded text. The second part is usually (but not always) on the stack frame of the current function. It holds the metadata about the heap memory text buffer I mentioned earlier - that is, the pointer to the start of the buffer, the full size of the buffer and the size of the text currently occupying that buffer. (If you are wondering why you need the metadata part, it's because it has a fixed size and structure known at compile time, unlike the actual text buffer). When we take the reference &String, we get a safe pointer to the second part (the metadata).

Now &str. It's a reference to a fixed sized sub-string (slice) of a full string somewhere in the memory. (That sub-string can be the full string too). Since it points to a fixed-size portion of a string, it has only a pointer to the beginning of the sub-string and the size of the sub-string. (It's not concerned with the buffer's size at all).

The Deref coercion of &String to &str converts the pointer pointing to the metadata part of the String, to a pointer pointing at the buffer containing the actual text. This happens transparently.

This long an answer is irrelevant to the topic in the article. That's perhaps why it's omitted.

It's not too important. String is a String-Builder, it is a pointer+length+capacity. &String is thus a pointer to a pointer.

The idiomatic solution is to use &str, which is a string-view or string-slice, which is only a pointer+length.

&String can implicit cast to &str via deref-coercion, which means that it's free for APIs to only accept &str. Accepting &str is more correct in the idea that not all strings need to be allocated individually, some might be sliced from a larger string, and losing that generality would be a shame.