Check whether function has return typehint about phpstan-strict-rules HOT 11 CLOSED

cannot be added due to BC implications

1. No one is forced to use this rule.
2. You can avoid BC issues with adding just a phpDoc.

 In the end this is more suitable as simply Coding Standard rule

I can agree with that, but this is also closely related to static analysis - more typehints you have, the better the analysis can be.

from phpstan-strict-rules.

But when no typehint is defined I would expected that function "returns" void.

This assumption is wrong. Nothing means either mixed or void.

from phpstan-strict-rules.

@Majkl578 This request is about pointing out that a method should have complete typehints so it's a valid concern.

@CzechBoy Can you prepare a PR? I'd like to report missing parameter types as well. Thanks!

from phpstan-strict-rules.

@ondrejmirtes I will try and let you know at the weekend how it goes.

from phpstan-strict-rules.

Reporting missing types is fine, but the quoted assumption is incorrect.

Either way I think this rule is problematic. There are lots of occurences where type cannot be added due to BC implications (consider Doctrine for example, or just any project with BC constraints) or where mixed is intentional.
(In the end this is more suitable as simply Coding Standard rule, which is already in place in Slevomat CS.)

from phpstan-strict-rules.

more typehints you have, the better the analysis can be

Yes, but I don't see how it fits to this extension, which describes itself as:

This repository contains additional rules that revolve around strictly and strongly typed code with no loose casting for those who want additional safety in extremely defensive programming

I'd argue that enforcing typehints is not something SA tool should be doing, that is beyond static analysis. (I am happily using CS rule for that.)

No one is forced to use this rule.

This is really PITA since it's not possible to exclude rules - adding and maintaining set of all rules minus one in all consumers is slightly messy. :(

from phpstan-strict-rules.

I'd argue that adding omitted typehints leads to additional safety.

from phpstan-strict-rules.

Additional safety? Maybe. Additional safety in extremely defensive programming? Likely not.

Also not related in terms of no loose casting.

from phpstan-strict-rules.

The definition in the README can of course change if you think it's ambiguous.

from phpstan-strict-rules.

I was surprised too that this is not in any coding-standard that I know/use.

more typehints you have, the better the analysis can be.

This was exactly why I created this issues

from phpstan-strict-rules.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

from phpstan-strict-rules.