Moreover, having these declarations actually be part of the language, even if the interpreter itself cannot enforce them ahead-of-time, means tooling can be built around it, and we can use them for optimisations in the VM (which PHP 7.1 does: we elide type checks on certain arithmetic operations for operands of known types).
If you want to ensure type safety before the program actually runs, you can of course let your IDE or static analyser check that for you.
I think types specifications in interpreted (not compiled) languages should be only hints (for IDEs, code analyzers and JIT compilation etc.). This type checking for every method probably also adds some overhead does it not?
EDIT: correction
Unenforced type hints don't give these guarantees. They have no requirement to be accurate because the runtime won't enforce them, so they're essentially documentation, not code. They can't be safely relied upon by the optimiser because they're unenforced. The code inside the function body can break at runtime if given the wrong type, so if having a specific type is particularly important, you have to add manual type checks or coercions yourself.
Furthermore, doing ahead-of-time checking would require infrastructure we don't currently have for providing information to the PHP interpreter about whether or not PHP files have passed type checks. But again, most code is not fully typed, and so this doesn't provide all that many guarantees to the interpreter.
Having methods that just have the right names is a pretty weak assurance, isn't it?
Visibility and typing features are good. Visibility helps to design and write better code. The typing features are also welcomed in my view. I would rather a request completely fails because a variable is the wrong type rather than PHP's type coercion leading to an unexpected result with no errors or warnings.
That said, I use PHP for my day job. I see no reason to start new projects in it. I never use it in my side projects. Introduction of the single pipe operator to represent OR instead of a double pipe operator is baffling in my opinion.
7.1 does more work to improve consistency and error handling which is definitely welcomed. The problem is there is much legacy crap in PHP. It only exists for web applications and there are a growing number of languages which do this better.
I kind of understand it since it's not a traditional OR operation and intends to keep and associate the matching values, but maybe something like
catch (Exception $e in (Exceptions...))
would make it clearer. Either way, it's so close to feeling like an OR operation that I feel like it will be a lot of debugging when you forget this.
The good it does is it stops your application from possibly continuing on with buggy code.
This is especially important in something like billing code. Imagine if your code was expecting an integer (bill amount) but got a string instead that via the types system evaluated to 0 or 1 instead of the real integer... In that case you might charge customers less or more than you should have and its a big deal trying to get all that fixed.
Better to just throw an error which you can see in an exception handling system like Sentry and take care of the problem.
Because they are easy to implement (function type hints, typed properties) and the php community have a collective, insatiable, perpetual hardon for features that are supposed to enhance correctness..
So the core devs are eager to propose these kinds of features. And the community is eager to accepts them without much thought..
To see how child like this mentality towards these type of features, see this comment, where a Php expert makes a big deal regarding when a user omitted mentioning the type of a value....
https://www.reddit.com/r/PHP/comments/4k2htl/ive_just_given_...