Pre-RFC: Custom Literals via Traits

[newpavlov]

I think this proposal has the following problems:

• Use of marker types feels quite ad-hoc to me, and no, byteorder and other crates which use marker types are not good examples, because m and s will not be used as type parameters anywhere.
• It breaks Rust naming convention, which inevitably will lead to a confusion. What i represents in use foo::bar::i;? My first thought will be a “value”, next “macro”, and type will be the very last.
• How const fns will work on traits? Will it be a const in trait definition? Or in implementation?
• You will not be able to return BigNum from const fn, same goes for regexp engines and other heap-backed structures. You may return &'static T, but will it result in an ergonomic code or will you have to clone?
• Compound units are not supported. I know we have a different opinion on this, but I personally think that 1.2m_per_s2 and other longer suffixes will not be a good thing for readability of Rust.
• String prefixes are not included (in many cases they will be a better choice that string suffixes), though they can be described with the proposed approach.

Regarding tying custom prefixes to the full-blown units system, I am not sure. Yes, ideally they should work together, but AFAIK we don’t even have a Pre-RFC for it, no?

[drXor]

Use of marker types feels quite ad-hoc to me, and no, byteorder and other crates which use marker types are not good examples, because m and s will not be used as type parameters anywhere.

The whole point is to allow for them to be used in type paramters. I think Rust should allow constraining by pretty much any behavior, including literal processing.

It breaks Rust naming convention, which inevitably will lead to a confusion. What i represents in use foo::bar::i; ? My first thought will be a “value”, next “macro”, and type will be the very last.

This is still an open problem.

How const fn s will work on traits? Will it be a const in trait definition? Or in implementation?

There’s been RFCs floating about that would give this meaning. The intention is to require all implementations of a custom literal to be const, so that they can be used in constant position like built-in literals.

You will not be able to return BigNum from const fn , same goes for regexp engines and other heap-backed structures. You may return &'static T , but will it result in an ergonomic code or will you have to clone ?

Actually, MIR evaluation will support heap allocations, but I don’t have details beyond that.

Compound units are not supported. I know we have a different opinion on this, but I personally think that 1.2m_per_s2 and other longer suffixes will not be a good thing for readability of Rust.

This explicitly not a question the RFC wants to consider at this point.

String prefixes are not included (in many cases they will be a better choice that string suffixes), though they can be described with the proposed approach.

I don’t want to mess with prefixes in an already large RFC.

Regarding tying custom prefixes to the full-blown units system, I am not sure. Yes, ideally they should work together, but AFAIK we don’t even have a Pre-RFC for it, no?

The unit system should not be part of std, so there’s no need to write an RFC for it.

[newpavlov]

The whole point is to allow for them to be used in type paramters.

Your proposal does not include any examples where unit marker types are used as type parameters outside of desugaring for literals. And, no, it does not count for a reason why marker type have to be used here.

Actually, MIR evaluation will support heap allocations, but I don’t have details beyond that.

AFAIK it will support heap allocations inside const fn, but will not allow return of an owned heap-backed value.

This explicitly not a question the RFC wants to consider at this point.

But IMO it should be included in drawbacks section (which I think is too slim right now) with other voiced issues.

The unit system should not be part of std , so there’s no need to write an RFC for it.

No, if we want unit system to handle unification (see @Centril posts) properly, e.g. teach type system that m/s*m is equivalent to m*m/s, and maybe ideally auto-derivation of unit types, so you will not have to define all possible combinations like KgMeter2PerSecond2 (otherwise known as Joule) of basic SI types. If we want such system, necessary tools will have to be part of the language. (but note, not necesserally SI units themselves)

[ExpHP]

I hate seeing these discussions about suffixes being turned into discussions about units of measurement. There are other use cases of suffixes. And as people on both sides of the argument apparently agree, suffixes don’t do crap to solve the problems of UoM.

[drXor]

And, no, it does not count for a reason why marker type have to be used here.

The marker type is convienient because it gives a unique point of reference to the trait system for the desugaring, and places the literal into the module system. I think not having a trivial desugaring, like with every other operator, is a bad idea.

AFAIK it will support heap allocations inside const fn , but will not allow return of an owned heap-backed value.

Huh. I do want some way of being able to make some implementations const though. @Centril, do you have anything useful to say on this? I know you wrote a const fns in the trait system RFC.

But IMO it should be included in drawbacks section (which I think is too slim right now) with other voiced issues.

