Or maybe just renameroute_parameters toparams?
#[Route('/foo/{id}', requirements: ['id' => '\d+'], condition: "params.id < 100")]

Thanks, that's a nice feature, and the implementation is perfect. This leaves me only bike-shedding :D

So: what about injecting the parameter as variables directly in the expression? eg#[Route('/foo/{id}', requirements: ['id' => '\d+'], condition: "id < 100")]

Of course we should then forbid to use context/request as var names, or at least give them higher priority.

Or maybe just renameroute_parameters toparams? #[Route('/foo/{id}', requirements: ['id' => '\d+'], condition: "params.id < 100")]

Thanks for the review, I'verenamed the variable toparams. I like the idea of injecting the parameters as variables as well, but as you mentioned, that might cause collisions with var names. This seems like the safer option, but if you want, I can inject them instead, I'm fine either way.

I prefer injecting aparams variable.
From prior experience in the@Security annotation of FrameworkExtraBundle, mixing predefined variables and user-defined variable names in the same expression is a mess regarding conflicts (and still requires injecting a variable allowing to access params that could not be injected as variables due to the conflict, with a weird DX when a few param names need a special access pattern, and a forever-freeze of the list of predefined variables to avoid BC breaks)

I agree with stof.

I think it would be ok to still release this in 6.1 before the RC. It fits with#44405 and it would make sense to document/new in symfony this together.

Thank you@HypeMC.