6 ms·

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

If anyone wants to know more about const fns, see https://doc.rust-lang.org/reference/items/functions.html#const-functions 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 6y ago
Never worked with Rust, but I am pretty sure that having a function be pure is not enough to evaluate it at compile time.
- deleted 6y ago
  [deleted]
- steveklabnik 6y ago
  Yes, we don't actually use the "pure" terminology for this reason.
- mijamo 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
        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 6y ago
        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?
        eloff 6y ago
        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.
  - ko27 6y ago
    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 https://en.wikipedia.org/wiki/Pure_function
the_duke 6y ago
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 6y ago
An interesting history note: Rust used to have an effects system which included actually being able to annotate a function as pure.
- steveklabnik 6y ago
  From way back in 2013, a HN thread https://news.ycombinator.com/item?id=6940624 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?
  - est31 6y ago
    Alright this sent me down a rabbit hole. The URL is: http://thread.gmane.org/gmane.comp.lang.rust.devel/3674/focus=3855 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/rust-dev@mozilla.org/ https://www.mail-archive.com/rust-dev@mozilla.org/ https://mail.mozilla.org/pipermail/rust-dev/ 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.comp.lang.rust.devel/* http://web.archive.org/web/*/http://article.gmane.org/gmane.... http://web.archive.org/web/20140723013539/http://article.gmane.org/gmane.comp.lang.rust.devel/6778/match=dst http://web.archive.org/web/20140723013539/http://article.gma... http://web.archive.org/web/20140719142224/http://article.gmane.org/gmane.comp.lang.rust.devel/9466 http://web.archive.org/web/20140719142224/http://article.gma... http://web.archive.org/web/20141225073140/http://article.gmane.org/gmane.comp.lang.rust.devel/10449 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/rust-dev@mozilla.org/msg06831.html https://www.mail-archive.com/rust-dev@mozilla.org/msg06831.h... https://www.mail-archive.com/rust-dev@mozilla.org/msg09516.html https://www.mail-archive.com/rust-dev@mozilla.org/msg09516.h... https://www.mail-archive.com/rust-dev@mozilla.org/msg10494.html https://www.mail-archive.com/rust-dev@mozilla.org/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 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_rust_ditched_pure_functions/ 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&q=max+cantor+pure https://www.mail-archive.com/search?l=rust-dev%40mozilla.org... This is the E-Mail: https://www.mail-archive.com/rust-dev@mozilla.org/msg03913.html https://www.mail-archive.com/rust-dev@mozilla.org/msg03913.h... https://mail.mozilla.org/pipermail/rust-dev/2013-April/003926.html 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-archive.com/rust-dev@mozilla.org/msg03913.html 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/rust-dev@mozilla.org/msg04653.html https://www.mail-archive.com/rust-dev@mozilla.org/msg04653.h... https://news.ycombinator.com/item?id=5986985 https://news.ycombinator.com/item?id=5986985

ko27 6y ago

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

deleted 6y ago
[deleted]
steveklabnik 6y ago
Yes, we don't actually use the "pure" terminology for this reason.
mijamo 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
        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?
        eloff 6y ago
        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.
- ko27 6y ago
  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 https://en.wikipedia.org/wiki/Pure_function

the_duke 6y ago

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 6y ago

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

steveklabnik 6y ago
From way back in 2013, a HN thread https://news.ycombinator.com/item?id=6940624 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?
- est31 6y ago
  Alright this sent me down a rabbit hole. The URL is: http://thread.gmane.org/gmane.comp.lang.rust.devel/3674/focus=3855 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/rust-dev@mozilla.org/ https://www.mail-archive.com/rust-dev@mozilla.org/ https://mail.mozilla.org/pipermail/rust-dev/ 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.comp.lang.rust.devel/* http://web.archive.org/web/*/http://article.gmane.org/gmane.... http://web.archive.org/web/20140723013539/http://article.gmane.org/gmane.comp.lang.rust.devel/6778/match=dst http://web.archive.org/web/20140723013539/http://article.gma... http://web.archive.org/web/20140719142224/http://article.gmane.org/gmane.comp.lang.rust.devel/9466 http://web.archive.org/web/20140719142224/http://article.gma... http://web.archive.org/web/20141225073140/http://article.gmane.org/gmane.comp.lang.rust.devel/10449 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/rust-dev@mozilla.org/msg06831.html https://www.mail-archive.com/rust-dev@mozilla.org/msg06831.h... https://www.mail-archive.com/rust-dev@mozilla.org/msg09516.html https://www.mail-archive.com/rust-dev@mozilla.org/msg09516.h... https://www.mail-archive.com/rust-dev@mozilla.org/msg10494.html https://www.mail-archive.com/rust-dev@mozilla.org/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 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_rust_ditched_pure_functions/ 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&q=max+cantor+pure https://www.mail-archive.com/search?l=rust-dev%40mozilla.org... This is the E-Mail: https://www.mail-archive.com/rust-dev@mozilla.org/msg03913.html https://www.mail-archive.com/rust-dev@mozilla.org/msg03913.h... https://mail.mozilla.org/pipermail/rust-dev/2013-April/003926.html 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-archive.com/rust-dev@mozilla.org/msg03913.html 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/rust-dev@mozilla.org/msg04653.html https://www.mail-archive.com/rust-dev@mozilla.org/msg04653.h... https://news.ycombinator.com/item?id=5986985 https://news.ycombinator.com/item?id=5986985