4 ms·

You might find generics useful as well, to support any parameter that can be referenced as a `&str`, such as a `String`: fn tokenize<S: AsRef<str>>(code: S

You might find generics useful as well, to support any parameter that can be referenced as a `&str`, such as a `String`: fn tokenize<S: AsRef<str>>(code: S) -> ... code.as_ref() Edit: whoops, was too quick, apparently this isn't a great idea here.

ridiculous_fish 6y ago
What would be the ... in this case?
- Arnavion 6y ago
  It's a bad suggestion for this case [1]. The ... would have to be `impl Iterator<Item = String>`, because the function would not have anything to return a borrow from. That is exactly the problem the original article was trying to avoid in the first place. [1]: And arguably a bad suggestion in general. If a fn needs a String, it should take a String. If it needs a &str, it should take a &str, and if the caller has a String they can call the fn with a borrow. fns that are generic on AsRef<str> are usually only found where the ergonomics make it worth it. Eg the standard library's filesystem functions often take AsRef<Path> parameters because string literals are AsRef<Path>, which means you can write fs::read_to_string("/etc/passwd") instead of a more cumbersome fs::read_to_string(Path::new(OsStr::new("/etc/passwd")))
  - timvisee 6y ago
    You're right! Didn't think about it much before posting.
alilleybrinker 6y ago
In cases like this, it can be useful to have the generic function call a separate, private function which does the implementation and is _not_ generic. Generic functions are monomorphized, meaning copies are generated for each concrete type they're called with. Separating them out in this way can reduce the size of the generated code after monomorphization.
- Arnavion 6y ago
  In cases like this, the generic function cannot return an Iterator of &str that borrow from the input because the input is being consumed, so it's a bad suggestion. The input needs to be &str to be able to return borrows from it. If they had tried to complete their code and compile it, they would've noticed there's no way the function could return `code.as_ref()`.
  - alilleybrinker 6y ago
    That's true that in this case their plan of making the input generic wouldn't work, as it relies on the output being borrowed. The technique of reducing the size of monomorphized functions would be useful in other contexts, but not this one.

ridiculous_fish 6y ago

What would be the ... in this case?

Arnavion 6y ago
It's a bad suggestion for this case [1]. The ... would have to be `impl Iterator<Item = String>`, because the function would not have anything to return a borrow from. That is exactly the problem the original article was trying to avoid in the first place. [1]: And arguably a bad suggestion in general. If a fn needs a String, it should take a String. If it needs a &str, it should take a &str, and if the caller has a String they can call the fn with a borrow. fns that are generic on AsRef<str> are usually only found where the ergonomics make it worth it. Eg the standard library's filesystem functions often take AsRef<Path> parameters because string literals are AsRef<Path>, which means you can write fs::read_to_string("/etc/passwd") instead of a more cumbersome fs::read_to_string(Path::new(OsStr::new("/etc/passwd")))
- timvisee 6y ago
  You're right! Didn't think about it much before posting.

alilleybrinker 6y ago

In cases like this, it can be useful to have the generic function call a separate, private function which does the implementation and is _not_ generic. Generic functions are monomorphized, meaning copies are generated for each concrete type they're called with. Separating them out in this way can reduce the size of the generated code after monomorphization.

Arnavion 6y ago
In cases like this, the generic function cannot return an Iterator of &str that borrow from the input because the input is being consumed, so it's a bad suggestion. The input needs to be &str to be able to return borrows from it. If they had tried to complete their code and compile it, they would've noticed there's no way the function could return `code.as_ref()`.
- alilleybrinker 6y ago
  That's true that in this case their plan of making the input generic wouldn't work, as it relies on the output being borrowed. The technique of reducing the size of monomorphized functions would be useful in other contexts, but not this one.