Sometimes, you _know_ that something will be valid. Rust has an unwrap method that does the same as get does, and legitimate uses of it come in cases like this:
use std::net::Ipv4Addr;
fn main() {
let addr: Ipv4Addr = "0.0.0.0".parse().unwrap();
}
Here, I _know_ that the call to `parse()` will always succeed. More verbose handling isn't helpful.
(We almost changed unwrap to assert to make it even more clear, but not everyone agreed that it was more clear)
In this specific case, sure. But it's not really about this specific case; it's about the general idea of "I know that this won't fail, even though you, the compiler, do not." Unless you have full-on dependent types, (and even then), there's going to be times where that's true; it's the nature of type systems. They have to be conservative, there will always be valid programs that are not expressible.
I feel like that's just a special case of casting and so should be handled by casting. You can always cast Optional to Some, can't you? It's verbose and dangerous-looking but it should be verbose and dangerous-looking in my book.
It depends on the language. In a language like Rust, direct casts mean "reinterpret these bits", and the two are represented differently, so that wouldn't work. In a less low-level language, then sure, maybe a cast would work for this case. I'm not sure that it's any more verbose or scary looking, though.
In a language like Rust, direct casts mean "reinterpret these bits", and the two are represented differently, so that wouldn't work.
What's the representation of an optional then? Doesn't make use of some generic concept like subclasses or unions? Surely you have a generic syntax for "assume this union is this particular member" or "assume this base class is this particular subclass" or the like?
I'm not sure that it's any more verbose or scary looking, though.
I guess the point is that I want all cast-like operations to look alike (or at least to have a way to consistently distinguish them from ordinary methods) so that I can flag them all up consistently in code reviews, linters etc.
It's a tagged union. Sometimes the tag can be elided, sometimes not. If you did a direct cast, you'd lose the tag. More specifically though, layout is undefined, so you don't know if the tag is first or last, strictly speaking.
It's a tagged union. Sometimes the tag can be elided, sometimes not. If you did a direct cast, you'd lose the tag. More specifically though, layout is undefined, so you don't know if the tag is first or last, strictly speaking.
Do you not have a generic syntax for unwrapping a tagged union, forcibly assuming that it's one particular component? That seems like something users would want.
Maybe your issue is that the `get` method in Java sounds pretty innocuous, but in Rust the `unwrap` method is notorious. Every Rust user knows that it can panic. Requiring a match would increase verbosity and decrease clarity.
What if we decide that adding IP literals to the language isn't worth the complexity?
In practice, "add a new language feature" isn't a real solution for programmers who need to get the job done. Static type systems always have limitations. You need to be able to circumvent the type system if it isn't expressive enough for your use case.
Comments
Sometimes, you _know_ that something will be valid. Rust has an unwrap method that does the same as get does, and legitimate uses of it come in cases like this:
Here, I _know_ that the call to `parse()` will always succeed. More verbose handling isn't helpful.(We almost changed unwrap to assert to make it even more clear, but not everyone agreed that it was more clear)
Sounds like you want IP address literals (or more generally custom literals). If it's safe because everything's static, then, uh, make it static.
In this specific case, sure. But it's not really about this specific case; it's about the general idea of "I know that this won't fail, even though you, the compiler, do not." Unless you have full-on dependent types, (and even then), there's going to be times where that's true; it's the nature of type systems. They have to be conservative, there will always be valid programs that are not expressible.
I feel like that's just a special case of casting and so should be handled by casting. You can always cast Optional to Some, can't you? It's verbose and dangerous-looking but it should be verbose and dangerous-looking in my book.
It depends on the language. In a language like Rust, direct casts mean "reinterpret these bits", and the two are represented differently, so that wouldn't work. In a less low-level language, then sure, maybe a cast would work for this case. I'm not sure that it's any more verbose or scary looking, though.
What's the representation of an optional then? Doesn't make use of some generic concept like subclasses or unions? Surely you have a generic syntax for "assume this union is this particular member" or "assume this base class is this particular subclass" or the like?
I guess the point is that I want all cast-like operations to look alike (or at least to have a way to consistently distinguish them from ordinary methods) so that I can flag them all up consistently in code reviews, linters etc.
It's a tagged union. Sometimes the tag can be elided, sometimes not. If you did a direct cast, you'd lose the tag. More specifically though, layout is undefined, so you don't know if the tag is first or last, strictly speaking.
Lints for unwrap already exist :)
Do you not have a generic syntax for unwrapping a tagged union, forcibly assuming that it's one particular component? That seems like something users would want.
That is exactly what unwrap() is...
(More specifically, it's a method which uses `match` internally to do this)
Ok, so I'm advocating forcing users to always use match directly if they want to do that. That helps ensure unsafe code looks unsafe.
Maybe your issue is that the `get` method in Java sounds pretty innocuous, but in Rust the `unwrap` method is notorious. Every Rust user knows that it can panic. Requiring a match would increase verbosity and decrease clarity.
Why add a language feature when a library feature does the same thing?
Hey, it worked for try!()/?
What if we decide that adding IP literals to the language isn't worth the complexity?
In practice, "add a new language feature" isn't a real solution for programmers who need to get the job done. Static type systems always have limitations. You need to be able to circumvent the type system if it isn't expressive enough for your use case.
Sure - you need casts or a similar feature. You don't need standard library methods that do casts, though, and having them invites trouble IMO.
Library methods are preferable to added language complexity.
You need the language functionality of casting anyway, no? Best that there's one and only one way to step around the type system.
No, you need pattern matching, which does not offer a convenient way to write Option.get().