Rejected in Dec 9th TAG meeting
http://lang.lucee.org/t/tag-meeting-agenda-december-9th-8pm-utc/265/6

• In the languages that allow this it is purely a naming convention and function names may contain ? and !. There is nothing special about it.

• Can interfere with elvis / ternary operators

• Can already be done with brackets i.e. foo[‘bar?’] = function(){}; foo‘bar?’;

I'm in agreement with @Kai Koenig and @Adam Cameron - I find the ruby method harder to read and I'm not sure I see a compelling reason to do it short of saving a couple of bytes from the uncompiled source. I'd rather have the readability.

In Clojure, ? and ! can be part of an identifier and it follows the Ruby convention of foo? returning a boolean and bar! doing something not thread safe so, in principle, I like the idea of expanding the characters that can be part of an identifier. However, the possibility for breaking existing code is too great with ? due to code like foo?bar:baz in my opinion, so I'm with Kai and Adam in being opposed to this.

Looking at this in preparation for TAG meeting 16/09/15.

I don't think is a good idea, for both the reasons @Adam Cameron provided in the previous comment as well as from a language clarity point of view. I find the syntax just hard to read and we need to have a discussion if this kind of language feature is something we'd want for LuceeLang.

I think this only works in Ruby because the inbuilt methods also employ this syntax, so there's a uniform approach to having boolean-returning methods identified accordingly via the "?" This would make less sense with a CFML-based dialect as it would only be UDFs that have that "convention". And, TBH, I prefer the approach of prefixing the method name with some variation of the verb "to be" (eg: isValid()) or "to have" (hasNext()). That's convention enough.

As for the ! suffix, I don't think Ruby's convention here is very clear. I also think the distinction of "changes the object" or "returns a new object" is best left to a punctuation symbol to differentiate between.