On Thu, 24 Jun 2021 at 21:25, Dan Ackroyd <dan...@basereality.com> wrote:
> > Please can you go into some detail about what you think people are > > meant to do when they detect a non-literal used where a literal is > > expected? > > There is a whole load of hand waving going on of "you can protect > yourself!" but then no detail of what this RFC proposes people > actually do, which means people can't evaluate whether it's worth > adding or not. > As noted by Lauri Kenttä, "I'd imagine people use custom error handlers which report errors (warnings, notices) to ticket system or email or some other convenient place, so they don't need to read through logs." By using a simple function, it allows the library to handle the situation however it likes. In the RFC there is a "How it can be used by libraries" link, which shows how a library can easily provide options for a basic warning, exception, or just ignoring. But a library could also only run these checks in development mode (off in production), or do additional checks to see if the value is likely to be an issue (value matches a field name), etc. https://github.com/craigfrancis/php-is-literal-rfc/blob/main/justification/example.php > > Why are you prioritising speed of adoption, over reducing the cost of > > using this feature for projects over say the next 5 or 10 years? > > I think this feature should be of most value to teams with large > code-bases, where maintaining the code (and figuring out security > problems) has a much higher cost than for small code-bases, where this > feature might not deliver much value. But by carrying the literal flag > through on string concat, that results in it being annoying to use for > teams with large code-bases....which seems self-defeating. > As noted by Rowan Tommins, "It would also not solve the problem of the assertion only triggering in production without a careful integration test. That can only be solved with a static analyser, which would also have enough information to isolate the cause." Static Analysis via `literal-string` is now supported in Psalm (thanks Matthew Brown): https://psalm.dev/r/9440908f39 And with a dedicated type (a future RFC, as it needs to cover different questions that build on this implementation), that would make Static Analysis even better for debugging, rather than a solution that triggers exceptions for everyone. Craig
