Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Nullable Types »

[RFC] Nullable Types

php.internals

Levi Morrison

10 years ago
As alluded to in an earlier email today[1] I am now moving the Nullable Types RFC[2] to the discussion phase. In a nutshell this RFC proposes syntax for declaring a type to alternatively be null. There is a decision that needs to be made: does the question mark go before or after the type name? function (?Foo $foo); function (Foo? $foo); There are precedents in several languages for each position. Some relevant issues to where the question mark goes are noted in the RFC[3]. I look forward to a helpful and meaningful discussion! [1]: http://news.php.net/php.internals/92252 [2]: https://wiki.php.net/rfc/nullable_types [3]: https://wiki.php.net/rfc/nullable_types#position_of

Dmitry Stogov

10 years ago
On 04/14/2016 06:42 AM, Levi Morrison wrote:
> As alluded to in an earlier email today[1] I am now moving the > Nullable Types RFC[2] to the discussion phase. In a nutshell this RFC > proposes syntax for declaring a type to alternatively be null.
+1 The up to date implementation for return-type-hints may be found at https://github.com/php/php-src/pull/1851/files Implementation for argument-type-hints is really not a problem
> > There is a decision that needs to be made: does the question mark go > before or after the type name? > > function (?Foo $foo); > function (Foo? $foo); > > There are precedents in several languages for each position. Some > relevant issues to where the question mark goes are noted in the > RFC[3].
It's better to use ? position before the type, to reduce fragmentation with HHVM. Thanks. Dmitry.

Tom Worster

10 years ago
On 4/14/16 3:50 AM, Dmitry Stogov wrote:
> The up to date implementation for return-type-hints may be found at > https://github.com/php/php-src/pull/1851/files
Splendid! Thank you, Dmitry. I will refer to it in the nullable_returns RFC[1]. Tom [1] https://wiki.php.net/rfc/nullable_returns

Dmitry Stogov

10 years ago
A week ago, I actually wrote my own RFC https://wiki.php.net/rfc/nullable_return_types but didn't push it for discussion in favor of Levi's nullable_type RFC (they are almost the same). I'm sure, union types bring too many conceptual and implementation questions, and I even don't speak abut intersections. Thanks. Dmitry. ________________________________________ From: Tom Worster <fsb@thefsb.org> Sent: Friday, April 15, 2016 20:17 To: Dmitry Stogov; internals Subject: Re: [PHP-DEV] [RFC] Nullable Types On 4/14/16 3:50 AM, Dmitry Stogov wrote:
> The up to date implementation for return-type-hints may be found at > https://github.com/php/php-src/pull/1851/files
Splendid! Thank you, Dmitry. I will refer to it in the nullable_returns RFC[1]. Tom [1] https://wiki.php.net/rfc/nullable_returns

Lester Caine

10 years ago
On 15/04/16 18:58, Dmitry Stogov wrote:
> I'm sure, union types bring too many conceptual and implementation questions, and I even don't speak abut intersections.
The one problem I see with all of this is that it is reliant on every single variable being passed in when in early PHP5 days the preference was to move to hashes of data passed as arrays to open up flexibility. None of my record handling currently relies on having every 'parameter' formally defined, and elements of the record that are not passed in the hash are most definitely replaced by null valued elements allowing the DB engine to supply the relevant schema default unless it is replaced by additional variable in the data array. The idea of converting every record array into an object with multiple 'typed' variables seems to me to be a total overload to me, but if that is what people think is essential to make PHP 'safer' then that some of those variables are inherently 'null' or need to be switched to null if a change is required back to the schema default. 'Union' does not fit easily into this model? Documenting the content of a record hash via the docblock comments fits perfectly with this method working ...
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Tom Worster

10 years ago
On 4/15/16 1:58 PM, Dmitry Stogov wrote:
> A week ago, I actually wrote my own RFC https://wiki.php.net/rfc/nullable_return_types
You proposed the ?Something grammar. With ?: and ?? appearing in recent PHP and proposals for ??= if not ?:= and now this, I feel we're heading to regex hell :p Tom

Dmitry Stogov