The fact that the RFC limits its scope is not something that’s to be listed in the drawbacks of the proposed feature.

No, if we want unit system to handle unification (see @Centril posts) properly, e.g. teach type system that m/s*m is equivalent to m*m/s , and maybe ideally auto-derivation of unit types, so you will not have to define all possible combinations like KgMeter2PerSecond2 (otherwise known as Joule) of basic SI types. If we want such system, necessary tools will have to be part of the language.

This feature is orthogonal to the proposal.

[newpavlov]

The marker type is convienient because it gives a unique point of reference to the trait system for the desugaring, and places the literal into the module system. I think not having a trivial desugaring, like with every other operator, is a bad idea.

Same argument can be made for macro based system (which was roughly described here), which will have trivial desugaring as well.

[CAD97]

Actually, MIR evaluation will support heap allocations, but I don’t have details beyond that.

@Centril, do you have anything useful to say on this? I know you wrote a const fn s in the trait system RFC.

As I understand it, miri can use mutable allocation internally, and const can return statically borrowed heap memory, but not owned or mutable.

(as it has to be .rodata or similar, I don’t know those names)

[Centril]

AFAIK it will support heap allocations inside const fn , but will not allow return of an owned heap-backed value.

Huh. I do want some way of being able to make some implementations const though. @Centril, do you have anything useful to say on this? I know you wrote a const fn s in the trait system RFC.

As I understand it, miri can use mutable allocation internally, and const can return statically borrowed heap memory, but not owned or mutable.

cc @eddyb

This feature is orthogonal to the proposal.

It is; but there will still be interactions; and we should ensure that these work well. For example, say that we wanted to introduce the syntax 1 [m/s] at some later stage… how do we deal with this then and will we have two systems? We should always consider forward-compatibility in lang design.

[drXor]

It is; but there will still be interactions; and we should ensure that these work well. For example, say that we wanted to introduce the syntax 1 [m/s] at some later stage… how do we deal with this then and will we have two systems? We should always consider forward-compatibility in lang design.

For sure! @kennytm already pointed out that this syntax already has a meaning, though, so we’ll need to think of something else. I kind of like the angle brackets. Maybe 123some::path is sugar for 123::<some::path>. We can then make the syntax be $lit::<$some_limited_expr>. My proposal is intentionally light on the grammar, in view that most obvious things (like $lit$expr) can be forced to have meaning. Thus:

let _ = 80m;
let _ = 1.23::<m/s>;

[Riateche]

I propose the following solution to the i__ input type problem:

// marker
trait LiteralInput {}
impl LiteralInput for i32 {}
//impl LiteralInput for u32, i64, ..., f32, f64, &'static str, ...
// possibly add big integer literals in some form in the future

trait Literal<T: LiteralInput> {
    type Output;
    /*const*/ fn apply_literal(input: T) -> Self::Output;
}

struct Meter(i32);
enum m {}
impl Literal<i32> for m {
    type Output = Meter;
    /*const*/ fn apply_literal(input: i32) -> Meter {
        Meter(input)
    }
}

With this, a custom literal can use any of the available input types, and it’s possible to support more input types (e.g. i256 or [u8; N]) in the future if needed. If the custom literal requires i32, the compiler will try to interpret the preceeding integer literal as i32 (and fail if it’s not a valid i32 literal).

It also will be possible to implement the trait for multiple input types, e.g. impl Literal<i32> for m and impl Literal<i64> for m. This is useful if multiple input types makes sense for this literal (for example, it may even produce a generic Meter<T: Num>). The compiler will pick a suitable implementation for invokation. This can work in a very similar way to how operator traits like Add<Rhs> or Index<Idx> work now.

If there are multiple implementations and the supplied literal can be interpreted as any of them, it’s not clear what the compiler chooses. It’s not very good but it’s the same situation we already have with normal integer literals. You may not know what type is selected for vec![1] if the context doesn’t place additional limitations. The type inference should do its magic. If the context requires a Meter<i64>, the impl Literal<i64> for m will be chosen over impl Literal<i32> for m.

[kennytm]

The following impl s generate a lint (yet unnamed, please bikeshed):

impl IntLit for e<numbers> { .. }
impl IntLit for E<numbers> { .. }

impl FloatLit for e<numbers> { .. }
impl FloatLit for E<numbers> { .. }

This is to point out a parse ambiguity. Float literals in scientific notation are always lexed as literals, since having 10e100 possibly parse as a custom literal is extremely confusing.

