There isn’t a universal one. A fun fact is that Activity pub, the protocol that lets these applications communicate on the backend, also has a front-end spec for this exact purpose, but no one has implemented it.

Agreed, that’s what I was trying to say but I’m not great at writing. I’ve seen this in rust and other languages long before llms

I actually disagree, because I’ve both seen it everywhere and I also work mainly in dotnet, and when I’ve talked to people about option and result types, the first inclination is to have a .Value, but that defeats the purpose. I’ve done quite a few code reviews where I was essentially saying “you know this will throw, right? Use .Match or .Map instead”.

I think the imperative programming backgrounds encourage this line of thinking, since one of the first questions I’ve gotten is “how do I get the value out of an Option? I’m 100% sure it’s there.” And often, surprise, it wasn’t.

I feel like I’ve seen an insane number of error messages in various apps and websites around the unwrap method.

But this is on a result type, right? I’d figure the point would be that you would match on it and that the unwrap itself, which if my assumptions are correct, is more like get value or throw, should either not exist or take a default value. You shouldn’t be able to directly get the value of a monad.