Its in the issue comments

    def foo?
      Object.new
    end

    foo?.class

since "foo?" is a valid method it would conflict with "?."

Edit: with ".?" looks like "foo?.?class"

Edit 2: side note, this would never pass a code review, the expectation of "foo?" is that it returns true/false.

> this would never pass a code review, the expectation of "foo?" is that it returns true/false.

95% of the time, yes. However, the "official" rule is simply that such methods must return a value that can be EVALUATED as true/false. There are plenty of methods in the ruby core/standard library which end in a "?" but do not return true/false, such as:

* File#size (http://ruby-doc.org/core-2.2.3/File.html#method-c-size-3F) returns Integer or nil.

* Integer#nonzero? (http://ruby-doc.org/core-2.2.0/Numeric.html#method-i-nonzero...) returns self or nil.

This misunderstanding of what "?" methods are allowed to return is an ongoing problem in the community, e.g. https://github.com/rails/rails/issues/20110

I'm no rubyist, but I think it is because ? is often used at the end of method names

This means that something like foo.thing?.bar is potentially ambiguous.

For whatever reason, Ruby allows method names ending with ? or !. AFAIK the general practice is to use ! for methods that perform a mutation in-place (e.g. list.sort! would sort a list in place, list.sort would be expected to return a new list) and to use ? for methods that return a boolean (e.g. list.empty? would indicate whether the list is empty).

Ruby inherited this from Scheme (and I prefer empty? over isempty or emptyp or variations thereof). They return truthy or falsy values and not true or false (the is* macros/functions in C only guarantee zero and nonzero as return value either).

>AFAIK the general practice is to use ! for methods that perform a mutation in-place The ! suffix is rather loosely defined as it just means the user should be cautious/the method might have "dangerous"/surprising behavior.

Your description is usually correct but only when a non-suffixed version exists and not even then the behavior has to match your description. There are also a lot unsuffixed mutating methods. See also Kernel#exit vs. Kernel#exit! (immediate exist/exit handlers aren't called) or Tempfile#close vs. Tempfile#close! (close and unlink).

> AFAIK the general practice is to use ! for methods that perform a mutation in-place

That's not quite the usual statement of the rule: ! is for methods where there exists a "dangerous" version and a "less dangerous" version, to denote the more dangerous version. A common example of that is methods where one version returns a copy of the original object with some modification applied and the other version modifies the original object in place, but IIRCT that's not the only distinction it is used for in the standard library and, more importantly, in-place mutations that aren't paired with a "return-a-modified-copy" method don't get the !.

Please define IIRCT as I cannot find what it's meant to mean.