Hacker News Reader

Comment by est31 | Hacker News Reader

A smaller release. The most notable thing is probably the update to LLVM 12.

One things I wonder about is why newly stabilized functions like char::from_u32 aren't const fn from the start. I get when existing functions have to be made const after the fact, but to me it feels that new functions should be stabilized already as const unless there is a good reason they can't be (e.g. they allocate).

View on HN

I don’t know the specifics of this function yet but don’t forget there are lots of things that could be done in const fn that aren’t accepted yet; it’s often the reason things work out like this for these functions.

EDIT: okay, I looked into it! (rust-analyzer is really useful for this...)

this function calls TryFrom::try_from. which runs afoul of https://github.com/rust-lang/rfcs/blob/master/text/0911-cons...

> Traits, trait implementations and their methods cannot be const - this allows us to properly design a constness/CTFE system that interacts well with traits - for more details, see Alternatives.

So, there you go.

Often, functions call trait methods internally and const traits aren't ready for prime time yet iirc.

Mhh you are right. Apparently it calls try_from internally. It throws away the error but often creating errors also allocates.

I wonder if the validation of the char is non-trivial and unwanted at compile time?

Validating should be pretty trivial. Explicitly handling all cases would look something like this:

    #[inline]
    const fn is_valid_scalar(c: u32) -> bool {
        match c {
            0..=0xD7FF => true,
            0xD800..=0xDFFF => false, // surrogate pairs
            0xE000..=0x10FFFF => true,
            0x110000..=u32::MAX => false, // outside of Unicode range
        }
    }

But this could be reduced down to a simple if statement that tests for the invalid ranges.

If you absolutely want to golf it into one line:

  #[inline]
  const fn is_valid_scalar(c: u32) -> bool {
    matches!(c, 0..=0xD7FF) || matches!(c, 0xDE00..=0x10FFFF)
  }

But I prefer your version for its clarity. It should compile into the same thing regardless.

Reply on news.ycombinator.com