10
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 13 Aug 2023
10 points (91.7% liked)
Rust
5938 readers
1 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
A vec and a string are basically the same thing (a series of bytes)
In the context of vectors I prefer my APIs to return an empty set rather than an None-option. This makes handling it much easier because you can still iterate over it, it just has nothing.
This might involve the compiler making an allocation of an empty array but most of them (gcc, ghc) will now what you are doing and optimize the null check on the empty array to a bool check.
Note: the
ᐸᐳ
characters used below are Canadian Aboriginal syllabics because Lemmy devs haven't fixed broken input sanitization yet.Everything is a series of bytes! I thought you were going to mention that both are fat pointers. But that "series of bytes" description is quite weird.
This is not a valid consideration/objection, as
Option
s are iterable and you can flatten them:This paragraph appears to be out of place in the context of a Rust discussion.
Yes, but it's a pain to iterate over Options of Vec because you need to check/flatten twice. I am aware gcc/ghc is not relevant to rust discussions but I am not sure if rustc performs these specific optimizations. I expect it does because they are trivial. Who knows. I am just some random dude on the internet and a lot of drugs.
I can see that argument. But you can also iterate over an Option-wrapped response with something like
for x in xs.into_iter().flatten() { ... }
, and theOption
gives you an extra bit of information that can be helpful in certain cases.Vec::new is const and thus can’t allocate anyways.