flint dew
Is the Rust compiler smart enough to know to optimise optional parameters away?
fn foo(value: i32) {
...
}
fn foo_optional(optional: Option<i32>) {
foo(optional.unwrap_or(5));
}
fn main() {
foo_optional(None);
foo(5);
}
Essentially, is foo(5) the exact same thing as foo_optional(None) where optional is known to be None at compile-time?
placid urchin
that'll all get inlined, so sure
flint dew
any situations where this wouldn't work?
e.g.
#[inline(never)]
fn foo(value: i32) {
...
}
#[inline(never)]
fn foo_optional(optional: Option<i32>) {
foo(optional.unwrap_or(5));
}
fn main() {
foo_optional(None);
foo(5);
}
maybe if it involved trait objects and dynamic dispatch etc, because those probably wont get devirtualized
placid urchin
```rs
#[inline(never)]
fn foo(value: i32) {
...
}
#[inline(never)]
fn foo_o...
yeah probably not in that case. but inline(never) is just a hint, and lack of inlining is not guaranteed
ionic apex
I think generally it's preferred to have two distinct versions of a function if a parameter is going to be optional, for example, Vec::new and Vec::with_capacity, rather than passing Options around...