Do you feel Rust is too verbose for simple things?

[hydroper1]

But you've to do unwrap_or(...) anyway. Tbh I directly thought in unwrap() when posting about out-of-bounds error on this topic, but the owned string type isn't so flexible as its operations return &str again.

[moy2010]

Not really. Having your value wrapped by an Option provides you a context to do the computations you need to perform in a safe way.

Attempting to unlift a value immediately after is often a sign of misunderstanding the value of monads.

[quinedot]

It'd be more like

s.get(..2) == Some("fo")

But yeah, "custom" string support and interop -- including between OsStr and str! -- could definitely be improved.

[quinedot]

...I mean actually it'd be

s.starts_with("fo")

but for a more general range the comment applies.

[SOFe]

I see that you repeatedly say you get a &str instead of String. Maybe you really should have used &str instead then? If you just want to slice it again, I don't see any reason you want to own the intermediate step.

[hydroper1]

I was saying that because I didn't find str and std::string::String types flexible, but I just gave up creating my own alternative string type because Rust ends up using them too much ("literal" returns str, include_str!(...) returns str... and so on). I stopped implementing my own type on regular expressions, but if I futurely implement my own scripting language, I'll still use my own type (for Python like Scalar Value strings).

Instead of s: impl AsRef<str> I'm now using s: impl AnyStringType as function parameters (and then I call s.convert(), which returns &str), which made me feel fine.

[truppelito]

You know, I went through the exact same question myself when I started learning Rust. I decided to start using Rust because I needed the absolute best no-compromises performance for some algorithmic code I'm writing, and I couldn't stand C++ anymore. And when I started with Rust, I thought "what do you mean, I have to write Some(x) every time I need to return an option? why not just x with implicit conversion?", "so many .into() calls!", etcetc. But eventually I realised: that's the point. It's the trade-off Rust, as a language, is making: everything is explicit. Disavantage: more code to write. Advantage: code is much clearer when read, and there are very few ambiguities and hidden effects. Whether you like this trade-off or not, it's up to you. I know I do.

[xmh0511]

I have to say too many implicit things would blow up to your face. Consider this example in C++:

struct A{A(int){}};
struct B{B(A){}};

B c{{0}}; // OK
B d({0}); // call to constructor of 'B' is ambiguous

You may be surprised why one is ok and the other results in an error but they are only different in the outmost brackets. This issue is incurred from the implicit conversion sequence and implicit-declared constructors. The standard has so much jargon to say about which one is permitted and which one is forbidden with complex rules.

With the assumption, one guy is sufficiently familiar with the rules of the c++ standard, he uses a large of the similar trick, in the codebase, to prove he is the guru of c++... when you maintain the codebase you have to dig into the standard to find out why and spend a large of time to research the syntax and rules instead of paying more attention on the business logic itself, in this situation, you would think: I would prefer to spend a bit more time to input more characters. Moreover, the spent time inputting characters is negligible than you spend time for research complex rules.