Re: [RFC] Strict operators directive

On Wed, 26 Jun 2019 at 10:36, Benjamin Morel <benjamin.morel@gmail.com> wrote: > Oh, I see. You mean that only replacing some of the current results with > TypeErrors would be acceptable; returning a different value would not. > This makes a lot of sense, but once again prevents the language from slowly > moving towards something different (and better), leaving it stuck in its > legacy forever. > If we're talking about combining operator overloading and type juggling in the way that JS does it, I would definitely debate whether that's "better". It leads to the weird circular situation where to know what an operator means, you have to look at the types; but to know how the types will be interpreted, you need to know what the operator means. Perl is a notable contrast: the types of operands are deduced based on the operator, but there are different operators to force them to different types. So 23 < 4 and "23" < "4" are both numeric comparisons, so return false; but 23 lt 4 and "23" lt "4" do string comparisons, and return true. That way the user's intent is clear, but you don't have to manually cast values or remember how different combinations will be interpreted. > I'm starting to believe that a joint effort to fork PHP if the only way out > If what you want is a fork of PHP with stronger typing, then take a look at Hack https://hacklang.org/ Regards, -- Rowan Collins [IMSoP]