On 14 Sep 2014, at 15:56, Andrey Andreev <n...@devilix.net> wrote: > It seems a bit political ... A lot of people want either strict type > hints or type casting hints, but because the people on this list can't > get to agree on any of the two, this RFC tries to make a compromise > that, IMO, satisfies nobody. It's done not for the benefit of > everybody, but just so we can say that PHP has "scalar type hints". > I've said this in the RFC discussion thread: In order to satisfy both > sides, instead of arguing which is the one and true way, just > implement both.
I’m not sure it satisfies nobody. I realise a lot of people would prefer strict types, but plenty are still in favour of this as a compromise: http://strawpoll.me/2463199/r - Might not be representative, but I held a poll on Twitter and StackOverflow. There are the results. 67 would vote in favour of strict hints (à la Hack), and 36 would vote in favour of this RFC, with only 5 willing to vote against it, versus 10 voting against strict hints. Note that the options aren’t mutually exclusive. > That is also why I suggested altering the proposed syntax here from: > > function foo(int $bar) > > to: > > function foo((int) $bar) But it’s not a cast. Such a syntax would be misleading. You would reasonably expect the following two functions to be equivalent: function foo($bar) { $bar = (int)$bar; } function foo((int) $bar) { } Yet they are not equivalent at all. > Whether it applies more strict rules or not, this RFC is clearly about > type _casting_ hints, while the used syntax has so far only been used > for strict type hints. Well, we haven’t had any scalar hints so far. It’s also worth noting that the documentation for PHP uses this style even though internal functions are not strict. Furthermore, scalar types in PHP are fundamentally different from non-scalar types. We do not have weak typing for non-scalars: there are no implicit casts between non-scalar types. However, we implicitly convert and juggle the scalar types all the time. > I know some would argue that this is a side > effect because you can't cast to a specific class type, but that's not > the point - the result is a strict type hint and that's what people > are used to. This is both inconsistent AND prevents PHP from having > strict scalar type hints in the future (because of the used syntax). Strict hints would still be possible with different syntax. However, I’m not sure they’re a good idea. Strict hints would be abandoning PHP’s weakly-typed nature, and would segregate userland functions into two kinds: strict and non-strict. I also don’t expect that would pass internals anyway. I don’t think permitting multiple options is really the way forward, that sounds like the worst of both worlds. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
