[Jensson]

> because developers thought they can take input in one format, "escape" it enough, sprinkle with addslashes and things will work

But that is exactly what the solution is, you escape user strings, there is no other solution to the problem. Either you do it yourself or you use a library to do it, but the end result is the same, I'm not sure why you think this is impossible to do when it has been done successfully for decades.

The problem is that many fail to escape strings correctly, not that it is impossible to do.

[friendzis]

Escaping/sanitizing is required when providing "command+data" inputs to external engines. It's error prone. One needs rigorous escaping done just before the output. Multiple escapes can clash.

> But that is exactly what the solution is, you escape user strings, there is no other solution to the problem

The correct way is to use interfaces that allow separation of command and data inputs. With SQL prepared statements are used. With HTTP data is put in request body or at least after the ?. With HTML data URLs are used. And so on.

> The problem is that many fail to escape strings correctly, not that it is impossible to do.

I really don't want to argue whether escaping correctly is possible at all. Every possible substring sequence, escaping attempts included, that can be interpreted as command by the interpreting system must be accounted for. I would rather avoid the problem altogether, if possible.

[stefan_]

No, escaping is precisely not what you do. Escaping is the hack you add because you didn't consider separating code and data in the first place.

Do not offer an API that mixes these two things.

[blowski]

What about parameterised queries?