Apologies, first time, still learning and have no historical context - timing is what it is.
Proposal type: Concept Implementer: Unknown, fallback to me after slow learning Presumed simple implementation as the pattern should already be in place: Cast of (string) -> __toString() - already implemented Cast of (bool) -> __toBool() Cast of (int) -> __toInt() Cast of (object) -> __toObject() …and so on. Alternative implementation using an interface: \CastableTo{type} Extreme implementation: Make both of the previous available. Known unknowns: - Level of interest in something like this in the PHP community outside of one upvote on a Stackoverflow question I submitted: https://stackoverflow.com/questions/62747837/php-7-tostring-or-other-interface-for-boolean-values <https://stackoverflow.com/questions/62747837/php-7-tostring-or-other-interface-for-boolean-values> - Whether this conversation or proposal has already occurred. - The historical conversation leading to the creation of the __toString() method (and stopping there). - The current conversation around using magic methods in general and specifically when defining a cast response. - Enough details on PHP internal development to implement myself (this is the first time in 20 years I felt I couldn’t comfortably accomplish what I wanted to, thanks for that). - What potential collisions could occur if someone (me) wanted to implement all possibilities in a single class. - Right now __toBool() would be of the most personal benefit - if proposal is converted to an RFC, would it be better (faster/smoother) to do one RFC for all the cast possibilities - or to have an RFC for each cast separately? Thank you for the consideration, information, and feedback. Cheers, Josh ps. Also, apologies again for walking into a new space on a mission, not my normal approach. pps. The primary project inspiring the proposal: https://github.com/8fold/php-shoop <https://github.com/8fold/php-shoop>