If they're not enforced at runtime, then they're unsound if you have typed code calling untyped code. And as the maker of the sibling comment notes, runtime type checks still catch errors earlier than no type checks.

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.

> If they're not enforced at runtime, then they're unsound if you have typed code calling untyped code.

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

Yes, it adds overhead. But it means the type declaration can actually be relied upon: the code inside the function always gets the type it wants, the optimiser can elide type checks safely, and humans and computers reading the code don't have to worry about the type declaration being a lie.

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.

But these checks could also be performed by a code analyzer/compiler, removing this burden from the runtime. (Performing the checks at runtime, means the code is only checked when it is executed, which could be at any random time.)

Ahead-of-time type checking can only really work if the entire program has type declarations everywhere, and if you know what constitutes the entire program. This isn't the case for the vast majority of existing PHP code. Furthermore, PHP's dynamic features mean that there are cases where ahead-of-time checks will always be impossible. So you have to have at least some runtime checks, at the boundaries between typed and untyped code.

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.

I've seen quite a few JavaScript bugs and potential bugs exposed after adding incomplete type annotations in TypeScript, so I really don't think it's all or nothing, at least not as a general rule. I've been away from PHP too long to speculate how much it would help here.

Sure, it's not all-or-nothing, type checks that aren't enforced at runtime have some benefits, I just disagree that they can provide all of them.

If you're using type signatures, the alternative is probably going to be that your program crashes at a later time. "Foo is not a Bar" is a better error message than "$foo->xyz() isn't a function", and this happens much closer to the point where you've messed up.

I disagree. I think that this type of "late type binding" is actually an advantage of dynamically typed languages. That way it does not matter if you pass a map/array/dictionary or an instance of a class as long as the properties are the same.

I think one problem is when your object quacks like a duck, but the quack doesn't mean what you think it means.

Having methods that just have the right names is a pretty weak assurance, isn't it?

"Fail Fast" is a pretty popular best-practice and failing immediately on a mismatched type hint is in line with that.

The type hinting is optional, so if you want "late type binding" you can just omit the type hints.

Then... don't specify that you want a specific type?

PHPDoc is supported by most IDE's. Using this you can specify parameter types without using the actual type system.

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.

> Introduction of the single pipe operator to represent OR instead of a double pipe operator is baffling in my opinion.

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.

> What good does it do when your code suddenly throws a fatal error at runtime because you did not respect the type specification.

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.

>I wonder why PHP includes more and more type checks and visibility features

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_...