New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Debug] throw deprecation when `@return void` is found #30123

Open
nicolas-grekas opened this Issue Feb 9, 2019 · 7 comments

Comments

Projects
None yet
3 participants
@nicolas-grekas
Copy link
Member

nicolas-grekas commented Feb 9, 2019

The DebugClassLoader does lightweight static analysis at autoload time already and triggers deprecations when some annotations in a docblock hint it to do so.

When this class finds a method that doesn't have void as return type but whose parent has the @return void annotation, we should trigger a deprecation - unless it also has the same annotation.
The should hint ppl to add the void return type immediately in their code and be ready for next-major of the parent class, which will be able to smoothly turn the annotation to a real void declaration.

ping @fancyweb @GuilhemN since you contributed similar rules in the past.

@theofidry

This comment has been minimized.

Copy link
Contributor

theofidry commented Feb 9, 2019

@nicolas-grekas wouldn't that be both tricky & incomplete since traditionally:

function foo();

implies:

function foo(): void;

Whereas if something was returned, we have:

/**
 * @return mixed
 */
function foo();

?

@nicolas-grekas

This comment has been minimized.

Copy link
Member Author

nicolas-grekas commented Feb 9, 2019

function foo(); implies: function foo(): void;

That's maybe conceptually correct - you can't rely on anything else - but that's technically inaccurate - you can return anything with such a signature.

That's why it works - we only care about technicalities here.

@theofidry

This comment has been minimized.

Copy link
Contributor

theofidry commented Feb 9, 2019

@nicolas-grekas

This comment has been minimized.

Copy link
Member Author

nicolas-grekas commented Feb 9, 2019

From the fabbot failure on #30124 we can even say there are none :) Which is nice actually as ppl can start using it and express backward-compatible semantics for void.

@fancyweb

This comment has been minimized.

Copy link
Contributor

fancyweb commented Feb 9, 2019

@nicolas-grekas Why should we do it only for the void return type ?

@nicolas-grekas

This comment has been minimized.

Copy link
Member Author

nicolas-grekas commented Feb 9, 2019

Good question :)
We can do it for other return types IF they can be expressed as real return type indeed.

@fancyweb

This comment has been minimized.

Copy link
Contributor

fancyweb commented Feb 9, 2019

I'm going to work on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment