On Sat, 12 Jun 2021 at 18:00, Craig Francis <cr...@craigfrancis.co.uk> wrote:
> I'd like to start the discussion on the is_literal() RFC: > https://wiki.php.net/rfc/is_literal > Hi Internals, Following up on the is_literal() RFC, thanks for the feedback. It looks like there are only 2 minor open issues - updating the implementation to allow integers, and what to call the flag/function. Matthew Brown wants to support integer values, simply because so much code already includes them, and I cannot find a single way that integers alone can cause issues from an Injection Vulnerability point of view (but if anyone can, I absolutely welcome their input). Other variable types like floats and booleans will still be excluded (because the value you put in often is not what you get out, e.g. true/TRUE being converted to "1"). Which leads us to the name, because "is_literal" may be, uh, too literal. So can we come up with something better? It needs to be a name that suggests: This variable contains programmer defined strings, integers, and interned values (as noticed by Claude Pache and Rowan Tommins). Ideally staying in the standard convention of ‘is_singleword’. Joe has suggested is_known(), where "we have the concept of known strings internally", which I like (though might clash with more userland functions than ‘is_literal’). Last night I also wondered about `is_constrained()`, as the value has limited sources. But I'd also welcome more suggestions, and am happy to set up a poll (thanks Dharman for the strawpoll.com suggestion). I've also updated the RFC Future Scope to note how this could be a dedicated type (thanks someniatko, Matthew Brown, and Dik Takken); and I'm really impressed to see the addition to Psalm so quickly. Craig
