| 20 Mar 2026 |
 emily | (also for clarity: not just because you can get it wrong although that would be sufficient by itself, but also because even if you get recording the actual roots right it's quite likely that what you're telling the compiler with the resulting API shape will allow it to make assumptions that can lead to UB crashes) | 12:42:49 |
 piegames | I mean, envision this: A special wrapper type which handles the manual root declaration, together with a special constructor and a macro that ensure the only way to get such a value is pinned on the stack. I'm daydreaming here, but doesn't sound completely implausible | 12:46:33 |
| emily | did you read the blog post? :) | 12:49:07 |
| emily | you can do safe rooting APIs. it's just hard | 12:49:23 |
| emily | (and some of the obvious designs are broken) | 12:49:43 |
| emily | that's the part that's not for the faint of heart (but ofc not impossible). in particular though you can run into tradeoffs between the structure of your GC algorithm and how easy it is to use in Rust remotely ergonomically | 12:50:39 |
| emily | (e.g. a moving collector is certainly a bit rough and brings its own constraints, though those aren't particularly fun to interface with in C++ either) | 12:51:18 |
| piegames | In reply to @emilazy:matrix.org
did you read the blog post? :) Years ago | 12:52:17 |
|  @draupnir:lix.systems left the room. | 13:21:43 |
|  Patrick changed their display name from patrickdag to Patrick. | 14:52:31 |
 @rosssmyth:matrix.org | There is memory management toolkit
https://www.mmtk.io/ | 16:25:53 |
 raitobezarius | (yeah lix people looked at it a couple of times) | 16:26:26 |
| 21 Mar 2026 |
 ShalokShalom | There is also https://fil-c.org/ | 12:32:23 |
| piegames | Fil-C is awesome | 12:42:59 |
| piegames | Except that memory safety is not our main problem with C++ | 12:43:37 |
 K900 | I do wonder if cppnix built with fil-c would be 10x slower or less somehow | 13:10:06 |
| ShalokShalom | I read that compiled stuff becomes significantly slower, and that people use it to detect the issues, and not to run it it production. | 13:11:03 |
| ShalokShalom | What is? | 13:11:18 |
| raitobezarius | Fil-C is not memory safe | 13:13:45 |
| raitobezarius | Don't see any interest in that thing | 13:14:21 |
| piegames | In reply to @shalokshalom:kde.org
What is? Ergonomics, developer experience, stdlib | 13:15:45 |
 aloisw | It isn't? Memory safety is basically their headline claim … | 13:16:04 |
| piegames | Like, have you tried writing C++ code? C++ iterators are a work of madness | 13:16:32 |
 Qyriad | ^^^^^ | 13:18:14 |
| raitobezarius | it doesn't solve data races, it doesn't any sort of reasoning over mutable aliasing | 13:18:16 |
| raitobezarius | it has a spatial safety instrumentation pass to clang (so out of band accesses) | 13:18:36 |
| raitobezarius | a runtime support library and a concurrent GC for temporal safety | 13:18:45 |
| Qyriad | Writing production C++ is like writing production Bash. It is extremely difficult to write Correct C++ code and it is extremely difficult to debug | 13:19:02 |
| raitobezarius | "memory safe, bounds checked, GCed ahead-of-time languages" (in the sense Fil-C claim to be) have been existing for a long time | 13:19:26 |
| raitobezarius | * it doesn't solve data races, it doesn't do any sort of reasoning over mutable aliasing | 13:20:12 |
