Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust 1.46

blog.rust-lang.org

Post reply on HN
Print view View original

81–90 of 157 posts

Re: Rust 1.46

#81

Post by marton78 »

phire wrote: post #45
marricks wrote: post #41

Earlier quoted context omitted.

I wonder why && and || are not allowed in const functions? > All boolean operators except for && and || which are banned since they are short-circuiting. I guess I'm missing something obvious but why does the short circuiting break const-ness?

Short circuiting introduces conditional branching. If you call a function on the right hand side of a || or && it might or might not be executed depending on the value of the left hand side. Until this version of rust, all conditional branches were banned from const functions. I guess to keep things simple they just banned any feature that might cause branching.

Why is branching a problem? Since `if` is now enabled in a const fn, it's trivial to rewrite && with & and if.

Re: Rust 1.46

#82

Post by steveklabnik »

kibwen wrote: post #79
steveklabnik wrote: post #51

Earlier quoted context omitted.

From way back in 2013, a HN thread https://news.ycombinator.com/item?id=6940624 Sadly it looks like the wayback machine does not have a copy of the original. Does anyone know how to get one?

Gmane was just a nice interface for reading mailing lists, in this case it was just referring to some thread on the old rust-dev mailing list, which is archived at https://mail.mozilla.org/pipermail/rust-dev/ . Sadly I can't tell exactly which thread it was, but I'm guessing it was https://mail.mozilla.org/pipermail/rust-dev/2013-January/002... . (Niko also once wrote a blog post which gives an overview of the old pu…

I knew it was, but couldn't find a rust-dev post with "pure" in the same time-frame. Thank you! Yours may be it, but I think est has a convincing case that it was the thread this one spun out from...

Thanks for that link to Niko's blog too!

Re: Rust 1.46

#83

Post by smabie »

kumarvvr wrote: post #19

So, I want to learn Rust. I am a C# / Python programmer, experienced. Are there any particular set of problems that I can solve systematically, so that I can learn all the features of Rust?

Write a chip8 emulator in Rust.

Re: Rust 1.46

#84

Post by BiosElement »

kumarvvr wrote: post #19

So, I want to learn Rust. I am a C# / Python programmer, experienced. Are there any particular set of problems that I can solve systematically, so that I can learn all the features of Rust?

You might check out https://exercism.io/tracks/rust . Some are a little heavy in the math department but personally I've always found test drive learning useful when learning a new language thanks to instant feedback.

Re: Rust 1.46

#85

Post by kibwen »

marton78 wrote: post #81
phire wrote: post #45

Earlier quoted context omitted.

Short circuiting introduces conditional branching. If you call a function on the right hand side of a || or && it might or might not be executed depending on the value of the left hand side. Until this version of rust, all conditional branches were banned from const functions. I guess to keep things simple they just banned any feature that might cause branching.

Why is branching a problem? Since `if` is now enabled in a const fn, it's trivial to rewrite && with & and if.

`if` wasn't enabled before, so `&&` wasn't enabled. Now that `if` is enabled, `&&` now works too.

Re: Rust 1.46

#86

Post by jedisct1 »

nemothekid wrote: post #35
sfvisser wrote: post #6

I’m learning rust right now and there is a lot to like. Steady updates like this are also very motivating. The ecosystem feels very sane - especially compared to npm. Top notch Wasm support, cross compiling is a breeze. That said, coming from a FP background (mostly Haskell/JS, now TS) Rust is... hard. I do understand the basic rules of the borrow checker, I do conceptually understand lifetimes, but actually using th…

> the borrow checker, I do conceptually understand lifetimes, but actually using them is tricky. I've been using Rust for a little over year, almost daily at work, and for several projects. I have a pretty good intuition about how the borrow checker works and what needs to be done to appease it. That said, I don't think I'm any closer to understanding lifetimes. I know conceptually how they are supposed to work (I ne…

I've been writing Rust code since before the 1.0 days, and I still can't understand lifetimes in practice.

When the compiler starts complaining about lifetimes issues, I tend to make everything clone()able (either using Rc, or Arc, or Arc+Mutex, or full clones).

Because if you start introducing explicit lifetimes somewhere, these changes are going to cascade, and tons of annotations will need to be added to everything using these types, and their dependent types.

Re: Rust 1.46

#87

Post by Filligree »

marricks wrote: post #49
phire wrote: post #45

Earlier quoted context omitted.

Short circuiting introduces conditional branching. If you call a function on the right hand side of a || or && it might or might not be executed depending on the value of the left hand side. Until this version of rust, all conditional branches were banned from const functions. I guess to keep things simple they just banned any feature that might cause branching.

Ahh that makes a lot of sense, if you're going to have a compiler insert the result of a function having conditional branching seems a bit gnarly I guess?

It's conditional based on what's ultimately constant data, so you end up with predictable output regardless.

Re: Rust 1.46

#88

Post by eloff »

tgb wrote: post #69
eloff wrote: post #67

Earlier quoted context omitted.

The parent didn't specify calling with constant parameters, which makes a huge difference. To answer your question, basically anything the compiler doesn't know how to evaluate - which has been expanded in this release, but does not include everything still.

Looks like we have some terminology confusion. I read mijamo's question as being about the theoretical ability to evaluate at compile time (the value is knowable) not whether the compiler does do it, and that's what I meant in my comment too. If you say that 'pure' functions are not compile-time-evaluatable because they may be given parameters that are not known at compile time, then you must also say that const fns…

I think that's it in a nutshell. You can't evaluate everything at compile time, even when you could theoretically. So you need some way to mark the subset of pure functions that can be evaluated at compile time, which is what const fn does. That way if a const fn only calls other const functions you know you can evaluate it. It's a convenient way of tagging functions.

Re: Rust 1.46

#89

Post by shepmaster »

jandrese wrote: post #70
kumarvvr wrote: post #19

So, I want to learn Rust. I am a C# / Python programmer, experienced. Are there any particular set of problems that I can solve systematically, so that I can learn all the features of Rust?

One thing I'd be wary of is Googling error messages and taking answers from Stack Exchange. Rust has mutated (heh) a fair bit over the years and many SE answers to noob problems are obsolete and sometimes incorrect. At the very least check the datestamp on any answer and be wary of anything more than a year or two old. This goes double if the answer has some extremely awkward looking syntax with lots of modifiers and…

I literally spend tens of hours a week on Stack Overflow ensuring this isn’t the case, or if it is that it’s clearly notated.

As always, feel free to drop into the Rust Stack Overflow chat room[1], or any of the official Rust discussion channels, and ping me or other Stack Overflow contributors to review and update answers.

1: https://chat.stackoverflow.com/rooms/62927/rust

Re: Rust 1.46

#90

Post by tgb »

eloff wrote: post #88
tgb wrote: post #69

Earlier quoted context omitted.

Looks like we have some terminology confusion. I read mijamo's question as being about the theoretical ability to evaluate at compile time (the value is knowable) not whether the compiler does do it, and that's what I meant in my comment too. If you say that 'pure' functions are not compile-time-evaluatable because they may be given parameters that are not known at compile time, then you must also say that const fns…

I think that's it in a nutshell. You can't evaluate everything at compile time, even when you could theoretically. So you need some way to mark the subset of pure functions that can be evaluated at compile time, which is what const fn does. That way if a const fn only calls other const functions you know you can evaluate it. It's a convenient way of tagging functions.

That makes sense, thanks.
Post reply on HN