Typed array properties V2

Sebastian Bergmann

6 years ago

Am 17.01.2020 um 08:50 schrieb Aran Reeks:

> @returns []int

int[] etc. is common-place, but I have never seen []int.

Brent

6 years ago

Hello all

It's a much-requested feature for years and years. My first thought was "we need generics, not this" but than I took 5 minutes to actually think about it. While the same, and much more, can be achieved with generics, it's a difficult feature to implement. There have been several RFCs for generics in the past, which failed. I know Levi Morisson was, at one point, looking at adding support for generics only in traits, because it's difficult to add them in other places.

While I still think generics would be a great feature, I now also believe it's worth looking at an "array of" type as something standalone. I've got no clue about the technical implications, but maybe suprting "array of" syntax is a lot more easy than full blown generics? Looking at my day to day work with PHP, I'dsay "array of" types would solve ~80% of my problems with PHP's current type system, and I figure there are lots of developers in a similar situation. If I remember correct from my college days, Java also supports both styles: Int[] and ArrayList<Int>.

All that to say that maybe it's worth the effort looking at "array of" types as something different than generics?

Kind regards
Brent

Máté Kocsis

6 years ago

Hi,

So essentially we are talking about generics. I think it's the best time to
do so... Maybe our wishes come true soon? ;)

Cheers,
Máté

Robert Hickman

6 years ago

> So essentially we are talking about generics. I think it's the best time to
> do so... Maybe our wishes come true soon? ;)
>

Given that the general trend is towards making PHP more statically
typed and very java/C# like, why not just ditch PHP and use one of the
aforementioned languages?

Olumide Samson

6 years ago

On Fri, Jan 17, 2020, 2:54 PM Robert Hickman <robehickman@gmail.com> wrote:

> > So essentially we are talking about generics. I think it's the best time
> to
> > do so... Maybe our wishes come true soon? ;)
> >
>
> Given that the general trend is towards making PHP more statically
> typed and very java/C# like, why not just ditch PHP and use one of the
> aforementioned languages?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

Who's this?

How does this feature means PHP becoming more static type language?

Does adding strict typing features remove any dynamic type features of the
language?
Nope, this still dynamic typing coz it can do both as the need demands.

Larry Garfield

6 years ago

On Fri, Jan 17, 2020, at 7:53 AM, Robert Hickman wrote:

> > So essentially we are talking about generics. I think it's the best time to
> > do so... Maybe our wishes come true soon? ;)
> >
>
> Given that the general trend is towards making PHP more statically
> typed and very java/C# like, why not just ditch PHP and use one of the
> aforementioned languages?

Because those languages suck for scripted use.  For shared-nothing scripting, PHP beats the pants off of them.

That doesn't mean we can't continue PHP's fine tradition of stealing good ideas liberally from every language we can find.  We can and should do so.  (Whether we adopt Generics in the Java.C#/C++ style or pull from some other language is a separate debate.)

cf: https://24daysindecember.net/2019/12/06/growing-gradually-in-php/

--Larry Garfield

Mike Schinkel

6 years ago

> On Jan 17, 2020, at 2:50 AM, Aran Reeks <cdtreeks@gmail.com> wrote:
> That said, there's a common use case that keeps me going back to them which
> I think would be a good thing for PHP to try and solve as a language
> feature - better typing of arrays to type their properties.

I for one would be a big +1 for this, with caveats.

> IDEs like PHPStorm handle this structure already hence sticking to that as
> a starting point...
>
> @returns []int

As previously noted, I assume you meant int[]?

----

Having the ability to type array elements would cover ~90% of the cases where I cannot properly type parameters or return values in PHP 7.4.

The caveat is that it would seem that to check dynamically would be an expensive proposition such as when an array that was not typed is passed to or returned from a function or assigned to a variable of a declared type, e.g.

function foo( $myarray ): Foo[] {
return $myarray;  // This would need to be dynamically checked, I think?
}

Of course we could limit this type of typing to only arrays that are already know to be typed, meaning this would always fail:

function bar( Foo[] $myarray ) {
// Do whatever
}
function baz( $myarray ) {
bar( $myarray );  // Fails here because $myarray not known to be Foo[] even when it is
}
baz( [ new Foo() ] );

Alternately we could have a global option that would do type checking or not for these type hints, so they could be dynamically checked for all code prior to production code, where checking could be turned off.

Another option could be if the number of array elements is small (<100?) it could check, but otherwise not check, but this feels all kind of different types of wrong.

----

