When we can expect laravel/framework package to have return types build in?

[mikield]

It's 2024, and PHP 8.4 has been released.

Strong typed codebases have been proven stability over non strong typed code.

I am asking myself, when we can see such big tool as Laravel that's used by billions of web apps to be strong typed?!

Do Laravel team has some plans on it?
If yes - I would like to contribute :)

[ghost]

Never:)

[mikield]

Do only me feels like we need here an RuntimeException?
Like, if you expect your code not to run - throw new Exception that will allow user to catch it and write "catch" case code.

[mikield]

@marius-mcp I am coding only laravel for like 6+ years now, so I can not say that I do not like it, I want the best for the tool that I like :)

But I understand your point, Laravel is kinda Apple from PHP dev for some people :)

[ghost]

@mikield good thing is that the packages for laravel can be written ~ 90% with return types and typed params. Also the projects that we build using laravel/lumen.

[puklipo]

There is precedent for very painful breaking changes destroying communities.
The only solution is to introduce types little by little with each major version upgrade.
Newer packages that don't need to worry about breaking changes are well-typed.

[ghost]

@puklipo that is why I said never. At first I thought it is possible, but after more than 3 years working with it, I understood it is not possible because of the backward compatibility issues..

[macropay-solutions]

The reason it Returns Eloquent builder instead of int: #56664

[macropay-solutions]

@mikield we started applying PSR12 but we did not touch the return types or the parameters types.

[macropay-solutions]

@mikield We saw some attempts on putting return types that generated bugs and were either patched or reverted in version 12. So the community is trying to improve the framework but the legacy is a big stopper for that.

[macropay-solutions]

But that did not stop us from using PSR12 in our projects. Also when extending Laravel classes we could put the return type even if the parent did not had one.
Of course putting mixed does not help much but anyway...

[macropay-solutions]

The other half of the problem are the typed parameters on functions definition.

[shaedrich]

We might just have to tie these changes closer to /types

[macropay-solutions]

@shaedrich what are those? tests that test the return type? What can they bring as a plus value to the framework if I have an app that returns different type vs the framework?

[shaedrich]

I haven't worked with them yet so I don't know, but this can at least cover a good chunk.

[Sophist-UK]

As is very common in the real world (rather than theory) there is a balance to be had here. In general terms, introducing strict types are going to create (at least potentially) breaking changes - and there are three separate situations to consider:

• Strict parameter types
• Strict return types
• declare(strict_types=1);

So you might introduce these at separate times and in separate ways.

Breaking changes are painful - but sometimes the pain is justified in order to provide a future path. Compare PHP4 with PHP8 - and think about how many breaking changes were successfully introduced to get from one to the other - and they were done because they were necessary for the long-term success of PHP. Breaking changes necessary for the long-term success of Laravel are equally justified IMO, but of course which changes are "necessary" is going to be subjective.

There are many many ways to mitigate / reduce the pain:

• You can deprecate a major version ahead and provide warnings (in non-production environments)
• You can use tools like Rector to automate refactoring for some changes in order to reduce the effort to migrate to a new major version. If Laravel were to provide Rector rulesets that might go a long long way to making such changes palatable.

So, for example, in Laravel 13 you could introduce static-analysis and/or or run-time and/or automated test code to test parameter types and warn users when their code will create a breaking change in L14, and you could provide a Rector ruleset and an artisan command to refactor such code.

And of course, some parts of Laravel are used in a greater number of different ways than others, so introducing strict typing in lower levels and functions which are normally internal only will create less pain than for areas which are used widely and in many different ways.

And finally, new calls are introduced in many releases, and although these are a very small proportion of the overall code base, they could (and perhaps should) be introduced with strict typing wherever possible.