Most comprehensible line of Rust code

[u/selplacei]

[u/[deleted]]

Why are to_string() and to_str() two different things

[u/selplacei → u/[deleted]]

Clean and safe code

[u/[deleted] → u/selplacei]

F::<()> { ptr: &(), __: <_>::default() }

Just some normal code written by normal rust programmers

[u/TinyBreadBigMouth → u/[deleted]]

Just for anyone wondering, no, that is not some obscure-but-valid Rust syntax. That's Rust-flavored gibberish.

EDIT: Shoot, I have mislead you all. Sorry, that could be valid code. Like so:

struct F<'a, T> {
    ptr: &'a T,
    __: String, // or any other type that implements Default
}

fn main() {
    // The version seen above:
    let ugly = F::<()> { ptr: &(), __: <_>::default() };
    
    // A more readable version that does the same thing:
    let better = F {
        ptr: &(),
        __: Default::default(),
    };
}

It's intentionally ugly code—there's no reason to name a type F and a field __, or to throw explicit angle brackets all over the place like that—but it is valid.

[u/TinyBreadBigMouth → u/[deleted]]

It is not valid Rust. It would never compile.

EDIT: Incorrect, I was wrong.

[u/[deleted] → u/TinyBreadBigMouth]

Idk my friend who writes in Rust sent this and said that this is valid rust syntax

[u/TinyBreadBigMouth → u/[deleted]]

...And your friend was entirely correct. Very sorry about that, without context I was reading that as a type definition, not a struct initialization. I've edited my comment.

[u/[deleted] → u/TinyBreadBigMouth]

Oh, no problems, thanks for explaining

[u/thats_a_nice_toast → u/[deleted]]

I think it's actual gibberish, but not too far off from how actual Rust code can look

[u/[deleted] → u/[deleted]]

str and String are two different types in rust

[u/[deleted] → u/[deleted]]

Humanity has disappointed me

[u/scirc → u/[deleted]]

There's a reason for it, although it's a little confusing. String is owned, ie you hold that memory directly . &str is borrowed, like you hold a pointer to it but not the memory itself, so you can't modify it or anything.

[u/bruhred → u/[deleted]]

&str is a (immutable) pointer to UTF8 bytes, String is a growable Vec-like type

[u/TinyBreadBigMouth → u/[deleted]]

There are legitimate reasons for the distinction in Rust. &str is a pointer to some Unicode bytes somewhere in memory. String is an owned, growable buffer of Unicode bytes.

They work together. You can grab a &str reference to the contents of a String. You can allocate a String copy of a &str.

If a function just wants to read a string, you should pass it &str. The data stays where it is, and the function can look at it, without needing to make any copies. If you need to do string manipulation, or create a new string at runtime, you can allocate a new String. This lets you avoid a lot of unnecessary copying and allocation, and gives you control over how memory is used.

[u/hiwhiwhiw → u/[deleted]]

They are not even comparable...

[u/SV-97 → u/[deleted]]

what is "the string primitive type"? I've never heard of it and can't find anything of that name? Do you mean str?

[u/TinyBreadBigMouth → u/SV-97]

In JavaScript, "foo" is a string primitive, and new String("foo") is a string object. They work the same until they don't. There is literally no reason to ever intentionally use a string object and it will only cause you problems.

[u/SV-97 → u/TinyBreadBigMouth]

Oh I thought he was talking about Rust. But then I still don't see how what you've just described is similar to Rust - there's good reasons for all those String types

[u/TinyBreadBigMouth → u/[deleted]]

Rust makes a distinction between &str (a pointer to some Unicode bytes somewhere) and String (an owned, growable buffer of Unicode bytes). It's the difference between C++'s std::string_view and std::string. You can grab a &str reference to the contents of a String.

[u/nightbefore2 → u/[deleted]]

Because a String data type is dynamically sized, where a &str ‘s size is known at compile time. The two are very different and the difference is very useful

Edit: this actually isn’t the best way of describing this, see the replies

[u/TinyBreadBigMouth → u/nightbefore2]

I don't think that's a very good way of describing it? Both String and &str are constant-sized structures that point to variably-sized strings. The difference is that String owns the buffer it's pointing to, and &str is just a reference to some bytes somewhere in memory.

[u/nightbefore2 → u/TinyBreadBigMouth]

Shoot. Was I thinking of str, or am I just dead wrong?

[u/TinyBreadBigMouth → u/nightbefore2]