My vote, if I had one, would be to add type new typing for array elements, but also add a type checking global option that can be in one of 3 states:

1. Static checks only,
2. Dynamic checks only, or
3. No checking of array elements.

#jmtcw

-Mike
P.S. Or maybe there is an inexpensive way to keep track of the types of the entire array on element assignment?
P.P.S. Can someone please explain and give an example of how generics would make this need moot?  I do not get why that would be the case...

Aran Reeks

6 years ago

Hi Mike,

Thanks for your support, and yes, you're correct, I did mean to structure
the type prior to the [].

I'm unsure of exactly how this might work so defer to an Internals export,
but having previously read @Nikita Popov <nikita.ppv@gmail.com>'s great
post on PHP's arrays, I did wonder if by knowing the data type within an
array and that it'd conform to a strict structure, could the array itself
be stored in an alternative way in C? Perhaps a more memory efficient way,
or one that's faster to iterate over rather than just a hash table?

Link to this article for reference:
https://nikic.github.io/2012/03/28/Understanding-PHPs-internal-array-implementation.html

Cheers,
Aran

On Fri, 17 Jan 2020 at 19:17, Mike Schinkel <mike@newclarity.net> wrote:

tyson andre

6 years ago

tyson andre

6 years ago

Nikita Popov

6 years ago

On Fri, Jan 17, 2020 at 8:51 AM Aran Reeks <cdtreeks@gmail.com> wrote:

> Hi Internals,
>
> I'd like to kick off a conversation to capture everyone else's thoughts on
> tweaking / improving typed properties for arrays (for a PHP 8.x release).
>
> With all the work done lately to greatly improve the type support in PHP
> (which is amazing by the way), I'm finding for the most part, I'm no longer
> needing to Docblock as much of my code which is lovely.
>
> That said, there's a common use case that keeps me going back to them which
> I think would be a good thing for PHP to try and solve as a language
> feature - better typing of arrays to type their properties.
>
> IDEs like PHPStorm handle this structure already hence sticking to that as
> a starting point...
>
> @returns []int
>
> This would designate the return of an array where all its keys are that of
> the int type, but it works for any type.
>
> With that in mind, it might also make sense to allow a shorthand array
> alias for array types anyway - array -> [].
>
> To use actual PHP examples, this would mean the following would be
> supported:
>
> // Typed array properties ...values would follow any existing PHO type
> function returnsIntArray(): []int;
> function returnsClassArray(): []Class;
>
> // The same outcome
> function returnsArray(): array;
> function returnsArray(): [];
>
> I welcome all your thoughts on this proposal.
>
> Many thanks,
> Aran
>

Hi Aran,

Did you read through the previous discussions on this topic?
https://externals.io/message/100946 in particular comes to mind.

The primary concern about the previous typed array proposal was the O(n)
cost of type checks, which required iterating over the whole array and
checking the type of individual elements. Any new proposal in this area
*must* address this concern.

As far as I know, the only viable way to do that is to make the array
intrinsically typed, which means that types are validated when elements are
inserted into the array, not when it is passed across a function boundary.
In other words, array generics.

Regards,
Nikita

Mike Schinkel

6 years ago

Hi Nikita,

> On Jan 18, 2020, at 5:05 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> Did you read through the previous discussions on this topic?
> https://externals.io/message/100946 in particular comes to mind.

Thanks for this link. It was very insightful.

> The primary concern about the previous typed array proposal was the O(n)
> cost of type checks, which required iterating over the whole array and
> checking the type of individual elements. Any new proposal in this area
> *must* address this concern.

Agreed.

> As far as I know, the only viable way to do that is to make the array
> intrinsically typed, which means that types are validated when elements are
> inserted into the array, not when it is passed across a function boundary.
> In other words, array generics.

Reading the prior discussion, there appeared to be several other potential approaches, but none were followed to a conclusion.  Of course it devolved into bikeshedding, but I digress...

One approach mentioned by Andrea Faulds was to extend the hashtable (ref: your article[1]) and count types as assigned just like we currently count references.  So a 10,240 element array of ints could have an internal tracker showing that the array contains type(s): ['int' => 10240].   Append a string value to the array and then the types would be ['int' => 10240, 'string' => 1].

Mark Randall mentioned that this would not work if the array contained references, but no one discussed the potential of simply disallowing arrays with references at compile time when the arrays are typehinted, which seems like it could solve the proverbial 80/20 scenario.  Need references in arrays?  Don't typehint them.

