| 13 Oct 2025 |
 lillecarl | I love how it was merged a year ago and I have been refraining from using pipe operator because I didn't know this.... Get my priorities straight man!!! | 14:51:35 |
| lillecarl | * I love (not) how it was merged a year ago and I have been refraining from using pipe operator because I didn't know this.... Get my priorities straight man!!! | 14:51:43 |
 bandithedoge | nil and nixd support it too | 14:52:12 |
| bandithedoge | and statix if you build from master | 14:52:22 |
 raitobezarius | warning | 14:53:11 |
| raitobezarius | pipe-operator in CppNix and pipe-operators in Lix are two different things | 14:53:19 |
 MangoIV | in what way | 14:54:11 |
| raitobezarius | I think CppNix only support one of the operator | 14:54:36 |
| raitobezarius | not both | 14:54:37 |
| raitobezarius | hence singular vs. plural | 14:54:40 |
| raitobezarius | and there might be some associativity thing I don't remember | 14:54:49 |
| raitobezarius | I don't use pip operators | 14:54:51 |
| raitobezarius | * I don't use pipe operators | 14:54:53 |
| MangoIV | in the PR it looks like it supports both | 14:55:21 |
| bandithedoge | isn't it the other way around? | 14:58:14 |
 thubrecht | The other way around | 14:59:03 |
| MangoIV | adding diverging syntactic sugar that doesn't even align well with the evaluation model, is not backwards compatible and requires enabling a flag sounds like an awesome footgun | 14:59:33 |
| lillecarl | In reply to @mangoiv.:matrix.org
adding diverging syntactic sugar that doesn't even align well with the evaluation model, is not backwards compatible and requires enabling a flag sounds like an awesome footgun At some point people have to try new things out. nixpkgs requires nix >=2.18(2023). If people want to use new things in their own repos that's one thing. Nixpkgs will be conservative either way. What better way to try out new syntax sugar in a fork and see if it sticks? | 15:03:01 |
| lillecarl | In reply to @mangoiv.:matrix.org
adding diverging syntactic sugar that doesn't even align well with the evaluation model, is not backwards compatible and requires enabling a flag sounds like an awesome footgun * At some point people have to try new things out. nixpkgs requires nix >=2.18(2023). If people want to use new things in their own repos that's one thing, Nixpkgs will be conservative either way. What better way to try out new syntax sugar in a fork and see if it sticks? | 15:03:19 |
| MangoIV | yeah I'm all for trying things out, but the kind of "progress" this brings is questionable, imo | 15:04:08 |
| raitobezarius | thx | 15:04:27 |
| raitobezarius | if I disappear and forget about it, please ping me | 15:04:33 |
 QuadRadical (Ping) | ok! | 15:04:40 |
| raitobezarius | language versioning would help tremendously but is hard to pull off | 15:04:51 |
| raitobezarius | this is the only feature like this | 15:05:03 |
| raitobezarius | coerce-integers is also this way | 15:05:06 |
| MangoIV | why I think this is a footgun and not an improvement:
foo |> bar is usually evaluated right to left, since bar is demanding foo in its body. So while in f# this might be a good idea since it is eagerly evaluated, it is not a good idea in lazy languages. I'm not sure if that's any evidence on this, but Haskell uses $ as the application operator, which is (conceptually) the same as <|. | 15:12:50 |
| MangoIV | as a users you might think that nix is evaluation foo and then applies bar to the result, but that's absolutely not what happens. | 15:13:58 |
| MangoIV | * as a users you might think that nix is evaluating foo and then applies bar to the result, but that's absolutely not what happens. | 15:14:17 |
| QuadRadical (Ping) | sure! NIX_REMOTE=local sudo nix build --no-sandbox .#checks.x86_64-linux.nextest | 15:43:17 |
