Issue #16348 has been updated by duerst (Martin D=FCrst).=0D
=0D
=0D
I personally think that we should be restrictive in adding new methods to `=
Symbol`. Otherwise, this very quickly becomes a slippery slope, and the dis=
tinction between `Symbol` and `String` becomes less and less clear.=0D
=0D
I was personally surprised when I implemented feature #10085 that `Symbol` =
had `#upcase` and friends, I wouldn't have guessed that.=20=0D
=0D
----------------------------------------=0D
Feature #16348: Proposal: Symbol#start_with?, Symbol#end_with?, and Symbol#=
include?=0D
https://bugs.ruby-lang.org/issues/16348#change-82710=0D
=0D
* Author: kamipo (Ryuta Kamizono)=0D
* Status: Open=0D
* Priority: Normal=0D
* Assignee:=20=0D
* Target version:=20=0D
----------------------------------------=0D
When replacing #match? to #start_with?, #end_with?, and #include? for some =
reason (address to https://bugs.ruby-lang.org/issues/13083 etc), we frequen=
tly hit missing Symbol#start_with?, Symbol#end_with?, and Symbol#include? i=
n spite of Symbol#match? exists.=0D
=0D
https://github.com/rails/rails/commit/63256bc5d7dd77b2cce82df46c53249dab2dc=
2a8=0D
https://github.com/rails/rails/commit/a8e812964d711fa03843e76ae50f5ff81cdc9=
e00=0D
=0D
Is this inconsistency intentional?=0D
If not so, Symbol#start_with?, Symbol#end_with?, and Symbol#include? preven=
ts such like an issue.=0D
=0D
=0D
=0D
--=20=0D
https://bugs.ruby-lang.org/=0D