Random thought - cfparam could be more helpful if it would set default value when variable not match defined type. Use case - bots trying to put garbage to URL parameters to create error or SQL injection, single <cfparam> line would look nicer that cascade of <cfif>s

A closure could be interesting, too. Sor example to validate the value automatically to a regex or a list of allowed values.

I think flexibility is important for a tag such as cfparam. It is crucial that it leaves room for the developer to add extra validation. If and when needed. Software development will always be an arms-race between us, developers on the inside, and intruders from the outside. The use case that you propose is just one out of a myriad different attempts the intruder may make to breach our defences. A tag cannot anticipate them all. It can only hope to have the most vital drawbridges in place.

All I want that tag won't throw an error, but defaulted a value instead, just like it does for empty value. That will save couple of keypunches and leave code clean. CFPARAM itself is just a 'syntax sugar' for "cfif not isdefined and not len eq 0 blabla", but a nice one.

I don't think I'd want that behavior. Type validation to me should be a hard stop, not a change-the-value-behind-the-scenes sort of thing. Sounds unexpected and hard to debug.

behaviour of cfparam can be flagged, adding thowonerror="true" attribute for example. I hate to see logs sh*t-loaded with - literally - 10000s of errors produced by attempted SQL injections. One day they tried to exploit date param and sorting URL param - which produced error, but I would like to gracefully turn error params into default params. No big deal, CFIF for the win, but CFPARAM could save some screenspace

custom tag/function with the same argument signature wouldn't be any more screenspace?

That's really a failure in CF's logging strategy