I understand where you’re coming from,
and I completely disagree
false is blank, but it’s not nil,
however, in some cases, falseness should not be validated
“validates_presence_of :aggrees_with_contract” is correct, requires the user to check the contract
“validates_presence_of :displays_photo_for_guests” is incorrect, because it’s only a question and it’s ok if the user forgets or chooses not to mark
[false, nil].map &:blank?
=> [true, true]
[false, nil].map &:present?
=> [false, false]
[false, nil].map &:nil?
=> [false, true]
If it’s OK if the user doesn’t send this value, why are you validating for it to be present? Set a default for your boolean column (which you should be doing anyways ) and have a nice life.
While technically you could say that “false” is “present”, it would be really unintuitive for most of the people as present? is supposed to be just opposite of blank? and is used to check for truthiness. Additionally present? is used in Rails app for a long time, so even if part of Rails Core had agreed with your arguments, I would be really surprised seeing this changed.
As you can see here: https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/object/blank.rb#L55, blank? is also implemented in FalseClass to always return true, so yes, it was deliberate