10 years ago
The grammar is taken from HHVM. Using any other would make more mess. Thanks. Dmitry. ________________________________________ From: Tom Worster <fsb@thefsb.org> Sent: Saturday, April 16, 2016 04:54 To: Dmitry Stogov; internals Subject: Re: [PHP-DEV] [RFC] Nullable Types On 4/15/16 1:58 PM, Dmitry Stogov wrote:
> A week ago, I actually wrote my own RFC https://wiki.php.net/rfc/nullable_return_types
You proposed the ?Something grammar. With ?: and ?? appearing in recent PHP and proposals for ??= if not ?:= and now this, I feel we're heading to regex hell :p Tom

Lin Yo-An

10 years ago
On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov <dmitry@zend.com> wrote:
> The grammar is taken from HHVM. > Using any other would make more mess. >
I agree

Guilherme Blanco

10 years ago
I read the RFC and I want to highlight why I'll vote -1 on it even before it goes to voting. IMHO, it looks backwards to what the language is progressing. The introduction of nullable type hint as a separate notation than a simple type hint makes it *very* hard to implement typed properties, factory methods and constructor verifications. Dmitry is even involved in the discussion of having IS_UNDEF until constructor ends, then enforcing type hinting at the end of constructor to trigger potential invalid instance state. It created a mess in the internal structure by creating a 3-state value: uninitialized, absent of value (null) and assigned value. All this problem would be solved by merging null into accepted value. So far the proposed solution there to take a wrong assumption to assume a default value based on type defined (like int = 0, string = '', etc), which are all potential valid values, leading to unpredictable behavior if a develop misses to assign a value to that property. Sure, people will say that now PHP will require a NullPointerException, PHP is turning into Java, or that I don't know what I'm talking about because they coded for Amiga and I don't (yes, I've seen that already in this mailing list). But the fact is that keeping control of 3-state flags are hard to maintain. Constructor verifications is actually a completely different subject that shouldn't be considered as part of typed properties, but for final properties (or whoever other keyword someone think is smarter because *reasons*). It's bad to bring this already to typed properties, specially because of its runtime performance impact. Now let's say we move forward with nullable type hint, ignore everything what I said and move forward. Congratulations, we just created a language inconsistency. Example: function foo(Bar $bar = null); Why now I have 2 ways to define a nullable value? Shouldn't this be changed into this: function foo(?Bar $bar); But of course, changing this would be a BC break and should be left for *reasons*. But accepting the absence of value (null) as a valid value, it would address the language inconsistency (the current support would be kept, so no BC break), and would solve a huge mess that typed properties patch currently needs to solve. Ah, and we don't continue into this path of madness where same thing have 144 different ways in different areas to be defined. Regards, On Mon, Apr 18, 2016 at 12:24 PM, Lin Yo-An <cornelius.howl@gmail.com> wrote:
> On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov <dmitry@zend.com> wrote: > > > The grammar is taken from HHVM. > > Using any other would make more mess. > > > I agree >
-- Guilherme Blanco Lead Architect at E-Block

Dmitry Stogov

10 years ago
What we really miss now, is an ability to define nullable return types. https://wiki.php.net/rfc/nullable_return_types I don't care about the same notations for arguments (and everything else), because we already may use NULL default value. However usage of "?" for arguments also may make sense. Someone may like this, someone not. Thanks. Dmitry. ________________________________ From: guilhermeblanco@gmail.com <guilhermeblanco@gmail.com> Sent: Wednesday, April 20, 2016 18:05 To: Lin Yo-An Cc: Dmitry Stogov; Tom Worster; internals Subject: Re: [PHP-DEV] [RFC] Nullable Types I read the RFC and I want to highlight why I'll vote -1 on it even before it goes to voting. IMHO, it looks backwards to what the language is progressing. The introduction of nullable type hint as a separate notation than a simple type hint makes it *very* hard to implement typed properties, factory methods and constructor verifications. Dmitry is even involved in the discussion of having IS_UNDEF until constructor ends, then enforcing type hinting at the end of constructor to trigger potential invalid instance state. It created a mess in the internal structure by creating a 3-state value: uninitialized, absent of value (null) and assigned value. All this problem would be solved by merging null into accepted value. So far the proposed solution there to take a wrong assumption to assume a default value based on type defined (like int = 0, string = '', etc), which are all potential valid values, leading to unpredictable behavior if a develop misses to assign a value to that property. Sure, people will say that now PHP will require a NullPointerException, PHP is turning into Java, or that I don't know what I'm talking about because they coded for Amiga and I don't (yes, I've seen that already in this mailing list). But the fact is that keeping control of 3-state flags are hard to maintain. Constructor verifications is actually a completely different subject that shouldn't be considered as part of typed properties, but for final properties (or whoever other keyword someone think is smarter because *reasons*). It's bad to bring this already to typed properties, specially because of its runtime performance impact. Now let's say we move forward with nullable type hint, ignore everything what I said and move forward. Congratulations, we just created a language inconsistency. Example: function foo(Bar $bar = null); Why now I have 2 ways to define a nullable value? Shouldn't this be changed into this: function foo(?Bar $bar); But of course, changing this would be a BC break and should be left for *reasons*. But accepting the absence of value (null) as a valid value, it would address the language inconsistency (the current support would be kept, so no BC break), and would solve a huge mess that typed properties patch currently needs to solve. Ah, and we don't continue into this path of madness where same thing have 144 different ways in different areas to be defined. Regards, On Mon, Apr 18, 2016 at 12:24 PM, Lin Yo-An <cornelius.howl@gmail.com<mailto:cornelius.howl@gmail.com>> wrote: On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov <dmitry@zend.com<mailto:dmitry@zend.com>> wrote:
> The grammar is taken from HHVM. > Using any other would make more mess. >
I agree
-- Guilherme Blanco Lead Architect at E-Block

Unnamed Person

10 years ago
What do you think about default return values? e.g. function foo(): db_result = null { } function canLogin(): bool = false { } Regards Thomas Dmitry Stogov wrote on 20.04.2016 18:13:

Guilherme Blanco

10 years ago
PHP lacks of enterprise engineering over the language, and that is the problem. You're not resolving the holism in the language, but rather a specific part without consider the whole. Yes, it makes sense to support ?Foo for and only for return types, but what about everything else? What about future scope? Sure, future scope is unknown, but we do have scope that is currently being defined, you're even debating over it and it'll severely impacted by this small little support that we're adopting right now only for this specific case. The problem of not thinking in the language as a whole and just fixing small bits every time lead to the inconsistency hell we live today. So please, step back and look over that introducing this tiny language enhancement will impact final properties, typed properties and add a language inconsistency with already defined standard (instanced may be absent of value like in function parameters). If you don't think what I'm saying is true, look at return type hint and how you define parameter type hint. And with typed properties (as the patch currently stands), it will follow parameter type hint instead of return type hint. Regards, On Wed, Apr 20, 2016 at 12:13 PM, Dmitry Stogov <dmitry@zend.com> wrote:
> What we really miss now, is an ability to define nullable return types. > > > https://wiki.php.net/rfc/nullable_return_types > > > I don't care about the same notations for arguments (and everything else), > because we already may use NULL default value. > > However usage of "?" for arguments also may make sense. Someone may like > this, someone not. > > > Thanks. Dmitry. > > ------------------------------ > *From:* guilhermeblanco@gmail.com <guilhermeblanco@gmail.com> > *Sent:* Wednesday, April 20, 2016 18:05 > *To:* Lin Yo-An > *Cc:* Dmitry Stogov; Tom Worster; internals > *Subject:* Re: [PHP-DEV] [RFC] Nullable Types > > I read the RFC and I want to highlight why I'll vote -1 on it even before > it goes to voting. > > IMHO, it looks backwards to what the language is progressing. The > introduction of nullable type hint as a separate notation than a simple > type hint makes it *very* hard to implement typed properties, factory > methods and constructor verifications. > > Dmitry is even involved in the discussion of having IS_UNDEF until > constructor ends, then enforcing type hinting at the end of constructor to > trigger potential invalid instance state. It created a mess in the internal > structure by creating a 3-state value: uninitialized, absent of value > (null) and assigned value. All this problem would be solved by merging null > into accepted value. > So far the proposed solution there to take a wrong assumption to assume a > default value based on type defined (like int = 0, string = '', etc), which > are all potential valid values, leading to unpredictable behavior if a > develop misses to assign a value to that property. > > Sure, people will say that now PHP will require a NullPointerException, > PHP is turning into Java, or that I don't know what I'm talking about > because they coded for Amiga and I don't (yes, I've seen that already in > this mailing list). But the fact is that keeping control of 3-state flags > are hard to maintain. > > Constructor verifications is actually a completely different subject that > shouldn't be considered as part of typed properties, but for final > properties (or whoever other keyword someone think is smarter because > *reasons*). It's bad to bring this already to typed properties, specially > because of its runtime performance impact. > > Now let's say we move forward with nullable type hint, ignore everything > what I said and move forward. Congratulations, we just created a language > inconsistency. Example: > > function foo(Bar $bar = null); > > Why now I have 2 ways to define a nullable value? Shouldn't this be > changed into this: > > function foo(?Bar $bar); > > But of course, changing this would be a BC break and should be left for > *reasons*. But accepting the absence of value (null) as a valid value, it > would address the language inconsistency (the current support would be > kept, so no BC break), and would solve a huge mess that typed properties > patch currently needs to solve. Ah, and we don't continue into this path of > madness where same thing have 144 different ways in different areas to be > defined. > > > Regards, > > On Mon, Apr 18, 2016 at 12:24 PM, Lin Yo-An <cornelius.howl@gmail.com> > wrote: > >> On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov <dmitry@zend.com> wrote: >> >> > The grammar is taken from HHVM. >> > Using any other would make more mess. >> > >> I agree >> > > > > -- > Guilherme Blanco > Lead Architect at E-Block >
-- Guilherme Blanco Lead Architect at E-Block

Tom Worster

10 years ago
+1 to what Dmity wrote. I prefer not to have ?Something argument hints but I acknowledge that others want it. Tom From: Dmitry Stogov Sent: ‎Wednesday‎, ‎April‎ ‎20‎, ‎2016 ‎12‎:‎13‎ ‎PM To: guilhermeblanco@gmail.com, Lin Yo-An Cc: Tom Worster, internals What we really miss now, is an ability to define nullable return types. https://wiki.php.net/rfc/nullable_return_types I don't care about the same notations for arguments (and everything else), because we already may use NULL default value. However usage of "?" for arguments also may make sense. Someone may like this, someone not. Thanks. Dmitry. From: guilhermeblanco@gmail.com <guilhermeblanco@gmail.com> Sent: Wednesday, April 20, 2016 18:05 To: Lin Yo-An Cc: Dmitry Stogov; Tom Worster; internals Subject: Re: [PHP-DEV] [RFC] Nullable Types I read the RFC and I want to highlight why I'll vote -1 on it even before it goes to voting. IMHO, it looks backwards to what the language is progressing. The introduction of nullable type hint as a separate notation than a simple type hint makes it *very* hard to implement typed properties, factory methods and constructor verifications. Dmitry is even involved in the discussion of having IS_UNDEF until constructor ends, then enforcing type hinting at the end of constructor to trigger potential invalid instance state. It created a mess in the internal structure by creating a 3-state value: uninitialized, absent of value (null) and assigned value. All this problem would be solved by merging null into accepted value. So far the proposed solution there to take a wrong assumption to assume a default value based on type defined (like int = 0, string = '', etc), which are all potential valid values, leading to unpredictable behavior if a develop misses to assign a value to that property. Sure, people will say that now PHP will require a NullPointerException, PHP is turning into Java, or that I don't know what I'm talking about because they coded for Amiga and I don't (yes, I've seen that already in this mailing list). But the fact is that keeping control of 3-state flags are hard to maintain. Constructor verifications is actually a completely different subject that shouldn't be considered as part of typed properties, but for final properties (or whoever other keyword someone think is smarter because *reasons*). It's bad to bring this already to typed properties, specially because of its runtime performance impact. Now let's say we move forward with nullable type hint, ignore everything what I said and move forward. Congratulations, we just created a language inconsistency. Example: function foo(Bar $bar = null); Why now I have 2 ways to define a nullable value? Shouldn't this be changed into this: function foo(?Bar $bar); But of course, changing this would be a BC break and should be left for *reasons*. But accepting the absence of value (null) as a valid value, it would address the language inconsistency (the current support would be kept, so no BC break), and would solve a huge mess that typed properties patch currently needs to solve. Ah, and we don't continue into this path of madness where same thing have 144 different ways in different areas to be defined. Regards, On Mon, Apr 18, 2016 at 12:24 PM, Lin Yo-An <cornelius.howl@gmail.com> wrote: On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov <dmitry@zend.com> wrote:
> The grammar is taken from HHVM. > Using any other would make more mess. >
I agree
-- Guilherme Blanco Lead Architect at E-Block

Björn Larsson

10 years ago
Den 2016-04-15 kl. 19:58, skrev Dmitry Stogov:
> A week ago, I actually wrote my own RFC https://wiki.php.net/rfc/nullable_return_types > but didn't push it for discussion in favor of Levi's nullable_type RFC (they are almost the same). > > I'm sure, union types bring too many conceptual and implementation questions, and I even don't speak abut intersections. > > Thanks. Dmitry.
Reading this together with Levi's RFC and it gives a very clear picture on the proposed feature. Definitely a +1. Hope that part of the text in this RFC can be lifted into Levi's RFC. E.g. the binary tree example gives a good motivation / UC etc. Regards //Björn

Derick Rethans

10 years ago
On Wed, 13 Apr 2016, Levi Morrison wrote:
> As alluded to in an earlier email today[1] I am now moving the > Nullable Types RFC[2] to the discussion phase. In a nutshell this RFC > proposes syntax for declaring a type to alternatively be null. > > There is a decision that needs to be made: does the question mark go > before or after the type name? > > function (?Foo $foo); > function (Foo? $foo); > > There are precedents in several languages for each position. Some > relevant issues to where the question mark goes are noted in the > RFC[3].
Please put it where HHVM puts it: in front of it. Other languages are less of an issue than a syntax that's already used in a somewhat PHP language. As to the rest of the RFC: LGTM! cheers, Derick

Davey

10 years ago
On Thu, Apr 14, 2016 at 2:00 AM, Derick Rethans <derick@php.net> wrote:
> On Wed, 13 Apr 2016, Levi Morrison wrote: > > > As alluded to in an earlier email today[1] I am now moving the > > Nullable Types RFC[2] to the discussion phase. In a nutshell this RFC > > proposes syntax for declaring a type to alternatively be null. > > > > There is a decision that needs to be made: does the question mark go > > before or after the type name? > > > > function (?Foo $foo); > > function (Foo? $foo); > > > > There are precedents in several languages for each position. Some > > relevant issues to where the question mark goes are noted in the > > RFC[3]. > > Please put it where HHVM puts it: in front of it. Other languages are > less of an issue than a syntax that's already used in a somewhat PHP > language. > > As to the rest of the RFC: LGTM!
I much prefer the "Nullable Foo" (?Foo) to "Foo or Null" (Foo?). I find it easier to read. However, I am not a fan of introducing both this and the "Null" type for union types — this should be the only way to create nullable types. We already have too many things that are possible in more than one way. As it sits, this is purely syntactic sugar (when taken in tandem with union types) and [if] we agree that it is good, then let us just forgo the other syntax entirely. I'll add a little about that on the appropriate thread. - Davey

Matt Prelude

10 years ago
On 14/04/16 10:59, Davey Shafik wrote:
> On Thu, Apr 14, 2016 at 2:00 AM, Derick Rethans <derick@php.net> wrote: > >> On Wed, 13 Apr 2016, Levi Morrison wrote: >> >>> As alluded to in an earlier email today[1] I am now moving the >>> Nullable Types RFC[2] to the discussion phase. In a nutshell this RFC >>> proposes syntax for declaring a type to alternatively be null. >>> >>> There is a decision that needs to be made: does the question mark go >>> before or after the type name? >>> >>> function (?Foo $foo); >>> function (Foo? $foo); >>> >>> There are precedents in several languages for each position. Some >>> relevant issues to where the question mark goes are noted in the >>> RFC[3]. >> Please put it where HHVM puts it: in front of it. Other languages are >> less of an issue than a syntax that's already used in a somewhat PHP >> language. >> >> As to the rest of the RFC: LGTM! > > I much prefer the "Nullable Foo" (?Foo) to "Foo or Null" (Foo?). I find it > easier to read. > > However, I am not a fan of introducing both this and the "Null" type for > union types — this should be the only way to create nullable types. We > already have too many things that are possible in more than one way. > > As it sits, this is purely syntactic sugar (when taken in tandem with union > types) and [if] we agree that it is good, then let us just forgo the other > syntax entirely. I'll add a little about that on the appropriate thread. > > - Davey >
Also agree, the "nullable foo" reads better and has the advantage of compatibility with HHVM. The easier we make it for people to switch interpreters (and develop software which works on both interpreters) the better for PHP as a whole. Also agree that we don't need null union types if we have nullable types. - Matt

Fleshgrinder

10 years ago
On 4/14/2016 5:42 AM, Levi Morrison wrote:
> As alluded to in an earlier email today[1] I am now moving the > Nullable Types RFC[2] to the discussion phase. In a nutshell this RFC > proposes syntax for declaring a type to alternatively be null. > > There is a decision that needs to be made: does the question mark go > before or after the type name? > > function (?Foo $foo); > function (Foo? $foo); > > There are precedents in several languages for each position. Some > relevant issues to where the question mark goes are noted in the > RFC[3]. > > I look forward to a helpful and meaningful discussion! > > [1]: http://news.php.net/php.internals/92252 > [2]: https://wiki.php.net/rfc/nullable_types > [3]: https://wiki.php.net/rfc/nullable_types#position_of >
I have to agree with the question mark in front after reading the possible problems with the question mark as a suffix, the fact that HHVM already puts it in front, and the argument to read it as "nullable type" instead of "type or null". :) +1
-- Richard "Fleshgrinder" Fussenegger

