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

  • RunAwayFrog@sh.itjust.works
    4·
    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.

  • hallettj@beehaw.org
    3·
    1 year ago

    You may be better off with &[String] as a read-only view of Vec. To get &[&str] I think you need to create a new collection to hold the &str values. (String and &str have different memory representations.) But the choice depends on what you want to do - maybe providing &str values adds a convenience that is worth creating a second collection.

    For the Option case I would go with Option<&[String]>. My understanding is that Option<&T> is the same size as &T for any T so an owned Option wrapper is zero-cost. If the reference pointer is null then Rust interprets that as None. Besides you usually want ownership of an Option so you can map it or whatever else you want to do.

    • jpfreely@programming.devOP
      1·
      1 year ago

      Right, I want the convenience of &[&str] , but if it requires creating a second collection then I think &[String] is better. Use cases that require &str can just map to as_str.

    • RunAwayFrog@sh.itjust.works
      3·
      1 year ago

      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(&v).into_iter().flatten() {
    eprintln!("{n}");
  }
  for n in None::ᐸ&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.

    • hallettj@beehaw.orgEnglish
      2·
      1 year ago

      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.

      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 the Option gives you an extra bit of information that can be helpful in certain cases.