| 20 Apr 2026 |
| picnoir changed their display name from Picnoir to picnoir. | 10:04:33 |
| 21 Apr 2026 |
| zoë (@blokyk) changed their display name from zoë (she/her) to zoë (@blokyk). | 03:08:40 |
zoë (@blokyk) | <disclamer>i'm not good at c++ / don't know much about the stdlib</disclaimer> i've seen an old FIXME by jade_ about getting rid of libutil::enumerate in favor of std::views::enumerate, but a lot of uses of it are for libutil::Generator, which don't seem like they can be easily substituted given Generator's unique semantics (notably nested generators, which i don't think is supported by any stdlib types?). so is that comment still relevant? or so, then do you plan to replace non-generator uses of it and keep Generator, or will Generator also be replaced at some point? | 09:33:08 |
zoë (@blokyk) | * <disclamer>i'm not good at c++ / don't know much about the stdlib</disclaimer> i've seen an old FIXME by jade_ about getting rid of libutil::enumerate in favor of std::views::enumerate, but a lot of uses of it are for libutil::Generator, which don't seem like they can be easily substituted given Generator's unique semantics (notably nested generators, which i don't think is supported by any stdlib types?). so is that comment still relevant? if so, then do you plan to replace non-generator uses of it and keep Generator, or will Generator also be replaced at some point? | 09:33:28 |
zoë (@blokyk) | * <disclamer>i'm not good at c++ / don't know much about the stdlib</disclaimer> i've seen an old FIXME by jade_ about getting rid of libutil::enumerate in favor of std::views::enumerate, but a lot of uses of it are for libutil::Generator, which don't seem like they can be easily substituted given Generator's unique semantics (notably nested generators, which i don't think is supported by any stdlib types?). so is that comment still relevant? if so, then do you plan to replace non-generator uses of it but keep it and Generator, or will Generator also be replaced at some point? | 09:33:48 |
Qyriad | LLVM libc++ doesn't have views::enumerate() yet :( | 09:34:36 |
Qyriad | Not sure about Generator though | 09:35:20 |
zoë (@blokyk) | oh i'm so dumb... i somehow misread the linked page about its stats ;-; | 09:35:48 |
zoë (@blokyk) | * oh i'm so dumb... i somehow misread the linked page about its status ;-; | 09:36:21 |
Qyriad | I did too the first time | 09:36:28 |
zoë (@blokyk) | it's surround by bright green Complete so it's easy to mistake | 09:36:55 |
zoë (@blokyk) | esp. weird because clangd doesn't flag it and gives you proper type checking for it | 09:37:36 |
Qyriad | There's an open PR for it, but views::enumerate is surprisingly tricky https://brevzin.github.io/c++/2022/12/05/enumerate/ | 09:37:56 |
zoë (@blokyk) | haha yeah i stumbled on that exact article while trying to understand how to use it | 09:38:17 |
Qyriad | Because, yknow, C++ | 09:38:17 |
zoë (@blokyk) | god stack traces being a Generator has been a thorn in my side every time i've made a repl-related cl >:| | 09:40:53 |
zoë (@blokyk) | * god stack traces being a Generator has been a thorn in my side every time i've made a repl-related cl, it's so annoying to work with >:| | 09:41:11 |
zoë (@blokyk) | * god stack traces being a Generator has been a thorn in my side every time i've made a debugger-related cl, it's so annoying to work with >:| | 09:42:18 |
zoë (@blokyk) | * god stack frames being a Generator has been a thorn in my side every time i've made a debugger-related cl, it's so annoying to work with >:| | 09:44:08 |
Sergei Zimmerman (xokdvium) | In reply to @qyriad:katesiria.org There's an open PR for it, but views::enumerate is surprisingly tricky https://brevzin.github.io/c++/2022/12/05/enumerate/ I hate that enumerate uses a signed type… | 10:11:29 |
Qyriad | gods I know right | 10:11:58 |
Sergei Zimmerman (xokdvium) | It’s like the classic C++ committee stupidity. Like why difference_type | 10:12:27 |
Sergei Zimmerman (xokdvium) | There’s a mandatory talk about views::filter | 10:13:51 |
Sergei Zimmerman (xokdvium) | It’s so full of footguns like being not thread safe | 10:14:06 |
Sergei Zimmerman (xokdvium) | Or rather “it’s not thread safe if you call begin() for the first time concurrently” | 10:14:48 |
Sergei Zimmerman (xokdvium) | And modifying elements is also UB when it changes the predicate | 10:15:38 |
antifuchs | * All the lixcon talks I’ve seen recordings of so far are super great! Thanks for sharing them with all of us who couldn’t make it | 12:00:02 |
zoë (@blokyk) | with regards to #1175, does saving each typed line ourselves (e.g. in an std::list or std::vector?) and then appending it to the file sound good? if so i can try to make a CL for it, but i want to get a vibe-check for it first | 12:26:04 |
zoë (@blokyk) | * with regards to #1175, does saving each typed line ourselves (e.g. in an std::list or std::vector?) and then appending it to the file sound good? if so i can try to make a CL for it, but i'd like to get a vibe-check for it first | 12:38:30 |
zoë (@blokyk) | * with regards to #1175, does saving each typed line ourselves (e.g. in an std::list or std::vector?) and then appending it to the file sound good? if so i can try to make a CL for it, but i'd like to get a vibe-check about it first | 12:38:35 |