Post · bonfire.cafe

I think I’d be in favor of this approach. It doesn’t “erase” the types, while it steers clear of the difficulty of implementing them at runtime.

#PHP https://phpc.social/@thephpf/114970839022787604

M1ke

@m1ke@phpc.social replied · 2 weeks ago

@ramsey I agree with the points @mnapoli makes about this on Reddit, it doesn't solve the main problems we need generics for, especially things like lists. Erased generics is preferable - ideally with clean syntax and accessible via reflection. If you're someone who cares about generics you're already using Psalm or Stan.

For me the best effort would be a systems language rewrite of a static analyser to make them faster

Gina Peter Banyard

@Girgias@phpc.social replied · 2 weeks ago

@m1ke @ramsey @mnapoli If the only thing to care about is "nice inline syntax" that many people seem to claim to want, then why isn't anyone using/writing a simple preprocessor that converts the inline syntax into doc comments and runs your favourite static analysis tool on top?

You get erased generics, and your static analysis execution similar to how TypeScript behaves.

If you want a SA tool in a compiled language, just have a look at Mago: https://github.com/carthage-software/mago

Ben Ramsey

@ramsey@phpc.social replied · 2 weeks ago

@m1ke @mnapoli Erased generics provide no benefit over using PHPStan or Psalm. If someone is using my library and not taking advantage of an IDE or toolchain that enforces the generics, then there is no type-safety guarantee.

Matthieu Napoli

@mnapoli@phpc.social replied · 2 weeks ago

@ramsey @m1ke it provides the advantage of not being in a phpdoc, that's all 🤷
My take is "PHPStan" is already the best thing, let's just not write types in phpdoc.
And I'm fine if some consumer of my libraries don't use static analysis, that's their choice. Just like it is today.

Ben Ramsey

@ramsey@phpc.social replied · 2 weeks ago

@mnapoli @m1ke To ensure consumers of my libraries who aren’t using static analysis tools (and there are still a LOT of folks in this camp) have a good experience with them, I have to implement extra checks in my code. I want to stop doing that.

Carlos 🔻

@cpereira@framapiaf.org replied · 2 weeks ago

@ramsey @mnapoli @m1ke
I would be in favor of a process of "internalising" some phpstan's checks into PHP "compile-only".
Devs should use phpstan. If we "internalise" some checks of phpstan, they will use it _de facto_.

Ben Ramsey

@ramsey@phpc.social replied · 2 weeks ago

@cpereira @mnapoli @m1ke Why do you think they will use PHPStan “de facto,” if we “internalize” some of the checks?

1 more replies (not shown)

bonfire.cafe

A space for Bonfire maintainers and contributors to communicate

bonfire.cafe: About · Code of conduct · Privacy · Users · Instances

Bonfire social · 1.0.0-rc.2.8 no JS en

Automatic federation enabled