Ashley Mannix

@slightlycode @lukeed05 Oh I’m no expert, but it’s weird isn’t it. Decimal formats pick a value for the binary64 that roundtrips. Many of our favourite base10 numbers aren’t exactly representable in a binary64 so they’re encoded as something very close. As you do math on them, they become less close

@lukeed05 @KodrAus you'd know all about this. You did some work on floating point to info recently for Rust?

sigh 😔

@ArmyOfBruce For sure 👍 I think I should maybe also try back up my claims that upgrading is easy by going through and submitting PRs to libraries still on 1.x

@KodrAus I think we talked some years ago about the usefulness of a janitorial team that would help do ecosystem-wide updates … might be useful to think about again.

Looking for input from any #rustlang bitflags users out there on a draft spec for its behaviour: github.com/bitflags/bitfl…

@ArmyOfBruce It’s a totally valid concern though. I don’t want to make breaking bumps frequently, even when they don’t actually break things

@ArmyOfBruce Yeh, as a consumer you should be able to go from 1.x to 2.x or 3.x (or 4.x or further) without needing to issue any major bump of your own. The differences between 2.x and 3.x only affect the behavior of edge cases

@firstdrafthell @khellang @getseq_net Someday 😄

@khellang @getseq_net Yeah, me too. I would have thrown money on them.

Does anyone know of a good cloud logging provider that supports structured logging? I really like Seq and have been using it a lot in the past, but for this thing, I would prefer to not host and maintain things myself. I'm looking for a dedicated SaaS solution for this.

@steveklabnik @fasterthanlime For this case specifically I still believe we should deprecate std::sync::Once in favor of std::sync::OnceLock<()>, but not as firmly as I once did

@DrawsMiguel @__phantomderp I’ve got some weird stuff I’d love to see made obsolete

@burntsushi5 Having to answer the question “would someone have a bad time implementing this” is a nice grounding principle for taming complexity in trait systems I think

@burntsushi5 I’ll out myself with bitflags. It’s got a BitFlags trait that was written just to be implemented by the macro so I sealed it. That decision made it into a dumping ground

I think we all need to stop using sealed traits and custom derives to paper over design incoherence in Rust libraries

@burntsushi5 I’m specifically talking about using these techniques to try hide poorly designed abstractions. Reaching for sealed or custom derive to hide a trait just because it’s been made difficult to implement

@KodrAus What's the alternative in today's Rust? I use them in byteorder, bstr and aho-corasick. Makes it nice and easy to add new required methods without worrying about backcompat.

@josh_triplett I shamed myself into rethinking the sealed bound on bitflags::Bitflags and immediately the potential utility has expanded now that I’m considering it independently of the macro: github.com/bitflags/bitfl…

@KodrAus Can you give some examples of the design incoherence you mean? I'd love to figure out whether there's something we could improve to systematically help libraries do better designs than they currently can with today's Rust.

@josh_triplett To be fair, I’m certainly not innocent here. Both of these traits in bitflags should be publicly implementable: github.com/bitflags/bitfl… Designing BitFlags specifically as if it’s just a target for the macro has made it a weird blend of operators and iterators

@josh_triplett Actually, one other case I can think of for sealed traits is for object-safe versions of generic traits, where there’s no “valid” impl of the object-safe version that isn’t from the generic one. That’s pretty niche though

@sadisticsystems I find sealed traits can be markers of incomplete or false abstractions where properties of the blessed impls leak back into the trait, and forced custom derives can hide spaghetti