if we can make this place just a bit better than before.

🏠 portland, or, usa
📆 mid-30s
💬 here to make friends and chat
🎮 video games
👩🏻💻 web development
👩🏻🏫 teaching others
🎨 digital aesthetics
💅🏻 makeup & jewelry
👗 gothic fashion
👩🏻🎨 making pixel art
🤘🏻 progressive metal
🎸 video game music
🟢 everything green
🌟 neon colors and transparent plastic
if we can make this place just a bit better than before.
Congratulations on being the proud parent of a new baby keyword!
Or is it still too soon to pop the champagne? I don't know the exact process, I'm sure there's lots of steps.
Can I ask the silly question? As someone that learned C many years ago but never actually completed a sizeable project beyond university class assignments, so I admittedly don't know what the challenges are in gigantic codebases with many authors, why do I want formal support for defer?
(I'm not intending to buzzkill rather I want to understand why this is a big deal so I can be excited with you kdjhgfjkhfkj)
Well I wrote an entire paper about it!! Here's a link to the design section that goes over a lot of the motivations/reasonings.
🫡
Not through completely, but positive reception means we're gonna be able to put it in C2Y soon!
best news of the day. thanks for making it happen!
i dunno if this is a path you all are actively pursuing, but i saw martin uecker's draft for a real generics system that looks like an interesting direction to take C as well https://open-std.org/JTC1/SC22/WG14/www/docs/n3212.pdf when it gets into talking about the runtime representation of metadata it gets a bit handwavey but i like the idea of a type system that can represent polymorphic operations without relying on either monomorphization or a heavy runtime, that seems like an underexplored design space
This one's beyond me, and the runtime storage bit makes me feel... icky, after my run ins with RTTI in C++. But, there's no exceptions or other things forcing anyone to be stuck with a dogshit-tier implementation, so maybe it can be done correctly here.
Still, it's not really my wheelhouse or something I'm excited about. I'd rather than static reflection so I could just build my own one of these...
yeah the runtime metadata bits struck me as the shakiest part of it as well. but it also seems like it's not really necessary for the core of what it's trying to do, which is what got my gears turning. like the example of qsort, you're passing it in a T* which gets passed along to the comparison callback as a T*, and that's all just pointers and you don't need any runtime information to move a pointer value from one place to another, only static checking on the call side that the types line up. just being able to line up pointer and function argument types would already give you a lot of expressivity to build on top of since you can then use "dictionary passing" to model typeclass-style polymorphism as needed.
now the other arguments like nel and width, you'd want to be able to derive from information about T, but i agree that that seems better suited to some kind of static reflection mechanism, since the information about the type you actually need to reify is so situational in practice. at first blush it seems like you could get pretty far with C++ style default arguments if they're evaluated at the call site, since that gives you the ability to write like
void qsort<T, n>(T (*base)[n], size_t nel = n, size_t width = sizeof(T), int (*compar)(const T*, const T*))
and get only the info you need from the call site.
holy shiiiiiiiiiiiiiiit. funny how this feels bigger than #embed and yet #embed looks to have taken much more work 