# Pre-RFC: Custom suffixes for integer and float literals

**URL:** <https://internals.rust-lang.org/t/pre-rfc-custom-suffixes-for-integer-and-float-literals/8029>\
**Category:** language design\
**Created:** [July 22, 2018, 3:34pm UTC](https://internals.rust-lang.org/t/pre-rfc-custom-suffixes-for-integer-and-float-literals/8029 "2018-07-22T15:34:58Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![mcy](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/mcy/32/6512_2.png) [@mcy](https://internals.rust-lang.org/u/mcy)\
**Post date:** [July 22, 2018, 5:44pm UTC](https://internals.rust-lang.org/t/pre-rfc-custom-suffixes-for-integer-and-float-literals/8029/9 "2018-07-22T17:44:18Z")

</div>

I have two problems with this design. The ad-hoc attribute should be replaced by a reasonable trait. The best we can get without a coherence disaster is

```rust
impl FloatLit for Meter {
    type SUFFIX = "m";
    const fn float_lit(lit: f?) -> Self { .. }
}

```

What `f?` is is my second problem. I detest the fact that C++ uses a builtin, fixed-width type, which is nonsense when you realize your literal constructor should be `const` anyways. I've actually already proposed the necessary types for this, [[Pre-RFC] Integer/Float literal types](https://internals.rust-lang.org/t/pre-rfc-integer-float-literal-types/7774), for this exact purpose.

The other problem is that that you'll get a coherence disaster _anyways_ if several such types make their way into scope. An alternative definition which sidesteps this is

```rust
enum m {}
impl FloatLit for m {
    type Output = Meter;
    // ..
}

```

This ensures that literals have an identifier name _and_ have a path; their path is that of the type that provides the name. Plus, you get to do silly things like

```rust
impl FloatInt for Meter {
    type Output = Self;
    // ..
}

```

Now, to import the literal you simply import `my_units::meter::m`, and name collision will take care of the rest. This even interacts nicely with the vanilla literals! Though this seems like a bit of a syntactical foot gun, since people will expect to implement `FloatInt` on the output type rather than the symbol type.

Finally, I think we should avoid table the brackets syntax for now, since it goes _quite_ afield; far more than the proposal should be allowing at this point in time.

> [@kennytm](#):
>
> IMO a literal suffix should be a **procedural macro** instead of a `const fn` , so interpolated strings ( `"log {date:?}: {msg}"_fmt` ) can be supported.

Can both features just exist alongside each other? I think most uses of a custom literal are better suited as `const fn`s, and I'd like to have to call the format prefix as `"..."!fmt` or something.

---

_[View the full topic](https://internals.rust-lang.org/t/pre-rfc-custom-suffixes-for-integer-and-float-literals/8029)._