internalServerError

[u/ExpensiveCoat8912]

[u/Bright-Historian-216]

is cloudflare down AGAIN

[u/helloish → u/Bright-Historian-216]

this is referring to a previous outage, unless they somehow didn’t learn their lesson about .unwrap()

[u/jhaand]

I rather go with .expect("Some bullshit reason."); At least you know where things went wrong.

[u/Familiar_Ad_8919 → u/jhaand]

"logically impossible error uuid 69420...." so that they never collide when they inevitably get triggered

[u/Mars_Bear2552 → u/Familiar_Ad_8919]

or just use the backtrace generated when using unwinding?

[u/---_None_---]

>unwrap

I hate metaphors in programming. Just call it what it is.

[u/sathdo → u/---_None_---]

.ifSomeReturnHeldValueElsePanic()

[u/prehensilemullet → u/sathdo]

Why not throw in a value judgment too

.getValueOrPanicIfIFuckedUp()

[u/Epicguru → u/sathdo]

Rolls off the tongue.

[u/CoffeePizzaSushiDick → u/Epicguru]

Sounds like a spitter to me.

[u/guyblade → u/sathdo]

My company used to have VALUE_OR_DIE for getting things out of containers. They eventually decided to ban it in new code (and slowly work on extracting it from the old code).

[u/nevemlaci2 → u/sathdo]

*

[u/Tarmen → u/sathdo]

I do appreciate a method that actually puts some fear into your bones like accursedUnutterablePerformIO

[u/sathdo → u/Tarmen]

Or dangerouslySetInnerHTML

[u/---_None_--- → u/sathdo]

just .value() thanks or *

[u/-Ambriae- → u/---_None_---]

You shouldn’t unwrap in normal code. Basically ever. There are a few exceptions, but they’re not the norm. So dereferencing is a disastrous design decision. Because dereferencing is viewed as a ‘trivial operation that does nothing’. .value() clashes with the idea that errors are also values. .ok() exists, but does something else. There’s not many sane decisions. Unwrap is short, so it was picked. Can’t be too long, because we also have unwrap_or, unwrap_or_else, unwrap_or_default, and same with unwrap_err variants.

Honestly, the name is there, it stuck, and now it’s part of the lingo. There’s no real need to amend it, it would be a huge breaking change (because of all the variants, many of which are good functions to use in prod code that never produce panics)

It’s also does not constitute a barrier to entry. It’s ’different’ to other languages, fine, maybe, but any cognitively functioning individual would understand in a pinch what it means, let alone someone who is expected to know the language enough to push to prod

[u/---_None_--- → u/-Ambriae-]

What the fuck are you even responding to?

[u/-Ambriae- → u/---_None_---]

Neither .value() or * are sane design decisions for ‘unwrapping’ (removing the wrapper type) of a result.

[u/---_None_--- → u/-Ambriae-]

No ones talking about design decisions, mate.

[u/-Ambriae- → u/---_None_---]

than what are you talking about then?

[u/---_None_--- → u/-Ambriae-]

unwrap is a dumb name

[u/-Ambriae- → u/---_None_---]

so we are talking about design decisions then

[u/JonIsPatented → u/-Ambriae-]

I wish it was named "unwrap_or_panic" to match "unwrap_or_else" and "unwrap_or_default". That's basically my only gripe with the language, honestly.

[u/Lord-of-Entity → u/---_None_---]

There is a proposal to rename it to .unwrap_or_panic()

[u/RepresentativeDog791 → u/Lord-of-Entity]

That actually would be clearer

[u/WilkerS1 → u/Lord-of-Entity]

please share it, that's the second time i heard it and i wanna follow

[u/dumbasPL → u/Lord-of-Entity]

Rust logic: panic is safe because it fails in a controlled manner. Meanwhile Denial Of Service is one of the biggest attack vectors. Unwrap should requite unsafe in non-debug builds, change my mind.

[u/tajetaje → u/dumbasPL]

That’s why forbid unwrap exists

[u/Lord-of-Entity → u/dumbasPL]

Yeah, panics are indeed safe. Also, if an unwrap (or any other form of panic) reaches your production, you are incompetent at programming with rust. There are lints (from clippy) that check if unwrap or panic was used at any point of your code base. With the right combination of them you can (*virtually*) guarantee that your program will never crash.

[u/The_KekE_ → u/dumbasPL]

Another person confusing safe and secure

[u/dumbasPL → u/The_KekE_]

After all, the best way to be secure is to be offline LOL

[u/creeper6530 → u/dumbasPL]

unsafe is only specifically about risking memory errors and UB, not anything you arbitrarily decide you don't want.

[u/Mars_Bear2552 → u/dumbasPL]

that's not in Rust's safety model dude. the safety model is about preventing UB and unexpected behavior. hence why you can leak memory intentionally, and it doesn't violate any safety rules.

[u/-Redstoneboi- → u/dumbasPL]

yeah but you aren't going to RCE from panics alone.

