Key word for dimensionally unsafe actions

[paholg]

I would like to ensure that any interface that lets you take actions where units are not checked is clearly labeled.

For example, in v0.5 of dimensioned, there is a map function that lets you apply a function to the underlying value. In the rewrite, I am looking at having two functions, map and map_unsafe. Both do the same thing, but the new map is only defined when dealing with dimensionless quantities so you have no units to mess up.

I would like direct exposure to the underlying value to follow a similar naming convention, but the word "unsafe" has pretty clear memory-safety connotations in the Rust ecosystem and I would like to avoid it.

Thoughts?

[droundy]

I can't think of something better than unsafe. I think unsafe is sometimes used in rust even when memory safety is not at issue (but only correctness). I think that bypassing compile-time guarantees could qualify as unsafe. e.g. interpreting a 32-bit integer as a f32 is unsafe, even though it cannot lead to any memory corruption issues. It's only unsafe because it might give different answers on different architectures. But broadly speaking, dimensioned is preventing precisely the same kind of thing: accidentally treating a value as a different type of value.

[paholg]

Unsafe it is!

[ExpHP]

Rust's unsafe keyword is not so much about memory safety as it is about Undefined Behavior, and I feel that this usage of the term cheapens its meaning. I hope you may still consider changing this before an eventual 1.0.

I do not feel there needs to be a single term for this applicable in all contexts; one could call the member value_raw (or to really discourage its use, something unwieldy like internal_value). The phrase "dimensionally unsafe" can be replaced with phrases like "dimensionality is (un-)checked".

Re: integers to floats, f64::to_bits and from_bits (stabilized in 1.20) are unapologetically marked safe. There's a note on the latter that it may or may not mask signalling NaNs... but to my understanding, the question isn't whether or not Rust wants to provide "no signalling NaNs" as a guarantee, but rather, it's because nobody in the community really knows whether LLVM (or other platforms) considers them to invoke UB.

[paholg]

Reopening this issue to be considered for the next batch of breaking changes (which will likely be when const generics are a thing).