No, it's entirely possible to forget. That should be obvious. It is a functional necessity for you to be able to forget as you can only type so much at a time. You cannot possibly write code to call a function and perform pattern matching on the result at the exact same moment in time. There fundamentally has to be a period of time where the work will be incomplete, which opens the opportunity to not finish. It should be abundantly apparent to you that that you can forget to finish what you started in such a scenario.
Your checks and balances will alert you of your forgetfulness, but that's true of all languages. The biggest risk is that you will forget to define behaviour. But if you fail to do that, you've got problems even in languages with pattern matching and associated types. ADTs/enums/unions/pattern matching. are not sufficient to define behaviour. Not even close.
Like you said, pattern matching only helps you with checking errors. But there is no reason to check errors in the first place if you don't do something with the error, and for that you need to document what the error condition means for the user. Otherwise you have undefined behaviour. And once you've documented the behaviour, the error checks are confirmed for free anyway. You can't forget. The checks and balances will make it known, spectacularly.
What, exactly, are you trying to accomplish by overselling what is already a fantastic feature by its own merits on the basis of something that isn't at all realistic? If you want to get developers excited about the feature, there are way more compelling attributes to extol!
I have read this exact claim before, for what it is worth. Did you end up here simply because you repeated what you saw elsewhere without actually thinking about it?
With a separate error value, like in Go, that's no longer the case. The code for handling the error and the code for doing something with the payload are totally separate, and don't both need to be present.
Consider:
func GetData() (*Data, error)
Success/failure values are logically intertwined by convention in some other languages, but you can't reasonably take idioms from other languages and slap them down on Go like that. Just as you cannot reasonably do so in reverse. Different languages express things differently. That's what makes them different.
Is that the disconnect here? That you believe all languages share the exact same idioms?
But you've been making arguments like the following:
> Like in the same way you might forget to write pattern matching code?
> No, it's entirely possible to forget. That should be obvious. It is a functional necessity for you to be able to forget as you can only type so much at a time. You cannot possibly write code to call a function and perform pattern matching on the result at the exact same moment in time.
And that is just disingenous. That's not you having a different opinion on something that's a matter of taste. That's you repeatedly trying to suggest that both forms of error handling are equally likely to suffer from somebody accidentally failing to handle the error.
And obviously that's not true, exactly because the returned values are logically separate in Go and aren't in the other lanuages. That is, in typical Go code, if you assign the error to err but omit the if err != nil {} boilerplate, the code will typically compile. (It'll compile, because the error variable is basically always named err, and most functions will have other references to that variable, such that the "unused variable" compiler diagnostics don't trigger.)
It may compile, but won't pass the test. Are you under the impression that a developer suddenly becomes blind after compilation and somehow magically won't see that the test failed? That doesn't happen. How are you going to forget? In reality, your forgetfulness is going to be made loud and clear. –– We offered a challenge to another account. He failed miserably, as did I, but maybe you can do better? https://www.hackerneue.com/item?id=42865349
And, before you even think it, no, you cannot skip that test in another language with pattern matching. There is nothing pattern matching can do to help you with what it is testing. It should be obvious to you that even if you do successfully pattern match, you might, for example, "forget" to return the right value. The documentation and additional checks and balances are required either way. The type system does not save you here.
And, before you even think it, no, "but what if I am a dummy who doesn't understand his tools or how to program???" doesn't work either as if you are that dummy then you aren't going to use the right types to activate the pattern matching semantics of which we speak, so pattern matching is not going to notice anyway. There is a necessary assumption in this discussion that you understand the tools, idioms, and software engineering in general. We cannot even meaningfully talk about pattern matching alone without that assumption.
So, how are you going to forget, exactly? You won't. This isn't a real thing. Pattern matching is cool, though, with many real benefits. It is funny that someone decided to focus on a made up benefit instead of what makes it actually great. But this is a commonly repeated trope so I'm sure we got here because he blindly repeated it without thinking about it for even a millisecond.
I can't tell if you're being intentionally obtuse. It behooves you to research the topic being discussed, instead of writing long-winded snarky posts.
It is not worth continuing this discussion unless you can demonstrate, with explicit code examples, what you think we're talking about, and why you believe it is incorrect.
func foo(bar func() error) bool {
err := bar()
if err != nil {
return true
}
return false
}
func TestFooReturnsTrueWhenBarReturnsError(t *testing.T) {
if foo(func() error { return nil }) {
t.Error("expected foo to return false")
}
if !foo(func() error { return errors.New("error") }) {
t.Error("expected foo to return true")
}
}
This https://go.dev/play/p/k8zDQj5knaj is what I envision you are talking about, but clearly that cannot be it. As you can see it loudly proclaims that I "forgot", making this forgetfulness idea you have come up with impossible. So, what it is that you actually have in mind?
Provide an example backing up your claim regarding pattern matching + union types:
> Like in the same way you might forget to write pattern matching code?
That is exactly what is being discussed. Why would the topic arbitrarily change? In case you have forgotten, my literal question/assertion was:
"How would you forget, exactly? Your tests are going to blow in your face should you ever leave out an entire feature from the implementation."
Go on, show us: How would you forget?
> Provide an example backing up your claim regarding pattern matching + union types:
Uh... Okay. Sure? Strange request, but here is an example in CrabLang that meets your ask:
let result = foo();
match result {
Ok(value) => println!("Result: {}", value),
}
Like I said in the full comment that you quoted from, you'll soon recognize your forgetfulness once you apply your checks and balances, but for that brief moment in between it is possible to forget. It must be that way else it would be impossible to input the program. If that's what you think we're talking about... Why? And let me ask again like I did in the comment you quoted from: What is the significance of that? If you had carried that quote through you'd also see: "That's not a real problem." I stand by that. Why not you?
In your CrabLang example, you don't have warnings on (I assume they exist) for completion or whatever. There's still the Err case that should at least throw a warning for not being caught.
This is a lengthy response to seemingly ignore, or miss, the point being made.
It is literally impossible to "forget" if you have pattern matching + algebraic data types/enum/unions. Conversely, it is possible and easy with Go.
Nothing you have said acknowledges this.