Also, Rowan Collins mentioned that checks in Go can be disabled for runtime checking; maybe we could support an option that disables said checking so that production sites could run w/o checks but we could run checks in development, testing and staging. We could also have an option to disable checking of array types above a given size of array, maybe defaulting to 1024? Clearly both of these would be no worse than what we have today.

I think this could add a major improvement to PHP all without having to finalize the design and implementation of generics, no?

Are none of these viable options?  I am asking that as a legitimate question — as I am not (yet) a PHP internals developer — and not just assuming they are viable options.

-Mike

[1] https://nikic.github.io/2012/03/28/Understanding-PHPs-internal-array-implementation.html

P.S.  There was also the mention by Levi Morrison that the type[] syntax was a poor one because of ambiguity between (?int)[] or ?(int[]).  I would argue that the latter would likely occur orders of magnitude more often than the former, so I would argue that ?int[] should interpret as ?(int[]), and if they want (?int)[] then the developer should use parentheses.

John Bafford

6 years ago

> On Jan 19, 2020, at 19:53, Mike Schinkel <mike@newclarity.net> wrote:
>
> P.S.  There was also the mention by Levi Morrison that the type[] syntax was a poor one because of ambiguity between (?int)[] or ?(int[]).  I would argue that the latter would likely occur orders of magnitude more often than the former, so I would argue that ?int[] should interpret as ?(int[]), and if they want (?int)[] then the developer should use parentheses.

As a thought, perhaps the syntax '[Type]' for an array of Type. That way, you could write ?[int], or [?int], or even ?[?int] and there would be no ambiguity, and no need for parentheses since the array brackets would serve that purpose.

If we also wanted to allow typing array keys, this syntax could be extended to [string : Type] and [int: Type], and it would continue to remain unambiguous, even with nested arrays, and with using a more similar syntax than the docblock syntax array<string, Type>. (It might also be reasonable to support both variants as aliases of each other.)

Both of these are the syntax Swift uses for arrays and dictionaries, so the syntax has precedence from another language. Swift also supports both syntaxes as described above ([KeyType : ValueType] is exactly the same as Dictionary<KeyType, ValueType>), but the shorter bracket syntax is preferred for readability.

-John

Mike Schinkel

6 years ago

> On Jan 19, 2020, at 8:42 PM, John Bafford <jbafford@zort.net> wrote:
> As a thought, perhaps the syntax '[Type]' for an array of Type. That way, you could write ?[int], or [?int], or even ?[?int] and there would be no ambiguity, and no need for parentheses since the array brackets would serve that purpose.

That syntax was what someone suggested on the prior discussion. I personally dislike it because I have used PHPDoc syntax of `type[]` for so long and would rather see us stick with that.

But if I'm honest about it, debate over syntax is probably just bikeshedding at this point.

The more important question IMO is, can we actually implement typed arrays to enough voter's satisfaction and w/o a significant performance penalty?

-Mike

Rowan Collins

6 years ago

On 20/01/2020 00:53, Mike Schinkel wrote:

> One approach mentioned by Andrea Faulds was to extend the hashtable (ref: your article[1]) and count types as assigned just like we currently count references.  So a 10,240 element array of ints could have an internal tracker showing that the array contains type(s): ['int' => 10240].   Append a string value to the array and then the types would be ['int' => 10240, 'string' => 1].

This would work really well for simple types like 'int' and 'string',
but loses its advantage fast with things like interfaces and
pseudo-types. For instance, if you have an array with objects of 20
different classes, and need to check it against a constraint of
SomeInterface[], you still have to test all 20 classes to see if they
implement that interface.

The overhead is also rather high, because you have to allocate memory
for this list on every array, and keep it up to date on every write,
even if it's never used.

I've had a similar idea in the past, but rather than trying to list the
types in advance, just cache them after passing (or failing) a type
check, so more like [ 'SomeInterface[]' => true, 'SomeOtherInterface[]'
=> false ]. Even if you just wiped the cache completely on every write,
I think that would give a decent boost, because there will often be
cases where a value is passed through a series of related functions all
expecting the same type.

