You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It has finally happened! As per rust-lang/rust#72437 the following things are now allowed in const functions:
if, if let, and match
while, while let, and loop
the && and || operators
This should allows us to basically move all of our clock calculation optionally to compile time since for most of the peripherals we provide it's very unlikely someone will want to dynamically change the clock speed at runtime, if they instead opt in to const-fn calculation of their clock speeds we can:
reduce initialization time since we don't have to calculate the config while starting up anymore
reduce binary size since the code wanders from runtime to compile time
I'm not quite sure whether this is doable as a const fn without breaking the current API though? I'd imagine we would need to add an additional parameter clock_configuration that gets passed the result of such a config calculator function? For example an I2C init might end up looking like:
Because otherwise the constant functions aren't called in a constant context so the rust compiler would treat them just like normal functions, or am I mistaken about that? If the compiler was feeling really clever it could of course allow us to call the const fn inside the i2c function, see that the parameter is a constant and evaluate the const fn at compile time, but I dont think it can perform such magic? Again not quite sure, this definitely requires some further investigation but definitely provides some big benefits for the HAL once adopted.
The text was updated successfully, but these errors were encountered:
It has finally happened! As per rust-lang/rust#72437 the following things are now allowed in const functions:
This should allows us to basically move all of our clock calculation optionally to compile time since for most of the peripherals we provide it's very unlikely someone will want to dynamically change the clock speed at runtime, if they instead opt in to const-fn calculation of their clock speeds we can:
I'm not quite sure whether this is doable as a const fn without breaking the current API though? I'd imagine we would need to add an additional parameter clock_configuration that gets passed the result of such a config calculator function? For example an I2C init might end up looking like:
Because otherwise the constant functions aren't called in a constant context so the rust compiler would treat them just like normal functions, or am I mistaken about that? If the compiler was feeling really clever it could of course allow us to call the const fn inside the i2c function, see that the parameter is a constant and evaluate the const fn at compile time, but I dont think it can perform such magic? Again not quite sure, this definitely requires some further investigation but definitely provides some big benefits for the HAL once adopted.
The text was updated successfully, but these errors were encountered: