On Wed, 26 Jun 2019 at 10:36, Benjamin Morel <benjamin.mo...@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]