Lester Caine

10 years ago
On 14/04/16 04:42, Levi Morrison wrote:
> There are precedents in several languages for each position. Some > relevant issues to where the question mark goes are noted in the > RFC[3].
Another discussion reference ... http://www.firebirdsql.org/manual/nullguide.html http://www.firebirdsql.org/manual/nullguide-check-constraints.html adds a little complexity to the validation case.
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Jesse Schalken

10 years ago
I read the RFC and it all sounds good to me. I appreciate the care taken to ensure method compatibility rules are correct, a smooth interop with =null, and to consider impact on union types if added later (? just becomes sugar). I'm not sure if it's been mentioned or not, but the position of the ? has impact on the ability to add a foo[] shorthand for generic arrays. Namely, if the ? is at the start, then the syntax becomes ambiguous. string[]? (nullable array of strings) string?[] (array of nullable strings) ?string[] (ambiguous, need to consult precedence rules and/or use brackets) I'm not sure how HHVM/Hack deals with that, or if it even has the foo[] shorthand. On Thu, Apr 14, 2016 at 1:42 PM, Levi Morrison <morrison.levi@gmail.com> wrote:

Levi Morrison

10 years ago
On Wed, Apr 20, 2016 at 11:55 AM, Jesse Schalken <me@jesseschalken.com> wrote:
> I read the RFC and it all sounds good to me. I appreciate the care taken to > ensure method compatibility rules are correct, a smooth interop with =null, > and to consider impact on union types if added later (? just becomes sugar). > > I'm not sure if it's been mentioned or not, but the position of the ? has > impact on the ability to add a foo[] shorthand for generic arrays. Namely, > if the ? is at the start, then the syntax becomes ambiguous. > > string[]? (nullable array of strings) > > string?[] (array of nullable strings) > > ?string[] (ambiguous, need to consult precedence rules and/or use brackets) > > > I'm not sure how HHVM/Hack deals with that, or if it even has the foo[] > shorthand.
You would write `array<?string>`; Hack doesn't have a short-hand syntax.