replace function with const var for better readability

[tao-stones]

Problem

const fn foo() isn't as readable as const FOO

Summary of Changes

To use const VAR, no functional change

Fixes #

[codecov]

Codecov Report

Merging #19285 (00ed438) into master (3945908) will decrease coverage by 0.0%.
The diff coverage is 100.0%.

@@            Coverage Diff            @@
##           master   #19285     +/-   ##
=========================================
- Coverage    82.9%    82.8%   -0.1%     
=========================================
  Files         458      457      -1     
  Lines      130813   130793     -20     
=========================================
- Hits       108461   108365     -96     
- Misses      22352    22428     +76     

[steviez]

For the sake of capturing our quick chat the other day (and partially for confirming my understanding) ...

A couple chunks from the Rust reference,

Certain forms of expressions, called constant expressions, can be evaluated at compile time. In const contexts, these are the only allowed expressions, and are always evaluated at compile time. In other places, such as let statements, constant expressions may be, but are not guaranteed to be, evaluated at compile time

The following expressions are constant expressions, so long as any operands are also constant expressions and do not cause any Drop::drop calls to be run.

• Literals.
• ...
• Built-in negation, arithmetic, logical, comparison or lazy boolean operators used on integer and floating point types, bool, and char.

A const context is one of the following:
...

• The initializer of
  • constants

A const fn is a function that one is permitted to call from a const context ... When called from a const context, the function is interpreted by the compiler at compile time

So my understanding is that:

• Defining a constant (ie pub const seven = 3 + 4) is a const context (constant initializer), and this is guaranteed to be evaluated at compile-time.
• A const fn can be used in a const context, in which case it would be evaluated at compile time.
• A const fn can also be used in a non-const context, in which case it may be evaluated at compile time.

Given the above, I don't think the const fn's would be guaranteed to be resolved at compile-time (although probably likely would) since they aren't all used in const contexts, so using constants gives us that guarantee too.

Interested to hear your thought, but regardless, change looks good to me!

[tao-stones]

For the sake of capturing our quick chat the other day (and partially for confirming my understanding) ...

A couple chunks from the Rust reference,

Certain forms of expressions, called constant expressions, can be evaluated at compile time. In const contexts, these are the only allowed expressions, and are always evaluated at compile time. In other places, such as let statements, constant expressions may be, but are not guaranteed to be, evaluated at compile time

The following expressions are constant expressions, so long as any operands are also constant expressions and do not cause any Drop::drop calls to be run.

• Literals.
• ...
• Built-in negation, arithmetic, logical, comparison or lazy boolean operators used on integer and floating point types, bool, and char.

A const context is one of the following:
...

• The initializer of

  • constants

A const fn is a function that one is permitted to call from a const context ... When called from a const context, the function is interpreted by the compiler at compile time

So my understanding is that:

• Defining a constant (ie pub const seven = 3 + 4) is a const context (constant initializer), and this is guaranteed to be evaluated at compile-time.
• A const fn can be used in a const context, in which case it would be evaluated at compile time.
• A const fn can also be used in a non-const context, in which case it may be evaluated at compile time.

Given the above, I don't think the const fn's would be guaranteed to be resolved at compile-time (although probably likely would) since they aren't all used in const contexts, so using constants gives us that guarantee too.

Interested to hear your thought, but regardless, change looks good to me!

Nice summary! I think it is within const context in my use of these const function. The performance tests I did before/after suggests this is the case. But honestly, I am not sure what does non-const context mean, as in const fn(variable: &mut u64) {}?

[steviez]

Nice summary! I think it is within const context in my use of these const function. The performance tests I did before/after suggests this is the case. But honestly, I am not sure what does non-const context mean, as in const fn(variable: &mut u64) {}?

Gotcha - I think I was mixed up on the which context is relevant here. Originally, I was thinking the caller of the constant/const function was the one that mattered. Such as:

self.transaction_cost.account_access_cost += ACCOUNT_READ_COST; // or account_read_cost()

But, as you pointed out to me in DM, I think the context of the const function itself is probably what is relevant.

pub const fn account_read_cost() -> u64 {
    // read account averages 5us
    compute_unit_to_us_ratio() * 5
}

This makes sense as the caller of a function shouldn't dictate how / when the compiler evaluates that function. Your quick test agrees with this so I'm all good / think I'm straightened out ... enough of this rabbit hole and back to real things ha