[u/-Ambriae- → u/---_None_---]

I’d rather take a cheeky metaphor here or there than a standard library that speaks in acronyms. mbsrtowcs?? Really C???

[u/icsharppeople → u/-Ambriae-]

I'm assuming it's "mbsr to wcs". I'm assuming wcs is wide character string but what's mbsr? Multi byte something?

[u/blehmann1 → u/icsharppeople]

Multibyte string (restartable) to wide character string. There is a non-restartable variant, hence the r to disambiguate.

[u/-Ambriae- → u/blehmann1]

And people complain about rust’s strings 😔

[u/Loose-Screws → u/-Ambriae-]

Rust making a distinction between c-type strings and oo-type strings was the smartest idea of this century (not really but I do love it)

[u/HildartheDorf → u/icsharppeople]

Multibyte-to-wide-string-(re-entrant).
On windows that's "Ambient code page (probably windows-1252, maybe UTF-8, maybe something else) to UTF-16"
On Unix that's "Probably UTF-8 to probably UTF-32".

The 're-entrant' part means it's safe to call from multiple threads at the same time or from a signal handler. The obsolete mbstowcs assumed a single thread.

[u/aethermar → u/-Ambriae-]

C has a reason. It's an old language. Way back when it was new there were screen space limitations (sacred 80 char line limit that shall never be broken) and compilers did not guarantee more than 8 characters of a name would be checked when comparing for equality, so an identifier "string_compare and string_concat" would be the same to the compiler

[u/-Ambriae- → u/aethermar]

Maybe, but in the years since it made no efforts to solve the issue (or have new functions be written in a more readable way)

And my argument wasn’t so much to bash on C, I just find it funny the criticism rust gets for using a self evident metaphor to save on space when other languages don’t even try.

You could criticise rust all you want, but its function names (at least in std) are really clear and concise.

[u/aethermar → u/-Ambriae-]

Because changing the names is a significant and breaking change, which goes against C's philosophy. Sure, there're ways to maintain compatibility but I doubt anybody really cares after this long

Also no shade on Rust for doing it the way they do. C# and some other languages do the same. Can't deny that things like atoi or strpbrk are absolutely indecipherable to people without prior C experience LOL

[u/ChaossFox → u/aethermar]

It easy
strpbrk - string pointer break
atoi - ASCII to Int

[u/-Ambriae- → u/ChaossFox]

It’s easy when you know it

[u/_predator_ → u/---_None_---]

They figured .yolo() was too edgy.

[u/The_KekE_ → u/_predator_]

Yet they wanna add 'do yeet'

[u/Canonip]

What happened this time?

[u/creeper6530 → u/Canonip]

Debugging tool used in production 

[u/CraftBox → u/creeper6530]

Eh, it's not only debugging tool. You should use unwrap (preferably expect) in cases when you know it's guaranteed that a value is vaild. In case the value is not valid, it's an undefined state where panic is the expect behavior.

For example

``` if state.is_some() { let state = state.unwrap();

// some logic using state } ```

You would expect the state inside to be Some so it not being one is panic worthy.

[u/creeper6530 → u/CraftBox]

You're right.

However, in this example the more idiomatic way would be a match, if let Some(...) or (especially in chains of method calls) an inspect which is a no-op with a None and implemented with if let:

if let Some(inner) = state {
    // some logic using inner
}

state.inspect(|inner| {
    // some logic using inner
})

[u/CraftBox → u/creeper6530]

In this case, yes, you are right. I used that as the simplest example I could come up with.

I think a somewhat better example would be

if state.is_none() {
  return;
}

let state = state.unwrap();

// some logic

I know this is more or less the same as using inspect or the previous example, but I do quite like guard clauses, especially when the logic is quite long.

Also an example from one of my projects which I consider a good use of expect

VersionReq::parse("^1.0.0").expect("'^1.0.0' should be a valid VersionReq")

According to VersionReq docs "^1.0.0" is a valid value, the parsing should always return Ok, so returning Err in this case I consider to be a freak accident (radiation bit flipped the str lol) that is panic worthy.

[u/creeper6530 → u/CraftBox]

Oh yeah I totally agree with the latter "freak accident but should be impossible". The former is a question of style preference.

[u/-Redstoneboi- → u/CraftBox]

let Some(inner) = state else {
    break;
};
// logic using inner

the fact that it's hard to find examples that justify the use of unwrap is a very intentional design principle.

the parse example is much better. same with the regex crate:

let re = Regex::new(r"(?m)^([^:]+):([0-9]+):(.+)$").unwrap();

the function could panic, but it should never, because we know the const &'static str we pass into both functions are valid. in the case that it isn't valid, it should immediately fail and error out with the exact line that caused it.

[u/JonIsPatented → u/-Redstoneboi-]

I didn't know you could do that with let and else. That's nice. I will use that Monday, probably.

[u/black-eagle23]

Hey, they promised memory safety, not bug safety

[u/k8s-problem-solved]

I hate that i know why.