scottmcm

@rfcbot concern reference-text I'd like to see something like https://github.com/rust-lang/rfcs/pull/3678/files#r1768869462 to nail down a couple of the details as part of the text here

That said, the current plan as described in the current version sounds great to me! I look forward to having it. @rfcbot reviewed

Reading *only* a `char` makes this feel much too restricted to be worth it, to me. For example, the "guessing game" example in the book couldn't use this. I think...

Hmm, curious. By the name `cons` I'd have expected it to *only* support `(a, (b, (c, d)))` order, since that want `cons`ing creates in lisp.

(@jhpratt I'd love for you to steal something like the text in this post for the RFC) > I assume it's library authors a making unsafe fields a "reminder to...

EDIT: see below; it looks like the thing I was worried about here is probably impossible for other reasons. I do thing that "safe to read; unsafe to modify" is...

> accessing the field can't lead to UB on its own Ah, I guess an access can't actually read an `UnsafeCell` (without ownership) because it's never `Copy`. So I think...

When do people really want `forbid`? The only thing that comes to mind for me is `forbid(unsafe_code)`, where I could consider it a plus that a macro can't `allow(unsafe_code)` to...

Alternatively, change some of the existing InOuts to be these Hermite functions For example, this piecewise definition of easeInOutQuint is IMHO poor https://github.com/ai/easings.net/blob/720053828214f0886763c0d90e6980498295a91b/src/easings/easingsFunctions.ts#L68-L70 because that definition is really jerky: it...

> if we can do this for every branch of the match 👍 This is my core complaint with rustfmt, I think. It seems to regularly lose consistency between items...