Re: [Discussion] Stricter implicit boolean coercions

>> In one application recently I actually had the string "false" (coming >> from a form transmission) being passed to a boolean argument and leading >> to true, which definitely was unintended. > >But "false" is a perfectly sensible thing to pass as a string in an >API (as HTTP is a string based protocol). As is 'faux' if your API is >used by French speaking programmers. > >You need an layer of code that converts from strings to the precise >types your API needs, rather than just passing values straight >through. In my opinion, this is a good point in the RFC's favour, as the depreciation warning will show up in exactly those places where this conversion layer was erroneously missing.