Re: [RFC] Enable strict_types checking for curl_setopt()

On Sat, Apr 29, 2017 at 2:46 PM, Rowan Collins <rowan.collins@gmail.com> wrote: > In this case, we should acknowledge that userland cannot > (delta dirty backtrace hack) change behaviour based on > strict types inside the body of the function, and in most > cases neither sold internal functions. We can then decide > if this use case merits breaking that rule or not. > That's a conversation I can agree needs to be had. My position should be pretty obvious wrt curl_setopt(), but I would actually state that I'd go *further* by saying we should allow userland functions to know if they were called strictly or not, and the reason is: Union Types. Union Types (and intersection types and several other complex variants) have been argued against (reasonably, I would say) on the merit that the syntax gets ugly quite quickly and anyway, userspace and implement the equivalent of arbitrarily complex types in the opening body of their functions. What such workarounds *can't* do, is know how much to freak out when called incorrectly. If, as an author of a function, I *want* to respect weak mode, I don't have that option currently (barring said backtrack hacks). I realize this is getting off-topic by venturing into a whole separate RFC discussion, but as you point out it's a salient one when it comes to deciding how much intelligence curl_setopt() should apply. Then again, I think operator overloading belongs in userspace as well, so there's no accounting for taste. -Sara