If this one is linted, there should also be lints for:

1. impl IntLit for ** where the name ** starts with any of [a-fA-F], since 0x7fff_EiB (intended for exbibyte) will be interpreted as 0x7fffE with suffix iB.

   • This could be problematic as it covers a lot of units of measures (A, cd, Bq, C, F, au, day, dB, eV, ft, fl_oz, prefixes exa-/deca-/deci-/centi-/femto-/atto-)
   • We could avoid this if there would be separate HexIntLit/OctIntLit/BinIntLit traits, thought that means u256 will need to implement 4 traits (should be fine?).
   • Speaking of which, should we also lint prefix x and o because of 0x6? I suggest no since 0_x6 is unambiguously parsed as 0 with suffix x6.

2. impl *Lit for ** where the name ** starts with _. 1234____s is equivalent to 1234s so there shouldn’t be any leading underscores.

Or maybe these don’t need to be linted at declaration site since you could unambiguously call it like 10::<e100> or 0x7fff::<EiB> (I’m not sure if using turbofish for this syntax is a good idea though).

[scottmcm]

Using uninhabited types as units is very confusing — you’re effectively overloading what types mean just because they coincidentally fit into the rest of your framework. The type itself is useless apart from for providing the impl .

In C++, milliseconds is a type: https://en.cppreference.com/w/cpp/chrono/duration#Helper_types (As is milli, but that’s a different discussion.)

That solves all these problems, and as a bonus allows more efficient uses in places that don’t want or need 1ns resolution (like sleeping a thread, which can sleep neither for 1ns nor for 136 years).

(Of course, it needs a bunch of stuff that rust doesn’t have yet to have it not also cause a ton of manual grunt work creating all these types and to avoid the need for .into() all over the place to actually use them.)

[drXor]

Yeah… this is something of a mess. I’m actually in favor of HexIntLit/OctIntLit/BinIntLit, all of which have IntLit as a supertrait. This lets us lint a little bit less aggressively. core certainly won’t have to put up with it, since the implementations for the primitive literals will get macro-generated anyways. Unit literals really shouldn’t be given by hex, or octal.

(I’m not sure if using turbofish for this syntax is a good idea though).

10::[e100]? I think further abusing :: for parsing disambiguation is fine. Even in the presence of a disambiguation syntax, we should still lint, because people will be really confused when 10e100 doesn’t do what they want and it takes them a second to remember about scientific notation literals.

[fintelia]

Other than the type checked SI units proposal which currently seems to have a bunch of other open questions, couldn’t these use cases be supported by either:

A (proc?) macro:

• time!(2s + 3m)
• complex!(3 + 4i)
• quaternion!(2i + 3j + 4k)

A normal const fn:

• Regex::from_static_str("foo(.+)")
• Utf16String::from_static_str("Hello, World!")

Or, a const fn + literal types:

• BigInt::from_literal(192346712347913279231461927356)
• HalfFloat::from_literal(1.23)

[drXor]

Sure, this is the implicit “or we could just, not do this” in any RFC. Also, things like time!(2s + 3m) are hilariously hard to implement, because + can’t be used as a separator currently.

[Soni]

I have to ask, what about 1e10e10?

[drXor]

Parses as 1e10::[e10] and desugars to <e10 as FloatLit>::float_lit(1e10);. I think I pointed this out elsewhere.

[Soni]

or should it be e10e10::int_lit(1)?

[drXor]

The RFC is very clear on this. We always parse a literal as far as it will go before parsing the suffix, because doing otherwise will confuse users. See @kennytm’s replies.

[Centril]

So we have…

let _ = 1.0m/s^2;
// desugars to
let _ = <m as IntLit>::int_lit(1.0).div(s.bit_xor(2));

and if we have:

1.23 < m / s >

(or some other two set of tokens for disambiguation) we desugar to:

<<m as Div<s>>::Output as IntLit>::int_lit(1.23)

I guess that makes sense… Basically, we interpret < m / s > as a type. However, translating / to Div this way is a bit weird.

Wild speculation: Another mechanism could be to interpret m / s as a const expression and so you get something like Unit<{ m / s }>. However, then you may get into coherence problems wrt. the type constructor Unit and so it might need to be #[fundamental] so that you can write something like:

impl IntLit for Unit<{m / s}> {
    type Output = Qty<Quot<Meter, Second>>;
    const fn int_lit(lit: i__) -> Self::Output {
        ...
    }
}