> More like promoted indirectly, I think by being used widely on reference code and tutorials the programmers absorbs as a familiar and quick to write method without planning much.
For references/documentation/tutorials I think the use of unwrap() and friends is a tradeoff. It (arguably) allows for more focused/self-contained examples that better showcase a particular aspect, though with the risk that a reader uses those examples as-is without taking other factors into consideration. There's also the fact that documentation examples can be used as tests, in which case use of unwrap() in docs/examples/etc. is arguably a good thing.
> And at same time by not being actively promoted that such methods should not be used within a library runtime or similar at least, because many people do not see it as wrong, what convert it in philosophy I guess.
I think it might depend on where you're looking. For example, the Rust book has a section titled "To panic! or Not to panic!" [0] which outlines some things to consider when deciding whether to panic/call unwrap()/etc. Not sure if that counts as active promotion, but the fact it's in official docs should count for something at least.
> IMHO they can't be genuine if a lib can panic the program
I feel this is a rather strong position to take. Given how panics are intended to be used (handling unexpected state/precondition violations/etc.), it seems it seems akin to saying "just don't write bugs", which would certainly be nice but isn't really realistic for the vast majority of development. I suppose one could hypothetically bubble up every possible error but that comes with its own maintainability/readability/etc. costs.
In addition, that stance seems similar to stating that there's no "genuine" assertion failures or similar in libraries, which seems... bold? What would the alternative be?
> or if it was just a unfinished prototyping part or etc
At least in Rust there's todo!() and unimplemented!() which more directly convey meaning.
`unwrap()` contains an assertion. Just like `slice[i]` or even `Box::new(whatever)`. The way to avoid these in C is to commit UB instead of panicking. I've seen arguments that seem understandable for why this is maybe appropriate in the Linux kernel ("I'd rather continue executing with garbage than shut down the user's system"), but I don't think it applies much beyond that. And to be clear, I'm not saying I agree with that either.
> Given how panics are intended to be used (handling unexpected state/precondition violations/etc.), it seems it seems akin to saying "just don't write bugs"
It is more about always making the error reach the function that called the method/library (lost if one of the own dependencies of this library rise the panic [UB included] crashing the program), what allows the programmer to take the decision (and not to a deep dependency^5 ) about if to continue running the program, by taking alternative route, or not.
The thing is that that kind of design isn't an unambiguous good; there are tradeoffs involved. Writing code in that manner means every single possibly-falliable operation must return an Option/Result/etc, said result checked, and the error bubbled up or the result used as appropriate. This can be quite noisy, especially before Rust 1.13.0, where users had to make do with the try!() macro instead of the ? operator. That can have negative impacts on readability/maintainability/clarity/etc. which may arguably outweigh benefits from allowing callers to handle errors, especially if callers usually don't.
This is also "viral", in that the use of any possibly-falliable operation in the implementation would require the corresponding public API to return a Result/Option/etc., even if the intent is that a correct implementation could never fail. This makes the public API clunkier, especially if/when all possible bugs are shaken out or their absence proved one way or another.
I'm guessing this kind of tradeoff is why (most?) indexing operations in Rust return the value instead of an Option/Result/etc - perhaps the team judged that most of the time users have some other way of guaranteeing success (e.g., checking indices) so panicking on failure better fits/streamlines the needs/use cases of most users rather than forcing them to constantly deal with an Option/Result/etc., especially since get()/etc. exists for those users who do want an infalliable option.
Presumably the author(s) of the library/libraries you're using made a similar judgement - while it's possible to write code in the way you desire, perhaps it just wasn't worth the bother for them and/or most of their users.
In other words, "every bug should be an error, and every failure should be an error." Except in order to make every bug be an error, you have to, well, know about every bug. And now all of your implementation details leak out into your public API errors.
Not exactly. It is more like if a library is gonna crash the program (the deep dependencies used in that library triggered a panic on its own), just to let the programmer know it before happens; thus allowing the programmer to try alternatives for to avoid it, and if it's inexorable after those tries, for procedures for a controlled shutdown with proper protocols, actions, and so on.
I mean, as the crash is not exposed in the public API, given the things, I think it might not matter if this signal is exposed or not.
By the public API then, may be a language generalized Err(panicked) through Result, nothing more as it is about the request cannot be accomplished at all (target/debug would tell), or may be someone thought on simpler tip through compiler or other thing. I humbly do not know what approach would be simpler, efficient or less intrusive, I would embrace anything to avoid sudden crash.
The juxtaposition between this comment where you seem to have absolutely no idea what you're talking about, and the certainty with which your initial comment was expressed is really quite something.
My initial comment was: So much correctness in the Rust language just for to promote to all the community to crash the program from libraries without handling the error is something I can not understand.
Empathy tone changed in such last message which you are ridiculing, it is the point within all my comments, the behavior of a --release.
I should not have had dialogue as the things are not going to change. What I take with me is to think on alternative for panic/unwrap is something only come from ignorance, the best is to crash a program without let the programmer nor the final user to blink; to think in a different behavior in Rust is ridiculous. This is what is really quite something.
For references/documentation/tutorials I think the use of unwrap() and friends is a tradeoff. It (arguably) allows for more focused/self-contained examples that better showcase a particular aspect, though with the risk that a reader uses those examples as-is without taking other factors into consideration. There's also the fact that documentation examples can be used as tests, in which case use of unwrap() in docs/examples/etc. is arguably a good thing.
> And at same time by not being actively promoted that such methods should not be used within a library runtime or similar at least, because many people do not see it as wrong, what convert it in philosophy I guess.
I think it might depend on where you're looking. For example, the Rust book has a section titled "To panic! or Not to panic!" [0] which outlines some things to consider when deciding whether to panic/call unwrap()/etc. Not sure if that counts as active promotion, but the fact it's in official docs should count for something at least.
> IMHO they can't be genuine if a lib can panic the program
I feel this is a rather strong position to take. Given how panics are intended to be used (handling unexpected state/precondition violations/etc.), it seems it seems akin to saying "just don't write bugs", which would certainly be nice but isn't really realistic for the vast majority of development. I suppose one could hypothetically bubble up every possible error but that comes with its own maintainability/readability/etc. costs.
In addition, that stance seems similar to stating that there's no "genuine" assertion failures or similar in libraries, which seems... bold? What would the alternative be?
> or if it was just a unfinished prototyping part or etc
At least in Rust there's todo!() and unimplemented!() which more directly convey meaning.
[0]: https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-pa...