add optional boolean trim to isEmpty(string, [ignoreWhitespace=false])

Adding random boolean arguments to functions is already a bad idea for readability – and we have plenty of those in CFML today, unfortunately. Big downvote from me on all the grounds that Adam has listed. This is just poor language design.

Another concern here I have is that I see no reason to treat whitespace as "special" when it comes to determining whether a string is empty. A space is just as much string content as "a" or "0", and if a string has any of those in it, it's not empty. Quite simply, " " is not an empty string. And isEmpty()'s job is purely to test for empty strings. If someone wants to first trim a string because they don't want leading and trailing whitespace, and THEN check if the string is empty, then that's how they should code it.

Also, isEmpty() can have meaning beyond strings, eg [], {} could be considered "empty", so there could just as easily be Array.isEmpty() and Struct.isEmpty(), to keep a uniform interface with other object types which could be empty (a Name object could be "empty" if it has no firstName and lastName values). Having an optional "trim" argument in that interface makes no sense outside of the specific string case (and I don't think it even makes sense in the string case either).

implementing this does not prevent you in any way from writing the code in your preferred way – your code will still run, albeit slower than if you use the proposed enhancement.

adding a BIF is a much more intrusive solution that can break code if someone has UDF with that name already, and bloat the API a-la PHP style.

I'm with @da_cameron, adding a boolean argument isn't going to do anything for readability.

Compare: `someString.trim().isEmpty()` to `someString.isEmpty(true)` the former is a lot clearer.

If anything, we should take a page from Apache Commons and add `isBlank` for this functionality, as it has semantic meaning and @21solutions can get the performance benefit they want.

Here is an off the wall idea - and I fully expect it might not be possible - but could the syntax parser look for things like this and rewrite them before compilation? eg: the parser sees:

```isEmpty(trim(variable))``` or ```variable.trim().isEmpty()``` and then is able to rewrite it to your proposed solution that gives speed improvements?

I'm with adam, the readability of the code is as important here, and knowing what that true means is not conducive to that. That said, i'm personally not against something like this - it won't be required that you use it, you could still write it as .trim().isEmpty() if you are so inclined. But it would be great to find ways to have our syntatic, readable cake and get the speed improvements too. I would imagine there could be lot of places we could use something similar if it is possible - at least where there is guarantees against side effects.