probably about the same as like vapor smoothing abs with acetone. I think pla has solvents that work too but they’re much nastier

I’m sure all of them are just cherrypicked hotfixes from main tho

repr is generally assumed to be side effect free and cheap to run, so things like debuggers tend to show repr of things in scope, including possibly exit

also then it behaves differently between repl and script, since repr never gets run. to do it properly it has to be a new repl keyword I imagine, but I still don’t know if I’m sold on the idea

yeah fair enough. that wasn’t really my point and I wasn’t paying attention

yeah it’s incorrect bc it destroys multibyte characters, but no idea what you’re saying about u8 being a different type from unicode. the original code was reading bytes and converting them too? the typing isn’t the issue, you can still store utf8 as a series of bytes

c++ guarantees that calls to malloc are aligned https://en.cppreference.com/w/cpp/memory/c/malloc .

you can call malloc(1) ofc, but calling malloc_usable_size(malloc(1)) is giving me 24, so it at least allocated 24 bytes for my 1, plus any tracking overhead

yeah, as I said, in a stack frame. not surprised a compiler packed them into single bytes in the same frame (but I wouldn’t be that surprised the other way either), but the system v abi guarantees at least 4 byte alignment of a stack frame on entering a fn, so if you stored a single bool it’ll get 3+ extra bytes added on the next fn call.

computers align things. you normally don’t have to think about it. Consider this a TIL moment.

sure, but if you have a single bool in a stack frame it’s probably going to be more than a byte. on the heap definitely more than a byte

things that store it as word size for alignment purposes (most common afaik), things that pack multiple books into one byte (normally only things like bool sequences/structs), etc