Ashley Mannix

Engineer @datalust_seq
he/him

[Ashley Mannix @KodrAus]

@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

[Ashley Mannix @KodrAus]

@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

[Ashley Mannix @KodrAus]

Looking for input from any #rustlang bitflags users out there on a draft spec for its behaviour: https://t.co/qTU8epI1n2

[Ashley Mannix @KodrAus]

@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

[Ashley Mannix @KodrAus]

@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

[Ashley Mannix @KodrAus]

@firstdrafthell @khellang @getseq_net Someday 😄

[Ashley Mannix @KodrAus]

@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

[Ashley Mannix @KodrAus]

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

[Ashley Mannix @KodrAus]

@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

[Ashley Mannix @KodrAus]

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

[Ashley Mannix @KodrAus]

@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

[Ashley Mannix @KodrAus]

@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

[Ashley Mannix @KodrAus]

@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: https://t.co/PKlpn1iGt6

[Ashley Mannix @KodrAus]

@josh_triplett To be fair, I’m certainly not innocent here. Both of these traits in bitflags should be publicly implementable: https://t.co/fK2h0QQ5j2

Designing BitFlags specifically as if it’s just a target for the macro has made it a weird blend of operators and iterators

[Ashley Mannix @KodrAus]

@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

[Ashley Mannix @KodrAus]

@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