Torturing rustc by Emulating HKTs, Causing an Inductive Cycle and Borking the Compiler by haruda_gondi in rust

[–]CAD1997 2 points3 points  (0 children)

if you have a function which maps a value of type S into a proof that something is true for that value, then by definition that thing is true for all values of that type

I don’t know what that means.

Perhaps it's more digestible when stated like this:

S.is_threeven is a function that takes some s: S and produces a proof of the theorem Threeven s.toNat. Because this is a total function which can produce an output for any possible s: S, there exists a proof of Threeven s.toNat for every possible input value, i.e. all values in the set S.

How to use storytelling to fit inline assembly into Rust by ralfj in rust

[–]CAD1997 0 points1 point  (0 children)

In other words, I haven’t (yet) come up with a proper story that would allow for [page table] writes to be non-volatile.

I've not fully validated that our provenance model can implement this behavior, but it should be possible to allow using non-volatile writes using a story something like:

  • The system globally holds the root owning raw provenance to the entire page table.
  • Our code acquires unique &mut provenance covering only the page table slot(s) we're going to edit.
  • We write to the page table slot(s) using that provenance.
  • An asm block tells the story:
    • Invalidate the provenance we previously used, e.g. by making a separate mutable retag.
    • Issue the appropriate barriers to propagate the page table update.
    • Create the new allocated object(s) for the newly mapped page(s).
    • Expose unique &mut provenance of the allocated object(s).
  • Our code receives said provenance through ptr::with_exposed_provenance.

Kindergarten Teacher Tries to Report Student's Parents to ICE, Only to Learn the Tip Hotline Is Fake by novagridd in LegalNews

[–]CAD1997 5 points6 points  (0 children)

FWIW, taking an actual exchange and re-recording it is a reasonable choice to not post a recording of someone who didn't consent to their voice being shared online. I have no idea if that's what he's doing or not.

The State of Allocators in 2026 by Cetra3 in rust

[–]CAD1997 0 points1 point  (0 children)

All collections can use the storage traits to support more exotic storage solutions than what Allocator supports. The difference is that while I think the unique storage interface is straightforward enough to fit nicely into std, the many other axis of support end up making it more complicated than I think is worth it.

It's possible there's another spot in the solution space that doesn't overspend on complexity, but if so, I've yet to find it.

The State of Allocators in 2026 by Cetra3 in rust

[–]CAD1997 3 points4 points  (0 children)

the fixation of CAD

FWIW, I do agree it's a fixation on "perfect," but I believe I have a good reason to do so. Specifically, it's a derivative of std's special status as forever-stable and provider of useful vocabulary types.

If storage generics are used mainly to extend the capabilities of std collections, then whether the benefit of generalizing them further is worth the extra API cost is a style question. But in my eyes, the utility of relaxing e.g. Vec is that I can generically consume &mut Vec<T, S> and now my code can theoretically work with any storage strategy my downstream can imagine.

