| 15 Nov 2025 |
 Katie | and have /foo/.match be essentially syntax sugar for builtins.match /foo/.source | 18:42:37 |
 K900 | FOr one | 18:42:48 |
| K900 | * For one | 18:42:50 |
 aloisw | In what sense is the empty list "conventionally falsy"? | 18:43:22 |
| K900 | In the any other language but Nix sense | 18:43:56 |
| Katie | empty list is truthy in JS | 18:44:50 |
| aloisw | That's straight up not going to work because /foo/.match is a path literal. And yes, you could make it work with a space, but at the cost of introducing another footgun if the user forgets that space. | 18:45:01 |
| Katie | which I think why no match returns null | 18:45:05 |
| K900 | I said language | 18:45:30 |
| K900 | Not eldritch abomination | 18:45:30 |
| Katie | MMMM... got it, yes, that is a problem | 18:45:37 |
| Katie | maybe (/foo/).match | 18:45:50 |
| Katie | or maybe a different bookend token | 18:46:10 |
| Katie | |foo| | 18:46:18 |
 antifuchs | Empty list is falsy in the originator of the meme, lisp (fixed in scheme though); still not sure I love it there | 18:46:21 |
| aloisw | It's quite reasonable given how builtins.match semantics work. Unmatched capture groups give null, matched capture groups give the list of its submatches. | 18:46:31 |
| aloisw | Same problem of being a footgun if the user leaves off the seemingly redundant parenthesis. | 18:47:00 |
| Katie | Yeah, I don't love the parentheses idea | 18:47:24 |
| aloisw | Like I don't see the point of syntactic sugar that makes an uncommon operation look slightly shorter at the cost of adding massive footguns. | 18:47:29 |
| Katie | I don't know how convincing it will be to you, but I can try to offer my perspective there on the appeal for me | 18:48:38 |
| Katie | I have... god only knows what kind of dyslexia-adjacent cognitive bullshit going on in addition to my really crappy vision. RegEx literals being their own unique semantic construct unto themselves that IDEs can differentiate and color/highlight as such is a HUGE benefit to me. I'm loathe to praise JavaScript for almost anything, but RE literals are a huge win for me there that I really miss when writing say, Rust. I find Nix Path Literals exceptionally ergonomic for very similar reasons. It just helps me see and understand much more clearly what I'm looking at, vs. just another string | 18:53:25 |
| Katie |
| 18:54:10 |
| Katie | * plus shorter is nice too | 18:54:16 |
| Katie | at the risk of sounding naively optimistic, I imagine their must be some happy path to deliver the benefits sans footguns | 18:55:40 |
 522 it/its ⛯ΘΔ | usage aware highlighting (if this is used inside a builtins.match / passed to something that takes a regex(not that nix really has a type system that'd make that easy to determine)) would also help that | 18:56:32 |
| aloisw | I feel like highlighting the first argument of builtins.match will get you 90% of the way for the thing you have mentioned. | 18:56:33 |
| 522 it/its ⛯ΘΔ | without needing language changes | 18:56:36 |
| 522 it/its ⛯ΘΔ | treesitter can do some level of that (things passed to writeShellApplication are highlighted as bash) | 18:57:37 |
| 522 it/its ⛯ΘΔ | 
Download image.png | 18:58:39 |
| 522 it/its ⛯ΘΔ | plus this to manually specify the language, though that's quite verbose for single line things | 18:58:56 |
