Hacker News Reader

Comment by Nican | Hacker News Reader

For example, on C#, I sometimes have to do:

  var value = (await (await startRequest()).GetBody()).Root;

While the Rust syntax would make this a little more clear, I do not think it is a dealbreaker.

View on HN

For ease of comparison, here's how that would look with syntax akin to Rust's choice:

    var value = startRequest().await.getBody().await.Root;

Assuming these are failable actions then this would probably end up looking like

  var value = startRequest.await?.getBody().await?.Root;

While we are doing comparisons, here is the Promise version:

    startRequest()
        .then(req => req.getBody())
        .then(body => { value = body.Root })

Please don't do that. I had to look several times to rewrite it as

    var temp1 = await StartRequest();
    var temp2 = await temp1.GetBody();
    var value = temp2.Root;

which is instantly grokked.

There are a few different ways I feel about this at the same time:

- On the one hand, I agree that "interesting" operations really should be on their own lines. I think I'm going to strongly prefer to keep it to one `await` per line for the foreseeable future.

- On the other hand, I know that many programmers will cram a lot of operations into one line if they can, and when that inevitably happens it would be nice for it to be readable.

- And maybe in the long run, it's possible that a big, mature async ecosystem might make a lot of these operations so commonplace that they aren't "interesting" anymore. Maybe in that world we'll be glad to have a syntax that makes it easy to chain things together.

This is a great example of why syntax and semantics can't be separated. This works great in GC'd languages, but in Rust, these two things may not be equivalent. With the distinction between owned and temporary values, this may change the lifetime of what stuff is in scope and when. This is reduced a bit with non-lexical lifetimes, but it's not, strictly speaking, actually equivalent.

I think this is a good example to show people who are on the fence about postfix then. I haven't felt strongly about postfix, but this is an eye opener for me.

It's a better case for showing how to use .map().

Yeah, I think the trick is that the theory and practice might be the same. And usually, it's the other way around; spreading it out makes it work, whereas it may not otherwise. For example:

    fn main() {
        let world = gives_string().split(" ").next();
        
        println!("{:?}", world);
    }
    
    fn gives_string() -> String {
        String::from("hello world")
    }

This will fail because the String is temporary, and we're trying to get a reference to it (via split), and so it would be deallocated at the end of the line, being a use-after-free. This, however, compiles:

    fn main() {
        let world = gives_string();
        let world = world.split(" ").next();
        
        println!("{:?}", world);
    }
    
    fn gives_string() -> String {
        String::from("hello world")
    }

We're shadowing 'world', but the underlying String now lives to the end of main, so everything works, no more use-after free.

I think before I'd want a good real-world example of where doing the multi-line thing goes wrong before I'd want to make an argument that this is why postfix is better.

This has surprised me on occasion. Shouldn't the compiler be smart enough to figure out how long to keep it around for, instead of failing to compile?

One could argue that the compiler could transform this for you. But systems languages are also about control. For someone versed in the way things are supposed to work, an owned value living longer than it should is surprising.

Tradeoffs, tradeoffs.

The compiler is smart enough to deduce lifetimes — that’s why it can throw a compile error — but fixing them (auto-keeping temporaries) might introduce extra memory consumption/leaks that the programmer did not intend. Requiring the programmer to explicitly assign a temporary to a variable makes the programmer’s intent more clear.

A comparison: in C++, the behavior of auto-extending the lifetime of const references to temporaries (but not non-const references) is considered a wart in the language design. (Really, you should just assign a temporary to a value because the compiler can elide the copy. : https://abseil.io/tips/101 .)

I totally get where you coming from, and even in non GC'd languages such as C++ lifetimes are extended (or not...) when you break down expression.

However, I also strongly perfer to give these subexpressions names. That tremendously helps when debugging, logging, or just discussing the code with colleagues. In fact, these subexpressions do exist and they are a certain unit to reason about, especially when the program is not doing what it should. In these cases (and not only these) you really want to give them a canonical name and not only "line 42".

Maybe there should be a syntactical equivalent for named subexpressions.

I do too, which is why I preferred prefix await.

This is to my eyes far more cluttered and confusing than:

    var value = StartRequest().await.GetBody().await.Root;

Or if you prefer multiline:

    var value = StartRequest().await.
                GetBody().await.
                Root;

this makes my eyes bleed

Why?

Because you have to read from the inside-out instead of left to right or right to left, most likely.

Reply on news.ycombinator.com