Rust

5651 readers

28 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

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

[email protected]

What should the getter for a Vec|String| return, &[&str]? What about Option|Vec|String||? (programming.dev)

submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]

7 comments fedilink hide all child comments

When returning an immutable reference to a private struct field. (On mobile and used vertical bars instead of a bunch of HTML codes)

top 7 comments

sorted by: hot top controversial new old

[–] RunAwayFrog 4 points 1 year ago

Note: the ᐸᐳ characters used below are Canadian Aboriginal syllabics because Lemmy devs haven’t fixed broken input sanitization yet.

Well, getters are not an official concept in Rust. You can do whatever works best in your case.

Just worth pointing out that a method with a return value of OptionᐸVecᐸStringᐳᐳ wouldn't be really a getter, as you must be constructing values, or moving ownership, or cloning. None of these actions conceptually belong to a getter.

Also, you should be clear on the what the Option abstraction means. Does it mean the vector is empty? Does it mean the vector does not exist or some sort of null (FFI ore serialization contexts)? And make sure the code does what you expect it to do.

[–] [email protected] 3 points 1 year ago

Why not &[String]?

[–] [email protected] 2 points 1 year ago (2 children)

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.

[–] RunAwayFrog 3 points 1 year ago (1 children)

Note: the ᐸᐳ characters used below are Canadian Aboriginal syllabics because Lemmy devs haven't fixed broken input sanitization yet.

A vec and a string are basically the same thing (a series of bytes)

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 makes handling it much easier because you can still iterate over it

This is not a valid consideration/objection, as Options are iterable and you can flatten them:

fn main() {
  let v = vec![1,2,3];
  for n in Some(&amp;v).into_iter().flatten() {
    eprintln!("{n}");
  }
  for n in None::ᐸ&amp;Vecᐸi32ᐳᐳ.into_iter().flatten() {
    eprintln!("{n}");
  }
}

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

This paragraph appears to be out of place in the context of a Rust discussion.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] [email protected] 1 points 1 year ago

@heartlessevil @RunAwayFrog Yeah, LLVM's got your back.

[–] [email protected] 2 points 1 year ago

Vec::new is const and thus can’t allocate anyways.