pennae

not sure why this is controversial. we already have the facility to add arbitrary side effects, it's just less convenient (requiring an explicit template instantiation and an implementation of `parse`...

this is a language-breaking change and cannot be done just like this. if we ever get a nixlang revision a la rfc137 this should *absolutely* be part of the syntax...

since this was listed as "blocked on parser rewrite" in the meeting notes but #9971 was rejected outright, we will add here: this should also be rejected outright for the...

> @pennae Does that mean you disagree with the idea of keeping the same behavior, while adding a warning about this suspicious syntax? without infrastructure that would also allow #9971...

@thufschmitt ok, the we're on the same page after all :) very good

important semantic nitpicking: `__curPos` is not a keyword, it is *specific* magic semantics for *specifically* the simple identifier `__curPos` in *specifically* value position

> Though it really should behave as a keyword. disagreeing on that. in the current implementation it should behave like a magic identifier (cf `$RANDOM` in bash), but in a...

rebased onto current master. also ran some perf tests, normal operation doesn't notice the change but `nix-env -qaP --out-path` sees about 5% runtime improvement.

@roberth when can we expect a review? this is kind of blocking parser work now (one dependent PR is up, another two in preparation).

rebased to fix merge conflicts.