Pre-RFC: Custom suffixes for integer and float literals

[DanielKeep]

Bikeshedding: I don’t think ^ should be used for “exponent”, since it already means “XOR”. If you’re going to introduce an exponentiation operator, that should probably be conditional on at least reserving the same symbol in the language proper.

[H2CO3]

Exactly – we already have operator overloading, and multiplication is perfectly fine to express the notion of… multiplication, which units of measure are. So indeed, if terseness is regarded as a value, then using a well-fitting, existing language feature (which is unambiguous for humans and doesn’t conflict with anything else in the language) is a far superior solution than cramming in a new, potentially very confusing and ambiguous one.

[newpavlov]

See https://github.com/rust-lang/rust/pull/52556 for a much more lightweight proposal

You can note that this PR was written by me. And it’s listed in the alternatives. You can see origins of this proposal in the PR thread. Though note that scope of this proposal is a bit larger than can be covered by constants.

Bikeshedding: I don’t think ^ should be used for “exponent”, since it already means “XOR”.

It’s just an example, ^ is not used as an operator there, but as part of the string “m/s^2”. We probably could use 1_si["m/s^2"] to make it more explicit.

[leonardo]

the more you have to do it, the more tempted you are to just start taking shortcuts.

Likewise mathematics notations meant for humans are short, somewhat ambiguous, quick to write, and use visual metaphors.

[RalfJung]

You can note that this PR was written by me.

oops okay

Though note that scope of this proposal is a bit larger than can be covered by constants.

Absolutely. But I think the comparison should be made with the most ergonomic thing that’s possible without the proposal, not with whatever happens to be the status quo. That’s all

[Centril]

In my view, a macro based solution is not very optimal from the perspective of units (putting aside the complexity of other approaches). If you write say expr.si![unit] where expr is some expression and unit is some unit format the macro understands, then it is not particularly extensible to other forms of unit. This means that all units must be defined by the macro up front and thus you can’t compose units other than by using different macros.

At this stage, I think syntax is secondary. You first need to figure out the story around unification at the type level. As @varkor previously noted, this topic was further discussed over at Any RFC for Units of Measure?.

[drXor]

I certain that the most efficient and Rust-like way to side-step this issue is to

• Associate each suffix with a type (possibly an uninhabited like enum m {})
• Implement a trait on this “symbol type”.

This sidesteps all of the weird ad-hoc problems related to using attributes and introducing new entities and introducing substantial grammar changes to the language, and gives an object that (in a given scope) refers to a suffix uniquely.

I think at this point I’m going to just write up my own Pre-RFC with my counterproposal in its own thread, since my idea is too broken up across replies to be understandable.

[drXor]

I’ve collected my various replies about a trait-based counter proposal here. Let me know what y’all think.

[fintelia]

We need this feature, Duration::from_secs(2) + Duration::from_millis(200) is annoying both to write and read.

I feel like I’m missing something. What is your use case that you frequently need to build up a bunch of Durations with very specific lengths of time? Also, why couldn’t you just write Duration::from_millis(2200)?

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.