Re: Previous discussions about generics syntax only?

2023-10-17 21:39 GMT+02:00, Rowan Tommins <rowan.collins@gmail.com>: > On 16/10/2023 15:08, Olle Härstedt wrote: >> Hello internals, >> >> Was there a previous discussion about the pros/cons of adding only the >> syntax needed for generics, but not the functionality? So static >> analyzers could use it, instead of docblocks. I looked at externals.io >> but couldn't find anything specific. > > > Hi Olle, > > Since I haven't seen it expressed quite this way in the previous > discussion, I'd like to highlight what I think is a major downside to > this approach, at least as commonly proposed: > > Using the same syntax for type information that is guaranteed to be true > (existing run-time checks) and type information that is "advisory only" > (new checks for optional static analysis) means users can no longer have > confidence in that type information. > > This is one of the interesting things about the compromise over scalar > types - if you see a declaration "function foo(int $bar) { ... }", you > *know* that $bar will be an int at the start of every invocation of that > function, regardless of which mode the calling code uses. I think adding > exceptions to that certainty would be a bad direction for the language. > > On the other hand, I can see a "third way": if the problem with current > static analysis conventions is that they have to be parsed out of a > string-based docblock, we can provide *dedicated* syntax, without > unifying it with the standard type syntax. For instance, some of the > earlier discussions around introducing attributes suggested reflection > expose the AST of the attributes arguments, rather than the resolved > expressions, allowing them to act a bit like Rust's "hygienic macros". > If that was added as an optional mode, you might be able to do something > like this: > > #[RawAttribute] > class GenericType { > public function __construct(AST\Node $typeInfo) { ... } > } > > function foo(#[GenericType(int|float)] array $foo) { > // array is the type guaranteed by the language > // static analysis libraries can get the GenericType attribute from > reflection and receive an AST representing the type constraint int|float > } Not sure readability is improved here compared to existing @template annotations. ;) Olle