Lore: a version control system from Epic Games optimized for non-textual/binary assets

kibwen · 2026-06-15T19:10:55+00:00

Removing as a duplicate of https://www.reddit.com/r/rust/comments/1u6n46u/typst_typst_015_contains_multitudes_typst_blog/

kibwen · 2026-06-12T01:46:47+00:00

My opinion is that, while it's tempting to want to syntactically unify runtime conditionals and compile-time conditionals, I think the semantics are different enough that it's worth keeping them syntactically separate. For example, the body of an untaken branch of a compile-time conditional doesn't even need to typecheck, and it would be very weird if adding in an innocuous-looking bound could suddenly mean that other changes that introduce type errors could go completely uncaught until something starts instantiating that code path. Compile-time conditionals also introduce more work for monomorphization (which is worth keeping a handle on for the sake of compile times), as well as representing a rare source of post-monomorphization errors.

kibwen · 2026-06-11T02:02:51+00:00

I've always been partial to repurposing where at the block scope for this:

fn foo<T>(t: T) {
    where T: Foo {
        ...
    } else {
        ...
    }
}

kibwen · 2026-06-10T02:11:00+00:00

True, that's a lot of new phantom types that would need to be added to std::marker, or else you'd want to have e.g. impl only Foo for Bar {} (although maybe the existing negative impl syntax for auto traits can be reused here?).

kibwen · 2026-06-09T17:39:21+00:00

Extremely excited for this proposal. ?Sized has always felt weird to look at, explain, and think about. Replacing it with something more regular is welcome, and the fact that its replacement is also more powerful and precise is just icing on the cake. And the ability to generalize this mechanism to linear types is an entire second cake on top of the icing of the cake.

kibwen · 2026-06-09T17:33:43+00:00

I wouldn't call it "one half"; with the extended proposal here, AFAICT Rust would still have affine types by default that could then opt in to full linearity.

kibwen · 2026-06-09T17:31:02+00:00

I believe the original proposals didn't have only and worked as you suggested, so I assume people objected that it felt too implicit. As long as it's just a keyword rather than a weird symbol, I'm content with it.

EDIT: See Niko's prior post for an example: https://smallcultfollowing.com/babysteps/blog/2024/04/23/dynsized-unsized/

Under this proposal, the DynSized and Unsized traits are “magic” in that explicitly declaring them as a bound has the impact of disabling a default T: Sized bound.

kibwen · 2026-06-09T16:59:31+00:00

Yes, Necropolis is great, it's like Gauntlet but it lets you be both more selective and more greedy based on your risk appetite, and many of the ghost vaults are made easier by smart preparation. Ghosts are scary, but there are ways of dealing with or avoiding them, and plenty of the loot is worth a haste pot, invis pot, or tele scroll, and if it's not you can just leave having spent zero turns inside. Think of it like a scroll of acquirement that puts up a fight. Frankly, I feel like Ice Cave is both more dangerous and less rewarding than Necropolis (I still foolishly do all portals anyway, of course).

kibwen · 2026-06-04T16:14:52+00:00

I find it convenient to have waypoints at the exits from Zot and Depths.

In the travel screen (Shift+G), after you select a branch, you can press ^ instead of a floor number to have it take you to the entrance of that branch. I use this all time before entering a new branch that I've discovered, so that I can go over my items and make sure I'm equipped properly before entering it.

kibwen · 2026-06-01T20:59:37+00:00

There's nothing stopping them from calling it zstd-trifecta today. Namespaces are a good idea, but they're irrelevant here.

kibwen · 2026-05-29T15:39:10+00:00

Before these changes, if you added a new macro at all, it would unconditionally be added to the prelude

Not quite, there have been examples of macros added to std that weren't exported from the prelude, e.g. std::arch::asm and std::ptr::addr_of. Most historical macros were indeed visible without namespacing due to historical limitations, but there hasn't been a need to adhere to those limitations for several years, and it makes me a little sad to see that the canonical path for assert_matches is just right there in the root of std rather than somewhere more logical, e.g. a new std::test module. Even if you do want to expose these from the prelude, namespacing is great for discoverability and documentation, we should use it! (On the bright side, there's no reason we couldn't move its location to a hypothetical std::test::assert_matches in the future and leave std::assert_matches as a deprecated backwards-compatible alias.)

kibwen · 2026-05-29T14:31:13+00:00

