> On 23 Apr 2019, at 21:02, Benjamin Morel <benjamin.mo...@gmail.com> wrote: > > It's exactly the purpose of the proposal: avoid this boilerplate. For the > same reason you probably write: >
Replacing 1 line of “boiler plate” with a *different* line of less-obvious “boiler plate” is not an improvement IMO. > The current proposal is to fill the gap of type checking / type hinting > **inline**, when getting data from an losely typed source. Parameter type hints use syntax that is clear, concise and reasonably common in other languages. Similarly, defining the type of a variable when it’s declared is clear and concise reasonably common in other languages. In languages without type hinting (e.g. JavaScript) - the “boiler plate” you’re trying to remove is also common, e.g. using `typeof` in JavaScript. Assigning a variable to itself, because you want to check its type is the weirdest concept I’ve heard in a long time. You want to add more capability to enforce type checking - I get that, and I share that goal. But when we already have pretty common, intuitive syntax to do so in one situation, I don’t see why you wouldn’t adopt the same syntax elsewhere. The typed properties RFC adopted the same syntax as parameter hints, even though they have some different implementation details (e.g. you can redeclare a function parameter to another type, you can’t with a typed class property). I can see that there would be pros and cons to either approach for typed local variables - but IMO *that* is the discussion to have. The initial RFC doesn’t even need to cover every possible scenario - it could literally just cover plain variable declarations. A later one could cover adding type hints to for example, foreach. By using syntax that’s already in-use, *and* doesn’t conflict with other *potential* points of implementation, we can hopefully end up with more options for type support in the language. Cheers Stephen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
