Open devnix opened 9 months ago
I found these snippets:
@veewee do you think this can make it to 3.0?
I've had an offline discussion about this and there were some good arguments in favour and against this. Will add the main discussion points to this ticket later so that we can conclude here
These were the main reasons that were holding back on implementing it:
There is no way in psalm (nor phpstan) to throw a generic exception: https://psalm.dev/r/b3988674a5
/**
* @template T of \Throwable
* @param T $e
* @throws T
*/
function throwIt(\Throwable $e): never {
throw $e;
}
There is no way in psalm to set a default generic value
In a lot of situations, you are using something like Result\wrap()
or similar in which you don't know what type of exception will be thrown. This will therefor be defaulted to \Throwable
, making people have to add the type \Throwable everywhere where they use Result. It doesn't add any value for the user to add this type - just more work for no extra gain. This could be solved if we had generics with default types.
But there is no such thing like:
/**
* @template E of \Throwable = \Throwable
*/
That allows you to overwrite defaults.
Either
Most of the problems that the additional <E>
would solve, could be better dealt with when introducing an Eiter<L, R>
type as described in https://github.com/azjezz/psl/issues/355.
There the types would be required and there won't be a throw. So you could use one of them as the specific exception.
Conclusion
It is possible to add an additional <E>
param. But it wouldn't add a lot of value, if any at current moment.
@devnix Feel free to add to the list here - I might have forgotten a few details.
I found these snippets:
I've been chatting with @veewee on Discord about adding a template to
ResultInterface
to return what kind of error it could contain.I'm not sure if this could be considered a breaking change, as it only affects static analysis and can be easily ignored, baselined, or fixed in a moment by going to each error and changing every
@return ResultInterface<Foo>
to@return ResultInterface<Foo, Throwable>
if you don't feel like studying the specific throwables you want to return from there.Another option apart from waiting for a new major version or just letting static analysis break is to wait for some default generic type syntax, see:
This could allow us to have a syntax that would behave the same way but without having any new errors:
If we are OK with baselining errors (regardless of whether the change is in a minor or major version), the following syntax would infer the template with
Throwable
as the default value:Psalm would only throw a
MissingTemplateParalm
. At the same time, PHPStan would report two errors. Still, the return would be implicitly inferred fromResultInterface<int> to ResultInterface<Throwable>
in thenot_documented()
case on both major static analysis tools.Apart from this, there is another feature that would be nice to have in the static analysis, and that is to be able to infer the type of
@throws
with a generic, so we could type this:UndefinedDocblockClass
E
at@throws