8 ms·

You're misunderstanding. async/await creates a dependence. errors do not – at least no more than any other type. Would you say your perspective on "coloring" is

• littlestymaar 2y ago
  > async/await creates a dependence. errors do not. It does! In both case you need to "unwrap" the value, and in most case it means making the caller function async or returning the error. (As an anecdote I've done way more refactoring involving replacing T with Result<T> in entire call stacks in Rust that I've done it for async). > I might buy into your idea the "?" operator colors functions. But that's something else entirely and obviously isn't what you were talking about originally as it isn't found in all of the languages originally mentioned It's exactly the same with Java's checked exception and Go errors, as soon as you start calling a function that returns an error, you're going to write something that looks like if err != nil { return 0, err } And tada! your functions now need to add the error to it's return parameter.
  • deleted 2y ago
    [deleted]
  • randomdata 2y ago
    > It does! In both case you need to "unwrap" the value Just as you do with any value, such as an email address, returned by a function. It is curious that you avoided my question as it would help us better understand where you are trying to come from. If that is the stance you are trying to take you're not exactly wrong about there still being some sort of dependence – there is an inherit dependency created when calling a function, always - but there is not a different color of dependence found within that. You're missing the intent of "coloring" if that is what you are trying to say. async/await introduces a different type of dependence than a function would normally present, where the dependence is no longer direct. I may even agree that the "?" operator introduces a similar indirect dependence. But a function returning an email address (or error; the type of the value is immaterial) is the "natural color" of a function. If that is all you have, there isn't a secondary color. > as soon as you start calling a function that returns an error, you're going to write something that looks like Only for internet memes. You would never write production code like that for so many reasons.
    • littlestymaar 2y ago
      > you do with any value, such as an email address, returned by a function. It is curious that you avoided my question as it would help us better understand where you are trying to come from I don't understand what you mean with your email address example. If you ask a function for an email address, and you get an email address you don't have to unwrap anything. > You're missing the intent of "coloring" if that is what you are trying to say. I'm not, really. The key thing is that as long as you have some effect (like "an error occurred" or "the execution is suspended while running some IO operation", “this function is allocating”, “this function is impure”, etc.) happening somewhere in the call stack then it infects all the call stack no matter what the language does. (A previously pure function calling an impure one becomes impure, a non-allocating function calling an allocating one becomes allocating itself, etc.) In some language, this effect is visible to the caller by default (but can generally be opted-out) and you have this kind of red/blue split for any effect. In other languages this effect is just hidden (but it still exists on reality), that means less effort annotating your code but also less information when reading other people's code. It's exactly the same tradeoff as typing. > Only for internet memes Not literally like that, but the gist of it still stands, you end up adding an error return value to your functions the vast majority of the time.
      • randomdata 2y ago
        > I don't understand what you mean with your email address example. But you didn't think to ask any followup questions to help with your understanding? > The key thing is that as long as you have some effect [...] happening somewhere in the call stack then it infects all the call stack no matter what the language does. In the same way email addresses do, I suppose. But that is the "natural color" of a function. Consider: fn getEmail() { return "joe@example.com" } fn getPerson() { email = getEmail() return "Joe Blow", email } fn getUser() { name, email = getPerson() return "joeblow123", name, email } fn main() { username, name, email = getUser() print(username, name, email) } Yes, you could say in a sense `getEmail` "infected" `getUser` in its need to get the email address to the top of the stack, but the dependence at each step remains direct. getUser returns an email address because an email address is relevant to the result of `getUser`, not just because it happened to call `getEmail`. That is different to async/await, where `main` now has to become aware of what `getEmail` is doing because `getUser` happened to call it transitively. The dependence is indirect. async fn getEmail() { return background { return "joe@example.com" } } async fn getPerson() { email = await getEmail() return "Joe Blow", email } async fn getUser() { name, email = await getPerson() return "joeblow123", name, email } async fn main() { username, name, email = await getUser() print(username, name, email) } I may be inclined to agree that the "?" operator can introduce a similar indirect dependence: fn producesError() { return ProductionError("an error occurred") } fn doesSomething() { value = producesError()? return true } fn main() { result = doesSomething() match result { ProductionError: print("Error", result) OK: print("OK", ok) } } Like async/await, `main` now has to be aware of what `producesError` is doing without calling it directly. But, then again, much like as we discussed in your Go example, you'd never actually write production code like that. There are so many things wrong with it. So, I'm not sure how significant that coloring actually is. And, regardless, is not related to the original discussion.