5 ms·

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.
            • tgb 6y ago
              That makes sense, thanks.
            • thomasahle 6y ago
              That's what I thought I said in the original comment. I wonder what people disliked.
  • 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