The worst case pseudotype is probably "callable[]", because it's
actually context-dependent (e.g. [$object, 'privateMethod] is only
"callable" inside the same class as $object) so can't be pre-calculated
or cached. That would be problematic even with full generics -
logically, List<callable> would check each member was callable when it
was added to the list, but it might turn out not to be callable when it
was accessed later.

Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

Mike Schinkel

6 years ago

>
> On Jan 21, 2020 at 5:37 PM,  <Rowan Tommins (mailto:rowan.collins@gmail.com)>  wrote:
>
>
>
>  On 20/01/2020 00:53, Mike Schinkel wrote:
> >  One approach mentioned by Andrea Faulds was to extend the hashtable (ref: your article[1]) and count types as assigned just like we currently count references. So a 10,240 element array of ints could have an internal tracker showing that the array contains type(s): ['int' =>  10240]. Append a string value to the array and then the types would be ['int' =>  10240, 'string' =>  1].
>
>
> This would work really well for simple types like 'int' and 'string',
> but loses its advantage fast with things like interfaces and
> pseudo-types. For instance, if you have an array with objects of 20
> different classes, and need to check it against a constraint of
> SomeInterface[], you still have to test all 20 classes to see if they
> implement that interface.
>
> The overhead is also rather high, because you have to allocate memory
> for this list on every array, and keep it up to date on every write,
> even if it's never used.
>
> I've had a similar idea in the past, but rather than trying to list the
> types in advance, just cache them after passing (or failing) a type
> check, so more like [ 'SomeInterface[]' =>  true, 'SomeOtherInterface[]'
> =>  false ]. Even if you just wiped the cache completely on every write,
> I think that would give a decent boost, because there will often be
> cases where a value is passed through a series of related functions all
> expecting the same type.
>
> The worst case pseudotype is probably "callable[]", because it's
> actually context-dependent (e.g. [$object, 'privateMethod] is only
> "callable" inside the same class as $object) so can't be pre-calculated
> or cached. That would be problematic even with full generics -
> logically, List<callable>  would check each member was callable when it
> was added to the list, but it might turn out not to be callable when it
> was accessed later.
>
>
>
>
>
>
>
>

>

Those are all really good points.

Unfortunately. :-(

-Mike

Rasmus Lerdorf

6 years ago

On Sun, Jan 19, 2020 at 4:53 PM Mike Schinkel <mike@newclarity.net> wrote:

> Also, Rowan Collins mentioned that checks in Go can be disabled for
> runtime checking; maybe we could support an option that disables said
> checking so that production sites could run w/o checks but we could run
> checks in development, testing and staging. We could also have an option to
> disable checking of array types above a given size of array, maybe
> defaulting to 1024? Clearly both of these would be no worse than what we
> have today.
>

You are getting into static analysis territory here with that. There are
already static analysis tools that do exactly this type of array type
checking during development. For example, there are three type mistakes in
this code:

1 <?php
2 class C {
3   /**
4    * @param int[] $ints
5    * @param string[] $strings
6    * @return array<int,string>
7    */
8   static function f(array $ints, array $strings):array {
9       return array_combine($strings, $ints);
10   }
11 }
12 print_r(C::f([3,2,'1'], ['abc', 'def', 42]));

Running Phan on it produces:

array.php:9 PhanTypeMismatchReturn Returning type array<string,int> but f()
is declared to return array<int,string>
array.php:12 PhanTypeMismatchArgument Argument 1 ($ints) is
array{0:3,1:2,2:'1'} but \C::f() takes int[] defined at array.php:8
array.php:12 PhanTypeMismatchArgument Argument 2 ($strings) is
array{0:'abc',1:'def',2:42} but \C::f() takes string[] defined at
array.php:8

The code itself would run in production without errors, of course, and
would produce:

Array
(
[abc] => 3
[def] => 2
[42] => 1
)

But at Etsy, at least, this code would never make it to production because
static analysis checks are run by all developers and also run automatically
during staging prior to a production push.

Really expensive checks like this belong at the static analysis stage. And
yes, it would be amazing to have a static analyzer built into PHP, which is
basically what you are asking for here, but that is a huge task and goes
way beyond just this particular check.

-Rasmus

Mike Schinkel

6 years ago

> On Jan 23, 2020, at 3:04 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> You are getting into static analysis territory here with that. There are already static analysis tools that do exactly this type of array type checking during development. For example, there are three type mistakes in this code:
> <snip>
> Running Phan on it produces:

Understood.  But in my experience a large number of PHP developers do not use Phan.  At least not in the WordPress realm.

For my current project we tried for two days to get Phan to work but it generated so many errors that were not actually errors we gave up.  I am sure it were possible if we had had the time and expertise to configure it correctly we could have gotten it working, but I would not be surprised if we are unique in that respect.

IOW, if a tool is very complex to get working, its existence is not a solution except for advanced teams and use-cases where the benefits are so overwhelming that teams managers are willing to fund the time it takes to implement.

> Really expensive checks like this belong at the static analysis stage. And yes, it would be amazing to have a static analyzer built into PHP, which is basically what you are asking for here,

Expensive checks would not be a problem if they could be run once during OpCode generation without affecting day-to-day code generation, right?

> But at Etsy, at least, this code would never make it to production because static analysis checks are run by all developers and also run automatically during staging prior to a production push.

To be fair, I would say Etsy is an extreme outlier.

Few business across the economy are fully web-based, have the revenue of Etsy and thus the financial downside Esty experiences when there is a problem on their website. Etsy is exactly the type of use-case I was referring to where the benefits of using tools like Phan are so overwhelming that management understands the need.

But many other companies won't see such an overwhelming benefit and thus managers often just don't appreciate the need to work on it.

#justsaying

> but that is a huge task and goes way beyond just this particular check.

Understood.

But my above comments are to point out that the existence of Phan is not a panacea.

-Mike

Rowan Collins

6 years ago

On 24/01/2020 19:22, Mike Schinkel wrote:

>> Really expensive checks like this belong at the static analysis stage. And yes, it would be amazing to have a static analyzer built into PHP, which is basically what you are asking for here,
> Expensive checks would not be a problem if they could be run once during OpCode generation without affecting day-to-day code generation, right?

I think you're both saying the same thing here. During OpCode
generation, no run-time information of a particular code path is
available, only what can be logically deduced from the source code
itself - and that's exactly what static analysis means.

I imagine the reason static analysers are generally run as a separate
step rather than just before execution is because then you _really_
don't care about performance, and it's more convenient to get the
results on demand, rather than them appearing in your server logs.

Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

Mike Schinkel

6 years ago

> On Jan 24, 2020, at 3:47 PM, Rowan Tommins <rowan.collins@gmail.com> wrote:
>
> I imagine the reason static analysers are generally run as a separate step rather than just before execution is because then you _really_ don't care about performance, and it's more convenient to get the results on demand, rather than them appearing in your server logs.

Let me try to make this rhetorical point in a different way.

One of the main strengths of PHP — and IMO one of the reasons for its incredibly marketshare — is the ease with which PHP code can be written, tested, and deployed. And that ease translated to ubiquity.

Adding a recommended build step to that in order to gain correctness weakens that value proposition and threatens future ubiquity as other language improve.

Said another way, if someone is evaluating which language to use — if they have to have a build step anyway — they might just avoid PHP and choose a truly compiled language that by nature is significantly more performant.

Or they might look for a language that is designed to provide static analysis without requiring a build step. Not sure if such as language exists, but if not there is certainly a compelling opportunity to create one. Or this is an opportunity that PHP could seize for itself.

So saying "use a static analyzer" is IMO just pointing out an overall weakness that PHP can't automatically do static analysis on its own.

-Mike

P.S. I am not calling for any new feature in this message, just wanting to call attention to the fact that PHP does not operate in a vacuum and that those who care about PHP's future should remember to consider that when discussing improvements other languages might have or might be adding.

Rowan Collins

6 years ago

On 25/01/2020 00:12, Mike Schinkel wrote:

> So saying "use a static analyzer" is IMO just pointing out an overall
> weakness that PHP can't automatically do static analysis on its own.

I'd just like to repeat that you and Rasmus are in agreement here. He
didn't say "PHP doesn't need to change because static analyzers exist",
he said:

> it would be amazing to have a static analyzer built into PHP
> ... but that is a huge task and goes way beyond just this particular

check.

Choosing whether that analysis runs automatically during server startup,
or as a separate command-line script, is just one detail among many. It
probably wouldn't make much difference to the rest of the analysis code,
and it might even make sense for it to support both modes. For instance,
it might be optional for command-line scripts, so you could have options
for "analyse and run", "run only", and "analyse only".

> One of the main strengths of PHP — and IMO one of the reasons for its

incredibly marketshare — is the ease with which PHP code can be written,
tested, and deployed.

> And that ease translated to ubiquity.
> Adding a recommended build step to that in order to gain correctness

weakens that value proposition and threatens future ubiquity as other
language improve.

Yes, the convenience of having something run automatically is definitely
worth considering, as long as it doesn't introduce new delays and rules
that get in people's way.

It partly depends what kind of checks were being done, I guess, and
therefore how much time it would take to run, and how much of a project
it would need to analyse at once.

Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

Midori Kocak

6 years ago

Given this orientation, can we also have this debated once more?

https://wiki.php.net/rfc/callable-types

Right now, I am using 7.4.2 in production and in my next book and I cannot
explain how it feels good to have those types but along with the loosely
typed freedom. That's the killer advantage of PHP and IMHO version 8 will
be quite popular due to the 7.4;

On Sat, 25 Jan 2020 at 16:12, Rowan Tommins <rowan.collins@gmail.com> wrote:

Matthew Brown

6 years ago

> As far as I know, the only viable way to do that is to make the array
> intrinsically typed, which means that types are validated when elements are
> inserted into the array, not when it is passed across a function boundary.
> In other words, array generics.
>

What if we left the array type alone, and instead focussed on "list<Foo>"
type and "dict<string, Foo>", "dict<int, Bar>" types?

That would allow a clear break from previous behaviour, and would allow you
to introduce other changes (e.g. removing string -> int coercion for
numeric string keys).

Benjamin Morel

6 years ago

>
> What if we left the array type alone, and instead focussed on "list<Foo>"
> type and "dict<string, Foo>", "dict<int, Bar>" types?

> That would allow a clear break from previous behaviour, and would allow you
> to introduce other changes (e.g. removing string -> int coercion for
> numeric string keys).

Can't agree more.

— Benjamin

Sebastian Bergmann

6 years ago

Am 21.01.2020 um 22:21 schrieb Matthew Brown:

> What if we left the array type alone, and instead focussed on "list<Foo>"
> type and "dict<string, Foo>", "dict<int, Bar>" types?
>
> That would allow a clear break from previous behaviour, and would allow you
> to introduce other changes (e.g. removing string -> int coercion for
> numeric string keys).

Just to make sure I understand you correctly: are you proposing new data
structures, names list and dict, in addition to array that can bring more
specific / strict semantics?

Matthew Brown

6 years ago

Yes!

Though I don't necessarily think they need to be genericised (e.g.
list<int>) in the language itself – just having those alternate
datatypes would, I think, be a boon to the language itself – with list (a
subtype of array) more useful to me than dict.


On Sat, 18 Apr 2020 at 10:51, Sebastian Bergmann <sebastian@php.net> wrote:

Mike Schinkel

6 years ago

Thus far we have discussed that implementation of type checking for arrays would be too costly from a performance perspective and that there is no good solution that is not extremely complicated to implement.

Given that, can we consider an alternative?

ALLOW the use of a syntax for typed arrays — whether it be type[] or [type] — but only validate that it is an array and that the "type" is in fact a type, but don't actually validate that each element is the correct type.

This would allow those of us who want to start documenting specific usage using type hints to be able to do so instead of what we currently have to do is PHPDoc one way and type hint with "array."  It would also allow IDEs like PhpStorm to add support.

Is this something the PHP community would consider?

-Mike

Rowan Collins

6 years ago

On 24/01/2020 19:27, Mike Schinkel wrote:

> ALLOW the use of a syntax for typed arrays — whether it be type[] or [type] — but only validate that it is an array and that the "type" is in fact a type, but don't actually validate that each element is the correct type.

I don't really see much point in that. Tools are happily reading this
information from docblocks already, so all I can see this achieving is:

1) Misleading users into thinking the language will guarantee something
when it won't.
2) Making it harder to use that syntax for a different purpose later,
because code will be out there which lists such constraints but violates
them, and will suddenly fail if the checks are enforced.

Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

John Bafford

6 years ago

> On Jan 24, 2020, at 14:27, Mike Schinkel <mike@newclarity.net> wrote:
>
> Thus far we have discussed that implementation of type checking for arrays would be too costly from a performance perspective and that there is no good solution that is not extremely complicated to implement.
>
> Given that, can we consider an alternative?
>
> ALLOW the use of a syntax for typed arrays — whether it be type[] or [type] — but only validate that it is an array and that the "type" is in fact a type, but don't actually validate that each element is the correct type.
>
> This would allow those of us who want to start documenting specific usage using type hints to be able to do so instead of what we currently have to do is PHPDoc one way and type hint with "array."  It would also allow IDEs like PhpStorm to add support.
>
> Is this something the PHP community would consider?
>
> -Mike

My opinion is that if you're going to declare the type of a variable, you have to have some way of enforcing that the type _really_ is what you say it is. Otherwise, the type information is basically a lie, and you're much better off without it. If PHP's type system can't or won't enforce the type fully as declared, then it's much better to have phpdocs that assert what the type "really" is, like we do now.

I have some ideas on what might be reasonably performant array type enforcement, but having not fully read the thread, I'll keep that to myself until I have a chance to see that I have anything that's actually novel.

-John