RFC Proposal - Types for Inline Variables

php.internals

Wendell Adriel

3 years ago
Hello everyone. My name is Wendell Adriel, I work with PHP since 2009 and these last couple of days I was thinking that we have made HUGE progress with types on PHP so far. We can add types in a lot of places, but we still don't have a way to add types to inline variables. The Idea I was talking about this on Twitter with some developers and I wanted to check how's the feeling on this. I know that there's a draft RFC that mentions this in the Future Scope section: https://wiki.php.net/rfc/declare_vars But my idea is not to have the declaration of variables like that. I'm thinking on a straightforward implementation that would be like: Today we have: $value = 10; $value = 'foo'; // OK My proposal is to be able to do something like: int $value = 10; $value = 'foo'; // TypeError This typing would be optional and under the hood all current declarations would implicitly add the mixed type to the variable. So this: $value = 10; Would be interpreted as: mixed $value = 10; ----- Implementation I'm new to the PHP source code, but I'm looking into it and studying so I can be able to work on the implementation and not only in creating/proposing the RFC. If someone that has more experience wants to help me it would be great. ----- I'm happy to help with anything needed for this to happen and if someone wants to discuss further just ping me. Thanks in advance for the attention. --- Best Regards, Wendell Adriel. Software Engineer | Investor | Amateur Photographer | Musician | INFP​ https://wendelladriel.com

Илья Сомов

3 years ago
Hi there, I am not a core PHP language developer, just a regular PHP programmer, and cannot speak for the whole community, so I'll just share my opinion. I believe a new language feature suggestion should contain not only its description, but also motivation: i.e. what are we trying to achieve with it. Will the development experience be worse without it, or maybe it disallows some sneaky bugs to appear in your code, or maybe it acts as a native documentation for your code etc. Personally it's hard for me to see what kind of improvement will restricting a type of a variable bring. It may prevent repurposing the variable with the same name for a different use somewhere down the function, which can lead to bugs if a function is large enough. However, for such cases I think better idea would be to introduce `const` variables like in JavaScript - which can only be set once and cannot be reassigned later. This way you'll also guarantee the type of the variable will be preserved.
> We can add types in a lot of places, but we still don't have a way to add
types to inline variables.
> int $value = 10; > $value = 'foo'; // TypeError
Can you describe some use cases where this feature will be useful? I see it's coming from statically typed / compiled languages like C++, but in such languages compiler must know variable type in order to manage memory properly. As PHP is an interpreted language, it doesn't have this problem. Regards, Illia / someniatko

Hans Henrik Bergan

3 years ago
function f(int $value){ $value="foo"; // should this be a TypeError? BC break all the things } On Mon, 6 Feb 2023 at 22:15, someniatko <someniatko@gmail.com> wrote:

Wendell Adriel

3 years ago
Hey, thanks for the feedback Illia and Hans. Illia, I think that the main motivation for having the support of typing inline variables is that with that we can have more safety in the code. The code can be more shielded from bugs and easier to maintain. I don't dislike the idea of having something like const on JS, but I think that adding the support to add types to inline variables at least IMO is a step further on all the typing that was already added in the language. We have today the ability to add types to function arguments, return and in class properties. So this is just another step towards adding support to optional typing on another place. Types can bring more confidence when writing code, you can see that for example a lot of people in the JS community is now using TypeScript because of the types. I love that PHP already added type support to a lot of places and adding the support for typing inline variables would be a game changer for the language I think. Hans, you sent a good example. I think that in this case, it should throw a TypeError, yes. I know this would add a lot of breaking changes. But if we want to avoid some breaking changes we for example make use of the declare(strict_types=1) to enforce this if this would means in less breaking changes. --- Best Regards, Wendell Adriel. Software Engineer | Investor | Amateur Photographer | Musician | INFP​ https://wendelladriel.com ---- On Tue, 07 Feb 2023 08:34:07 +0000 Hans Henrik Bergan <divinity76@gmail.com> wrote --- function f(int $value){ $value="foo"; // should this be a TypeError? BC break all the things } On Mon, 6 Feb 2023 at 22:15, someniatko <mailto:someniatko@gmail.com> wrote:
> > Hi there, > > I am not a core PHP language developer, just a regular PHP programmer, and > cannot speak for the whole community, so I'll just share my opinion. > > I believe a new language feature suggestion should contain not only its > description, but also motivation: i.e. what are we trying to achieve with > it. Will the development experience be worse without it, or maybe it > disallows some sneaky bugs to appear in your code, or maybe it acts as a > native documentation for your code etc. > > Personally it's hard for me to see what kind of improvement will > restricting a type of a variable bring. It may prevent repurposing the > variable with the same name for a different use somewhere down the > function, which can lead to bugs if a function is large enough. However, > for such cases I think better idea would be to introduce `const` variables > like in JavaScript - which can only be set once and cannot be reassigned > later. This way you'll also guarantee the type of the variable will be > preserved. > > > We can add types in a lot of places, but we still don't have a way to add > types to inline variables. > > > int $value = 10; > > $value = 'foo'; // TypeError > > Can you describe some use cases where this feature will be useful? I see > it's coming from statically typed / compiled languages like C++, but in > such languages compiler must know variable type in order to manage memory > properly. As PHP is an interpreted language, it doesn't have this problem. > > Regards, > Illia / someniatko
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Rowan Collins

3 years ago
On 06/02/2023 21:15, someniatko wrote:
> Can you describe some use cases where this feature will be useful? I see > it's coming from statically typed / compiled languages like C++, but in > such languages compiler must know variable type in order to manage memory > properly. As PHP is an interpreted language, it doesn't have this problem.
I'm not convinced the distinction between "compiled" and "interpreted" languages is actually meaningful for modern language implementations - PHP does have a compilation step, and even performs some of its correctness checks at that stage. Much more important is the distinction between "static typing" and "dynamic typing". The aim of a static typing system is to *prove*, in the mathematical sense, that the program is correct according to the type system of the language, without executing any of the code. The aim of a "dynamic typing" system is instead to *detect* problems in a program, while it is running, and to select operations overloaded based on the actual type of data. PHP itself currently only includes dynamic typing features - effectively, all the type keywords you add to the source code translate to run-time assertions that check the type of data at specific points. Mostly, that's currently at function boundaries (parameter and return type checking), though typed properties are more complex (especially when you access one by reference, and get a "typed reference"). One of the big implications of that is performance: adding checks in more places (e.g. on every assignment to a local variable), or more complex checks (e.g. checking every element of an array), means that the actual program runs slower. It may be possible to implement checks in a more efficient way, but it's not going to be a simple patch. That's why including an official static analyser is tempting, but it's not obvious where that would fit in the project and ecosystem (see the recent thread on that topic). Regards,
-- Rowan Tommins [IMSoP]