T.into() vs Some(x) are there any detriments of using .into()?

161 Views Asked by At

I just observed for the first time that I could create Options with .into() instead of wrapping in Some(). Are there any downsides to this approach?

1

There are 1 best solutions below

2
Kushagra Gupta On

Codegen wise, there wouldn't be any downsides as the .into() just wraps the value in Some() too. The only problem might be if LLVM wasn't inlining the call.

In the code readability side though, .into() is far less clear than Some(). .into() is highly generic. That means, you could end up having to add type annotations, which is more effort than just wrapping yourself. Even in the cases where you don't need to add annotations, it can become difficult for the reader what the type of the expression is.

IMO, .into() should be used where the exact type is not important and is only an implementation detail. The meaning of the type should not change. Going from Foo::Color to Foo::BetterForInternalUseColor is an implementation detail and does not change meaning. Going from T to Option<T> does.