[thomasahle]

If anyone wants to know more about const fns, see https://doc.rust-lang.org/reference/items/functions.html#con...

It is the Rust way of specifying a function as being _pure_. In other words the output is dependent only on the function arguments, and not on any external state.

This means they can be evaluated at compile time. I suppose in the future, it could also allow better compiler optimizations.

[ko27]

Never worked with Rust, but I am pretty sure that having a function be pure is not enough to evaluate it at compile time.

[steveklabnik]

Yes, we don't actually use the "pure" terminology for this reason.

[mijamo]

Why not? By definition the output does not depend on runtime property so you should be able to compute it at compile time right?

[eloff]

Pure functions are functions where the return value only depends on the function arguments. If the function arguments are not known at compile time, obviously you can't evaluate it at compile time. It would only be possible to do that when all the arguments are also known at compile time (constants).

[tgb]

But a const fn can also do that: if given non-constant parameters it will be evaluated at run-time. So I (having never used Rust before) still haven't see the distinction between pure and const. What's an example of a function that is pure but cannot be evaluated at compile time with constant parameters?

[eloff]

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.

[tgb]

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 are not compile-time-evaluatable. I think it's also clear that we mean for const fns to count, so the assumption that the parameters are known at compile time was implicit in the question.

Under those two assumptions: are pure functions evaluatable (in theory) at compile-time (on values known at compile time)? As far as I can think, the answer is yes? In which case, I'm not entirely sure what the distinction between 'pure' and 'cosnt fn' is supposed to be except to separate out the part of 'pure' functions that can are evaluated in practice. Is there anything more to it?

[ko27]

Well, that is not the definition. Output of a pure functions can depend on input arguments, and those arguments can definitely depend on runtime properties.

https://en.wikipedia.org/wiki/Pure_function

[the_duke]

Rust has no notion of purity. This would require something like an effect system.

const functions can't directly do any IO or even allocation - at the moment.

But this can be easily circumvented, eg by using a proc macro that does IO.

Sidenote: even in Haskell the function signature doesn't guarantee purity, due to unsafePerformIO.

[pitterpatter]

An interesting history note: Rust used to have an effects system which included actually being able to annotate a function as pure.

[steveklabnik]

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?

[kibwen]

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 purity system: https://smallcultfollowing.com/babysteps/blog/2012/10/12/ext... )

[steveklabnik]

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!

[est31]

Alright this sent me down a rabbit hole.

The URL is: http://thread.gmane.org/gmane.comp.lang.rust.devel/3674/focu...

I've also seen it without the trailing /focus.

The web interface of gmane.org is down, so the link is not available. Turns out though that the rust-dev mailing list archive is present on both mail.mozilla.org and mail-archive.com, so one only has to find the mail corresponding to the link.

https://www.mail-archive.com/[e-mail]/

https://mail.mozilla.org/pipermail/rust-dev/

Using archive.org's "find all archived websites with this prefix" feature one can obtain a total of three archived e-mails.

http://web.archive.org/web/*/http://article.gmane.org/gmane....

http://web.archive.org/web/20140723013539/http://article.gma...

http://web.archive.org/web/20140719142224/http://article.gma...

http://web.archive.org/web/20141225073140/http://article.gma...

Now, one searches for lines in those e-mails in on mail-archive.com and finds these corresponding links:

https://www.mail-archive.com/[e-mail]/msg06831.h...

https://www.mail-archive.com/[e-mail]/msg09516.h...

https://www.mail-archive.com/[e-mail]/msg10494.h...

Observe that the differences between the two IDs are different each time, namely decreasing: 53, 50, 45

So it's not a constant difference. What to do now?

Let's google the URL! It points towards this hn comment: https://news.ycombinator.com/item?id=7554676

It gives one piece of information: the e-mail was written by Graydon. Similarly, commenters in https://www.reddit.com/r/programming/comments/1t8y6g/why_rus... mention his name, making it very likely that the e-mail was written by him.

Another hint comes from the reddit thread you linked above: someone named maxcan stated they started the thread. Looking up their name plus "pure" gives only e-mails from a single thread, including an e-mail from Graydon: https://www.mail-archive.com/search?l=rust-dev%40mozilla.org...

This is the E-Mail:

https://www.mail-archive.com/[e-mail]/msg03913.h...

https://mail.mozilla.org/pipermail/rust-dev/2013-April/00392...

Also archived it, just to be sure:

http://web.archive.org/web/20200827181214/https://www.mail-a...

It covers precisely the topic you mentioned and is in a thread started by maxcan. I think it's the e-mail we are looking for.

To verify, the difference between the two IDs is either 239, or 58, depending on which of the two numbers in the URL point to the actual E-Mail, but 58 is more likely. The 0.7 release announcement for example has a difference of 57 and is quite close to both:

https://www.mail-archive.com/[e-mail]/msg04653.h...

https://news.ycombinator.com/item?id=5986985

[steveklabnik]

Argh! you are a better sleuth than me. I was looking at that month's rust-dev archives and didn't realize the subject did not have "pure" in it, so I looked right over it.

This is! Thank you so much!