russell
rpjohnst.bsky.social
russell
@rpjohnst.bsky.social
the proposals I've seen for actually adding negative bounds also tend to approach that by removing "excluded middle" style reasoning from the solver.

so if T merely lacks `impl Tr` you don't get `T: !Tr`. you need `impl !Tr for T` to get `T: !Tr`, and then it's a commitment *never* to impl it
October 21, 2025 at 2:59 PM
something I haven't seen in the thread yet is that this would introduce a bunch of unnecessary duplication at codegen time, because rust doesn't have a way to erase type parameters
October 21, 2025 at 2:37 PM
rust does currently default it to (), but due to the possibility of uninitialized values (important for rust's niche) it is not true that nothing ever needs the concrete type.

they went to change the default to ! when upgrading it to a real type (it wasn't before!) and had to do it over an edition
October 21, 2025 at 2:34 PM
I've implemented some of these for fun but never benchmarked them seriously- I'd be super curious to see how the various e-free constructions compare to removing epsilons after the fact, in terms of practical performance
September 13, 2025 at 5:21 PM
Other e-free NFAs have fewer states than Glushkov's: both Antimirov derivatives and Ilie & Yu's follow automaton merge equivalent states of the position automaton. (And while Glushkov and Antimirov go e-free directly, Ilie & Yu go via an e-NFA which is smaller than Thompson's.)
September 13, 2025 at 4:17 PM
I like to think of epsilon edges as corresponding to the regex tree edges from the non-symbol nodes: they're a linear-size way to encode the quadratic-size relation between pairs of adjacent symbol occurrences, which works by funneling through a shared parent node
September 13, 2025 at 4:09 PM
Glushkov's (i.e. the "position automaton", and more generally any epsilon-free NFA) is worst-case quadratic to construct, while Thompson's is linear. This is just due to edges, though- Glushkov's generally has fewer states because it's always exactly 1 + the number of symbol occurrences in the regex
September 13, 2025 at 4:04 PM
my neighbor told me ivys keep rejecting his applications so I asked how many he applied to and he said he just goes to the computer and writes a new essay afterwards so I said it sounds like he's just feeding essays to admissions offices and then his daughter started crying
September 3, 2025 at 3:39 AM
the other thing rust gets out of it being unique is that monomorphizing on that type eliminates the indirect call (though whether you want this all the time is another question)
August 28, 2025 at 5:10 PM
earlier on I remember a few people (eddyb?) arguing for this kind of full featured existential as the thing trait objects desugar to, possibly as part of the "custom dst" stuff. would make a lot of things really convenient!
August 28, 2025 at 3:53 PM
if you want to be really pedantic about the "closure over fields" thing, then `self` would be a separate feature that only gives you recursive access to the methods, and fields would be accessible exclusively through lexical scope
June 27, 2025 at 12:42 AM
also including some entertaining back-and-forth blog posts arguing with Russ Cox: matt.might.net/articles/par...
Yacc is dead: An update
matt.might.net
June 26, 2025 at 8:45 PM
lua and js (not sure about php) use different implementations within the runtime at least
June 22, 2025 at 2:56 PM
There's also a synergy where value semantics make it easier to store things in-line, making GC less expensive, and in the other direction having a GC gives you the flexibility to avoid excessive copying in some cases, making value semantics less expensive.
May 27, 2025 at 11:52 PM
Instead what you want is to lean more toward value semantics by default, and make the "soup of mutable objects" case more visible and opt-in. And having a GC makes this case way simpler, both in high level languages and in low level languages.
May 27, 2025 at 11:52 PM
My take on the discussion here about borrow checking and GC is that a language at this level of abstraction both 1) should have *some* answer for local reasoning about state, but 2) it almost certainly should not look anything like borrowck.
May 27, 2025 at 11:52 PM
objects are & and functions are ⅋ so they should be unified into sum-of-products codata, the same way + and × are for data
May 16, 2025 at 10:55 PM
it's the operation of creation, of the *other* &mut- that's the operation in stacked/tree borrows that invalidates conflicting references.
May 12, 2025 at 4:24 PM
how can they be statically invalidated? you can stash them off in whatever arbitrary (#[may_dangle]) data structure you want, and NLL + stacked/tree borrows still agree on when they get invalidated: play.rust-lang.org?version=stab...

there's no drop glue you could generate even in principle here
Rust Playground
A browser interface to the Rust compiler to experiment with the language
play.rust-lang.org
May 12, 2025 at 4:13 PM