[Feature Request] Provide a mechanism to ensure at compile-time that all path params that a handler-proc uses are in the route the handler is used in

[PhilippMDoerner]

This one came to me as I started writing procs that build generic prologue handlers:

How can I ensure, that the URL path param that my handler assumes is there (e.g. "id") is actually provided via the URL at compile time? Basically, if my awesomeHandlerProc uses a path param "ids" while the url actually only contains a path param "id" I want the compiler to scream at me.

This would eliminate an entire set of runtime errors where your handler tries to access a URL param and it's miss-spelled, or you mixed up which URL it should belong to etc.

It should strictly speaking be possible, the URL and which handler is associated with which URL are both known at compile time. In terms of how to go about it though, I'm not sure how this could be achieved though. Particularly since prologue itself wouldn't know which URL params any prologue-user would make use of in their handler.

[PhilippMDoerner]

Does anyone have any idea how this could even be architected? Outside of possible breaking API I can't even imagine anything concrete. You'd somehow have to analyze the string of a given route and then, at compile time:

1. generate a custom object type based on that string. It has 1 field per path parameter that it can contain + 1 table field for query parameters I guess
2. Generate procs that extract the strings from the URL as desired and convert them into the correct types according to the used regex in the path
3. Somehow replace StringTableRef in Request.pathParams and have that generated type be put in there.

None of that sounds easy in any way shape or form and arguably way too complicated for the benefit it brings, assuming the current architecture. But I'm somewhat struggling to even imagine how this system could be changed to allow for compile-time validation.