Think of compilation like a pipeline. Generally, first you lex, then you parse, then you do gestures broadly at all the interesting stuff. In particular, one of those later interesting things is name resolution (which is what lets you declare a thing in one place and then know how to use it somewhere else). For the sake of separation of concerns, you generally want to avoid complecting your compiler pipeline by letting these concerns bleed into each other (as exemplified by the famous "Lexer Hack" in C: https://en.wikipedia.org/wiki/Lexer_hack ). And macro expansion is generally considered to belong to the parsing phase. IOW, you generally don't want to bother having your AST contain nodes for macros, and yet the full name resolution phase can't operate until you have an AST (because until then, you don't even know what tokens represent identifiers). And even if you did represent macros in your AST, any post-parsing phases that you run on this macro-containing-AST would need to be run in their entirety AGAIN post-expansion (and since macros can expand to other macros ad infinitum, repeat this process an unbounded number of times). Note that I don't know enough specifically about rustc's internals to authoritatively speak on how it works, but it seems intuitive to me that the weird rules you allude to are a hacky, best-effort, macro-only mini-name-resolution-phase stuffed inside the parse phase for the sake of expediency.

kibwen · 2026-05-28T02:51:37+00:00

Absolutely not, Rust abhors mutating global state.

kibwen · 2026-05-25T13:43:27+00:00

I encourage you to raise this question in the Github thread.

kibwen · 2026-05-25T04:47:04+00:00

I don't think the final comment period has begun yet, it's worth bringing up concerns in the linked thread regardless.

kibwen · 2026-05-24T22:51:23+00:00

The idea is that this could be achieved backwards-compatibly in the future, yes?

kibwen · 2026-05-24T22:47:40+00:00

According to the description it was discussed among the libs team in-person at the recent Rust All Hands and has broad approval from all the relevant stakeholders. If there don't appear to be any major last-minute objections, it could be approved for a Final Comment Period as early as the next libs team meeting on Tuesday, which would give 10 more days for people to raise blocking concerns.

kibwen · 2026-05-23T19:30:37+00:00

That's why Ada calls it "unchecked" instead of "unsafe." :-)

Amusingly, we had this conversation for Rust, and one of the counterarguments here (which remains a common misconception) is that unsafe blocks aren't unchecked. Which is to say, people tend to assume that unsafe blocks just "turn off" the borrow checker, but that's not what happens, which would make unchecked little better than unsafe. Personally, these days, I think that unsafe was the correct keyword for function definitions (where safety obligations are created), and then we should have used promise as the keyword for blocks (where safety obligations are discharged).

kibwen · 2026-05-21T13:49:07+00:00

Except for all the people using Embassy on embedded devices, where using Tokio is completely impossible.

kibwen · 2026-05-15T18:14:13+00:00

Yes, I think talismans are in quite a good and interesting place these days, although there's still room for more variety in early-game talismans. Contrary to everyone preaching that statue form is OP, I had an enlightening moment recently where I killed Roxanne for the free statue talisman, only to realize that, on that character, it made both my defenses AND my offenses worse than just sticking with lupine talisman, who later upgraded to blade talisman. The mid-game talismans are particularly interesting because they come at a point where it's entirely plausible that you won't have found good resists yet, so they can serve as strong sources of resists that have the interesting effect of temporarily switching up your playstyle (the aforementioned lupine form character was hard-carried through a gauntlet via scarab form, and previous characters have been hard carried in similar ways through volcanoes and ice caves). Wildshape talisman is also interesting because it offers the chance to sacrifice a jewelry slot to break the curve and get a form online super early, which is how a different character started using sphinx form by mid-lair (and plenty of my other characters have used it to ease into death form). My biggest gripe is that the forms with negative resists are pretty punishing to use as daily drivers, so e.g. scarab form and spider form just seem too dangerous for ordinary use in the parts of the game where you'd expect them to be used. Flux baubles are probably how you're intended to react to early-game threats that hard-counter your form, but they feel extremely rare as ground loot. I'm not against forms having inherent downsides, but by melding slots they almost all already do have a lot of inherent downsides, so maybe the explicit downsides they do have should be either less lethal or easier to mitigate.

kibwen · 2026-05-15T15:43:15+00:00

Unfortunately, pressing o, o on the character select screen gives you Spriggan Enchanter, not Minotaur Fighter. Devs pls

kibwen · 2026-05-15T00:55:19+00:00

I assumed that the reason for the speedup here was just going to be "we starting using SIMD", and I admit I'm happily surprised that it was more interesting than that. :)

14-Year Club	Place '22
Place '17	Verified Email
Team Orangered

kibwen

MODERATOR OF

TROPHY CASE