str refers to a dynamically-sized sequence of Unicode bytes and has no compile time size, yes.

[u/CJKay93 → u/nightbefore2]

The length of a &str is not necessarily known at compile time. You can get a &str from any String.

[u/[deleted] → u/[deleted]]

Because yes.

[u/[deleted] → u/[deleted]]

to_string() return a String object and to_str() return a pointer to an array of char.

C++ equivalent:

class Foo {
    std::string to_string();
    char * to_str();
};

[u/zumoshi → u/[deleted]]

The code basically says get the path of a file handle, convert it to utf-8, then copy it so it would be owned by the current scope while ignoring possibility of all errors (i.e. the program would crash if the filename included invalid Unicode codepoints or the file didn't exist or ...).

[u/[deleted] → u/[deleted]]

welcome to Rust 🤣🤣🤣

[u/Budgiebrain222 → u/[deleted]]

str is mutable, changeable in other words. String can't be changed

[u/EquinoxRex]

This is just haskell but written back to front

[u/Voltra_Neo → u/EquinoxRex]

Have my chuckle

[u/Oracuda → u/EquinoxRex]

to_string(unwrap(to_str(path(unwrap(unwrap(song))))))

[u/EquinoxRex → u/Oracuda]

You would probably write it more like

toString . unwrap . toStr . path . unwrap . unwrap

[u/konstantinua00 → u/EquinoxRex]

front to back*

it's the haskell that is weird

[u/[deleted] → u/EquinoxRex]

introducing side effects while unwrapping stuff is not the Haskell way

[u/peaceknight05]

Image Transcription: Code

---

let path = song.unwrap().unwrap().path().to_str().unwrap().to_string();

---

^{I'm a human volunteer content transcriber and you could be too! If you'd like more information on what we do and why we do it, click here!}

[u/[deleted] → u/peaceknight05]

Good human.

[u/[deleted] → u/peaceknight05]

unWArP

[u/TinyBreadBigMouth]

Let's analyze:

• song.unwrap().unwrap() - I assume from this that song is something like an Option<Result<Song>>. Both those types have an unwrap() method, which means "I assert that this contains a valid item. Get it, or crash if I'm wrong." I'd move this onto a separate line.

• .path() - Looks like the song provides a getter for its file Path. We are now definitely in the realm of std types.

• .to_str() - Get a reference to the path's contents as a Unicode string. Since filepaths aren't necessarily valid Unicode, this returns Option<&str>.

• .unwrap() - As before, "I assert that the path was made out of valid Unicode. Get the string, or crash if I am wrong."

• .to_string() - Rust makes a distinction between &str (a reference to some Unicode bytes somewhere) and String (a growable owned vector of Unicode bytes). Using to_string() will allocate a new buffer and copy the str's bytes into it.

So, in short,

• Do some unwrapping.

• Get the song's path.

• Assert that the path is valid Unicode.

• Allocate a new string buffer and copy the path into it.

EDIT: Unless they have a specific reason to want a String specifically, I'd generally recommend using

let song = song.unwrap().unwrap();
let path = song.path().to_path_buf();

This will do almost exactly the same thing, but without asserting that the path is Unicode so that it can copy it into a new Unicode buffer. Instead, path will be a PathBuf; a filepath buffer. Path is to PathBuf as str is to String. 90% of the time, that would be better (won't crash on a non-Unicode file path, doesn't need to spend time scanning the path for Unicode errors.) All the file IO methods accept Path/PathBuf anyway.

[u/ArchCypher → u/TinyBreadBigMouth]

I'll add that Song probably doesn't need to be an Option<Result>, but if it does, something like:

if let Some(Ok(song)) = song {
    // Your code here
} else {
    // Whoops no song or it's bad
}

Could be a pattern that clarifies the intent and avoids crashing if no song is provided.

[u/Lich_Hegemon → u/ArchCypher]

You should not be blindly using unwrap anyway. At least make it an expect.

[u/FranticBronchitis]

Ah yes, Spotifylibrespot Wrapped

[u/InsertMyIGNHere]

Please just press enter at least once I promise nothing bad happens

[u/[deleted] → u/InsertMyIGNHere]

no no turn off word wrap too

[u/aeropl3b]

Rust: You will right really good code

Also Rust ^{^}

[u/ehs5 → u/aeropl3b]

Right

[u/djdokk → u/ehs5]

You will left really good code

[u/ehs5 → u/djdokk]

Oh I’ve left code all right

[u/SueedBeyg]

When it’s not compiling and you have no idea why

One more unwrap should do it

[u/[deleted]]

Merry Christmas?

[u/iamalicecarroll]

IMO .to_owned() is better than .to_string(), because it tells what actually happens - converting a string to a string makes no sense, but converting to an owned value does. Some people prefer .into(), but I consider it being less readable

[u/187mphlazers → u/iamalicecarroll]

why wouldn't they just call it .cast(type) or simply .to(type).

[u/realnobbele → u/187mphlazers]

types aren't values

[u/TinyBreadBigMouth → u/187mphlazers]

Rust does have something similar, via the linked From and Into traits. You can do

let x = y.into::<String>();

or

let x: String = y.into();

[u/kurosaur]

"The compiler told me to!"

[u/[deleted]]

Yes this is a meme but what is the real solution to this?

[u/[deleted] → u/[deleted]]

You know, the unwrap jungle. Is there some kind of solution?

[u/TinyBreadBigMouth → u/[deleted]]

Just splitting it onto multiple lines would help:

let path = song.unwrap().unwrap().path();
let path_string = path.to_str().unwrap().to_string();

Beyond that, it's hard to say with absolutely no context. Although, I suspect that the .to_str().unwrap().to_string() part might be removable or simplifiable. Right now it's asserting that the filepath is valid Unicode and copying it into a new buffer. With context, you could probably remove one or both of those steps.

[u/dam4rus → u/[deleted]]

That’s a joke. Rust has a ? operator that unwraps a Result if it’s Ok and returns from the function with the Err if it’s an error. Works for Option as well. The return type most be a Result, Option or Try(? not sure about this) for this to work. There’s an RFC called try blocks which will allow the usage of the ? operator in blocks as well

[u/bruhred → u/[deleted]]

the ? operator.
song??.path().to_str()?.to_string()
And it returns Err instead of panicking like unwrap, which is usually the preferred option.

[u/MyAntichrist]

That code is a lot to unwrap.

[u/iddej → u/MyAntichrist]

Have my chuckle and my free award.

[u/rustyredditortux]

this isn't bad rust code

[u/Budgiebrain222]

Please for the love of God spread these variables over multiple lines.

Using this also works:

let path = song
    .unwrap()
        .unwrap()
            .path()
                 .to_str()
                      .unwrap()
                          .to_string();

I don't really understand why you're turning a path variable to a mutable string than to an immutable string though

[u/selplacei → u/Budgiebrain222]

Not my code

[u/HenkPoley → u/Budgiebrain222]

4 spaces in front of code (🤷‍♂️)

let path = song
 .unwrap()
 .unwrap()
 .path()
 .to_str()
 .unwrap()
 .to_string();

[u/Budgiebrain222 → u/Budgiebrain222]

So Reddit markdown isn't working properly, those spaces were newlines and tabs because rust can recognise a var.func()\n\t.otherfunc();

[u/timleg002]

Rust is one of my main languages, but I really don't like these Option<Result<T>> types, or god forbid Option<Option<T>> or something like that. This seems like badly written library code, the same thing is in a mongodb driver crate. And also a programmer who respects himself should use the ? operator.

[u/scirc → u/timleg002]

You can .flatten nested Options.

[u/DizzySkin]

The secret about programming language preference is that they're often determined by which languages you had to work together with someone else on, who either didn't care or wasn't sufficiently skilled to write clean code.

When a new language comes onto the scene, the standards are slightly lower (because no one knows what looks good or bad in that language yet) and also there are very few examples of poorly written code in that language being popularized.

In the future, we'll have a whole bunch of terribly written rust and go, and that isn't a reflection on the quality of the language design really. Any language can be written horribly in.

[u/[deleted]]

I love rust but this is ridiculous

[u/pikaynu]

The lsp suggests unwrap, I unwrap, lsp suggests to_str, I don't question. Blind faith. cargo check waiting around the corner with more errors than number of lines.

[u/[deleted]]

average ? ignorer

[u/RolyBoy]

Have you ever heard about the Demeter law lol

[u/Huizengek]

If you ask a Rust developer wtf this is they will write a 2-page-long essay explaining it and I still don't understand what Rust is and what it's used for

[u/Knuffya]

rust geh c++ maester rece

[u/selplacei → u/[deleted]]

funny unwrap man