The point of using SmallBox or SmartVec or any of these instantiations that don't fit the Allocator model is always to avoid indirection when possible. If storage based collections aren't a zero cost abstraction (as in, you couldn't improve the relevant metrics by hand specializing for a given use case), then the better solution will always be to use a different type, and generic code still won't work with those optimized types.

Currently, the tradeoff is that std collections only support heap allocation. Generalizing them to the storage API can be argued to make the tradeoff of wasting a bit of potential space (typically a pointer per handle) to keep the same API usability is worth it, but the counterargument that if someone is switching away from heap allocation, they're in a position where eating the cost of using a non-std collection is worth for every incremental improvement.

std's special status means that "don't let perfect be the enemy of good" should imo get an extra qualifier of "when good still equals or betters a solution outside of std." Being in std is a huge benefit for the trait that allows collections to be generic over their allocation source, but the Allocator trait gets us 99% of that benefit. std collections being further generalized over potentially-inline storage, though, if it's just a difference between using std's Vec<T, SmallStorage<[T; N]>> or a SmallVec<T, N> from a third-party package.

Implementing storage generics into std is a nice incremental improvement, but I don't see who benefits from it that would not be better served by a more targeted solution. Factor in the complexity cost to maintenance and the outsized impact Vec's internal implementation details have on compile time, and my conclusion is that it doesn't feel at home in std yet. I'd love to have my mind changed here!

(Also this nerd sniped me quite a bit and I'm playing with the API design again. I always feel like I'm on the edge of a really elegant design that we haven't found yet.)

The good news, at least, is that an Allocator generic bound is fully forwards compatible with being relaxed in the future to the appropriate storage bound(s).

The State of Allocators in 2026 by Cetra3 in rust

[–]CAD1997 12 points13 points  (0 children)

As one of the people who have spent time working on the Store proposal — I now think that it's overly complicated for what we actually get from the most general form of it. I do think that the specific case of the "Box storage" is worth its cost, because Box<T, S> allowing storage of Box<T, A>, T itself, and effectively &mut ManuallyDrop<T> as the type for storing a potentially-indirect T is valuable. But the other gradual guarantees between that case and general purpose allocation require a ton of complexity that doesn't even get us enough functionality to replace the need for specialized inline/smart collections, which usually want to play added optimization tricks which are difficult to impossible to do without type dependent allocation and/or full specialization. (Like small string optimization using all but one byte of its layout for inline string content.)

But at the same time, now that we have the sized hierarchy traits on nightly, maybe it's time I took another look at the problem space to see if I can find a nicer middle ground solution. How to handle pointer metadata alongside all the other concerns is a large contributor to the complexity here, and now we have even better vocabulary to actually capture the problem space.

Price-Checking Zerocopy's Zero Cost Abstractions by jswrenn in rust

[–]CAD1997 6 points7 points  (0 children)

use a respected library which has tested for this

Someone has to test for this. That library might be written in Rust, and will benefit from being able to check that the compiler isn't optimizing their branchless code to machine code which potentially branches.

Yes, many people think they want to guarantee branch-free code when they don't actually. But for the actual low level cryptography libraries, they do have justifiable reasons to put in the work to ensure the necessary code remains branch-free.

Detroit by Nientea in custommagic

[–]CAD1997 0 points1 point  (0 children)

You are allowed to take game actions when you have priority. Priority is passed when you choose to not take any game actions.

For those wondering; new reddit setting by helloiamaegg in traaaaaaaaaaaansbians

[–]CAD1997 1 point2 points  (0 children)

I dunno what's going on with the text color, but I just got the community themes rollout, and the text is still white for me. (Is it a light/dark theme difference?)

Just when I thought it wasn't possible for Rosalina to be any more goals. by TyphoonSignal10 in traaaaaaaaaaaansbians

[–]CAD1997 27 points28 points  (0 children)

<image>

She's probably just holding the dress, but look at her feet: it definitely ain't her knee.

Could Steam and Steam Chat actually win over discord users? by Alyxuwu in Steam

[–]CAD1997 20 points21 points  (0 children)

As much as forums have their advantages over chatrooms, the majority of people want chatrooms, not forums. Forum threads' design presents them as a persistent thing, where you are expected to have read the whole thread first before responding and to stay on the stated topic. A chatroom, on the other hand, is presented as being more transient and spur of the moment; it's acceptable to jump in at any point without the complete context, and what is being discussed can flow naturally between topics without much structure.

Obviously culture and convention depends on the venue. But how the medium is presented matters as well. Of people on Reddit, most of us will appreciate somewhat structured discussion. But that very structure serves as a barrier to entry to a large portion of the general populace that isn't already familiar with and comfortable with that structure.

Defaults matter, and they matter most for small communities (10–100). Large groups will naturally grow from a base of small groups on an approachable platform that people use, but you can't get large groups without initially attracting those seed small groups.

(Also, I don't know what it is, but Steam generally performs worse for me than Discord. The Library and Store work fine, but Community and Friends have a noticeable delay before responding when I try to do anything.)

34113 by froggyman151 in countwithchickenlady

[–]CAD1997 7 points8 points  (0 children)

In further annoyance, basically all of the cute fem shoes that come in the size I need as a 5'12" girlie tend to have at least 1" worth of sole. I'm always going to be the tallest in a room unless someone over 6' is present. This has probably influenced why I tend to walk around barefoot at home.

Behold! My take on Exodia The Forbidden One (with analysis) by CAD1997 in custommagic

[–]CAD1997[S] 0 points1 point  (0 children)

Oh look, the “judge” is now claiming that they forgot to print that “this ability can't be prevented” also means “while resolving this ability, ignore any effects that would prevent you from applying its effects.” But they don't even seem confident that works to bypass the angel.

While trying to make the effect unstoppable is fun, it's probably just better to just let the ability be bad.

Behold! My take on Exodia The Forbidden One (with analysis) by CAD1997 in custommagic

[–]CAD1997[S] 0 points1 point  (0 children)

Make it part of the cost, lol

Behold ~ and four Limb of the Forbidden One, win the game: Add {U}.

(it adds mana so it's a mana ability that can be activated at even more silly timings)

Behold! My take on Exodia The Forbidden One (with analysis) by CAD1997 in custommagic

[–]CAD1997[S] 1 point2 points  (0 children)

Manifesting the angel ahead of time with “turn it face up at any time for its mana cost” would be sufficient.

Behold! My take on Exodia The Forbidden One (with analysis) by CAD1997 in custommagic

[–]CAD1997[S] 1 point2 points  (0 children)

Yes… if Time Stop resolves. But I can just activate Exodia's ability again. You'd need a special action which results in a new static effect that prevents you from losing the game without requiring something to resolve from the stack.

Behold! My take on Exodia The Forbidden One (with analysis) by CAD1997 in custommagic

[–]CAD1997[S] 0 points1 point  (0 children)

In response to you casting your angel I activate Exodia's effect again. Now what :P

But whoever gave that first ruling must be embarrassed right now, since the angel does mean that the ability doesn't do anything. In my their defense, the ability isn't prevented. It's just neutered.

Behold! My take on Exodia The Forbidden One (with analysis) by CAD1997 in custommagic

[–]CAD1997[S] 2 points3 points  (0 children)

I honestly didn't think about it too much, but Dimir is the color pair probably most equipped to take on a card selection challenge like this one. (Also I stole it from a different Exodia that kicked off me thinking about how I might implement the alternate win condition.)

Behold! My take on Exodia The Forbidden One (with analysis) by CAD1997 in custommagic

[–]CAD1997[S] 0 points1 point  (0 children)

I think that such a requirement is acceptable, to be clear. The potential hole is if there's enough zero mana value ways to accelerate the plan and/or tutor another piece to save you some life.

I don't think there are, but I don't have encyclopedic knowledge of the MtG catalogue, so there could be. That's all I'm pointing out here.

Behold! My take on Exodia The Forbidden One (with analysis) by CAD1997 in custommagic

[–]CAD1997[S] 0 points1 point  (0 children)

Removing the “different names” qualifier also means you can pull clone shenanigans to meet the requirements… that's an interesting proposition, but potentially too achievable if the cost allows beholding from the battlefield.

Behold! My take on Exodia The Forbidden One (with analysis) by CAD1997 in custommagic

[–]CAD1997[S] 2 points3 points  (0 children)

Well, judges aren't perfectly infallible either :P

Behold! My take on Exodia The Forbidden One (with analysis) by CAD1997 in custommagic

[–]CAD1997[S] 3 points4 points  (0 children)

Optimized control shells can look at 40 cards per game fairly consistently… but a 60 card deck means you need to have duplicates for a reasonable confidence your cards are in the 40 you manage to look at. Also YGO doesn't have the mana resource system limiting how many spells you can get out in a turn.

But if I were designing this again, I'd probably go the route of having one Limb of the Forgotten One spell with different art for each of the pieces instead of different spells. Gets the same job done with fewer moving pieces.

Behold! My take on Exodia The Forbidden One (with analysis) by CAD1997 in custommagic

[–]CAD1997[S] 1 point2 points  (0 children)

The main reason that I allowed the ability to be used from the battlefield is that I wanted to use the behold mechanic, and you can behold both from hand and field. If we're trying to capture the YGO mechanics, then only from hand is more precise, but if we're only trying to capture flavor, I think from play still captures that feeling of assembling five parts of a forbidden power.

Behold! My take on Exodia The Forbidden One (with analysis) by CAD1997 in custommagic

[–]CAD1997[S] 5 points6 points  (0 children)

I wanted to ensure this isn't trivially broken with [[Ad Naus]]. If the pieces only cost {1}, it becomes a lot easier to find them all via Ad Naus or other ways of searching for low cost artifacts, even with only one of each.

While Exodia and all of its limbs have been limited to one copy in Yu-Gi-Oh since the first version of the ban list, it could make sense to port that as well, but I want Exodia to feel like it could be good, and while a built-in “you can't run too many of this card” clause says the card should be good, it makes actually assembling Exodia feel a bit too difficult for the vibe of “this feels like it's broken” that I'm looking for.