[RFC] Nullable Types

8 years ago by Levi Morrison — view source

unread

As alluded to in an earlier email today1 I am now moving the
Nullable Types RFC2 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
RFC3.

I look forward to a helpful and meaningful discussion!

8 years ago by Dmitry Stogov — view source

unread

As alluded to in an earlier email today1 I am now moving the
Nullable Types RFC2 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
RFC3.

It's better to use ? position before the type, to reduce fragmentation
with HHVM.

Thanks. Dmitry.

I look forward to a helpful and meaningful discussion!

8 years ago by Tom Worster — view source

unread

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

8 years ago by Derick Rethans — view source

unread

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

8 years ago by Davey Shafik — view source

unread

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

8 years ago by Matt Prelude — view source

unread

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

8 years ago by Fleshgrinder — view source

unread

As alluded to in an earlier email today1 I am now moving the
Nullable Types RFC2 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
RFC3.

I look forward to a helpful and meaningful discussion!

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

8 years ago by Lester Caine — view source

unread

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

8 years ago by Jesse Schalken — view source

unread

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:

As alluded to in an earlier email today1 I am now moving the
Nullable Types RFC2 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
RFC3.

I look forward to a helpful and meaningful discussion!

8 years ago by Levi Morrison — view source

unread

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.

8 years ago by Dmitry Stogov — view source

unread

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

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

8 years ago by Lester Caine — view source

unread

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

8 years ago by Tom Worster — view source

unread

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

but didn't push it for discussion in favor of Levi's nullable_type RFC (they are almost the same).

8 years ago by Dmitry Stogov — view source

unread

The grammar is taken from HHVM.
Using any other would make more mess.

Thanks. Dmitry.

8 years ago by Lin Yo-An — view source

unread

The grammar is taken from HHVM.
Using any other would make more mess.

I agree

8 years ago by guilhermeblanco@gmail.com — view source

unread

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:

The grammar is taken from HHVM.
Using any other would make more mess.

I agree

--
Guilherme Blanco
Lead Architect at E-Block

8 years ago by Dmitry Stogov — view source

unread

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.

8 years ago by Thomas Bley — view source

unread

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:

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

8 years ago by guilhermeblanco@gmail.com — view source

unread

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,

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:

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

8 years ago by fsb@thefsb.org — view source

unread

+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,

The grammar is taken from HHVM.
Using any other would make more mess.

I agree

--

Guilherme Blanco

Lead Architect at E-Block

8 years ago by fsb@thefsb.org — view source

unread

Hi Thomas,

What is a default return declaration? Is this for branches within the function that do not lead to a return statement?

Tom

From: Thomas Bley
Sent: ‎Wednesday‎, ‎April‎ ‎20‎, ‎2016 ‎12‎:‎53‎ ‎PM
To: guilhermeblanco@gmail.com, cornelius.howl@gmail.com, dmitry@zend.com
Cc: fsb@thefsb.org, internals@lists.php.net

What do you think about default return values?

e.g.

function foo(): db_result = null {
}

function canLogin(): bool = false {
}

8 years ago by Thomas Bley — view source

unread

Hello Tom,

with default return value I mean to return a certain value if nothing else is returned (similar to method parameters with a default value).

example 1:

declare(strict_types=0);

function my_strpos(string $haystack, string $needle): int = false {
return 42; // return 42
return false; // return false
return true; // return 1
return; // return false
}

example 2:

declare(strict_types=1);

function my_strpos(string $haystack, string $needle): int = false {
return 42; // return 42
return false; // return false
return true; // fatal error
return; // return false
}

Regards
Thomas

fsb@thefsb.org wrote on 21.04.2016 15:05:

Hi Thomas,

What is a default return declaration? Is this for branches within the function
that do not lead to a return statement?

Tom

From: Thomas Bley
Sent: ‎Wednesday‎, ‎April‎ ‎20‎, ‎2016 ‎12‎:‎53‎ ‎PM
To: guilhermeblanco@gmail.com, cornelius.howl@gmail.com, dmitry@zend.com
Cc: fsb@thefsb.org, internals@lists.php.net

What do you think about default return values?

e.g.

function foo(): db_result = null {
}

function canLogin(): bool = false {
}

8 years ago by Fleshgrinder — view source

unread

Hello Tom,

with default return value I mean to return a certain value if nothing else is returned (similar to method parameters with a default value).

example 1:

declare(strict_types=0);

function my_strpos(string $haystack, string $needle): int = false {
return 42; // return 42
return false; // return false
return true; // return 1
return; // return false
}

example 2:

declare(strict_types=1);

function my_strpos(string $haystack, string $needle): int = false {
return 42; // return 42
return false; // return false
return true; // fatal error
return; // return false
}

I definitely do not like the equal sign in there because it goes against
all my mathematical knowledge; an int is false?!?

Note that the same /would/ be possible with union types if given precedence:

function fn(): int|false {}

That being said, it is way too magic! A return without an argument is
void and has to result in a TypeError. Really, start to think about
the types as /checked annotations/ ...

/**

@return int|false
*/
function fn() {}

function fn(): int|false {}

... are equivalent and the former does not suddenly return false on
its own and hell it shouldn't.

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Thomas Bley — view source

unread

Note that the same /would/ be possible with union types if given precedence:

function fn(): int|false {}

false is currently not supported in the union_types rfc.

Regards
Thomas

Fleshgrinder wrote on 21.04.2016 21:33:

Hello Tom,

with default return value I mean to return a certain value if nothing else is
returned (similar to method parameters with a default value).

example 1:

declare(strict_types=0);

function my_strpos(string $haystack, string $needle): int = false {
return 42; // return 42
return false; // return false
return true; // return 1
return; // return false
}

example 2:

declare(strict_types=1);

function my_strpos(string $haystack, string $needle): int = false {
return 42; // return 42
return false; // return false
return true; // fatal error
return; // return false
}

I definitely do not like the equal sign in there because it goes against
all my mathematical knowledge; an int is false?!?

Note that the same /would/ be possible with union types if given precedence:

function fn(): int|false {}

That being said, it is way too magic! A return without an argument is
void and has to result in a TypeError. Really, start to think about
the types as /checked annotations/ ...

/**

@return int|false
*/
function fn() {}

function fn(): int|false {}

... are equivalent and the former does not suddenly return false on
its own and hell it shouldn't.

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Tom Worster — view source

unread

Hi Thomas,

Sorry for the delay. I was traveling last week.

By convention return; in PHP is an early return for a function that
returns nothing at all. I think it can be confusing when reading a
function to look at a return; line and have to remember to look
elsewhere to discover what that means. And it can mean something different
in every function.

I prefer to write functions that return only the declared type. In some
cases I need to write functions that return only the declared type or
null. That's the limit of what I think PHP 7.1 should provide.

Hence, for me this has no attraction but it does introduce new ways to
write bugs. So I am not enthusiastic.

Tom

Hello Tom,

with default return value I mean to return a certain value if nothing
else is returned (similar to method parameters with a default value).

example 1:

declare(strict_types=0);

function my_strpos(string $haystack, string $needle): int = false {
return 42; // return 42
return false; // return false
return true; // return 1
return; // return false
}

example 2:

declare(strict_types=1);

function my_strpos(string $haystack, string $needle): int = false {
return 42; // return 42
return false; // return false
return true; // fatal error
return; // return false
}

Regards
Thomas

fsb@thefsb.org wrote on 21.04.2016 15:05:

Hi Thomas,

What is a default return declaration? Is this for branches within the
function
that do not lead to a return statement?

Tom

From: Thomas Bley
Sent: ‎Wednesday‎, ‎April‎ ‎20‎, ‎2016 ‎12‎:‎53‎ ‎PM
To: guilhermeblanco@gmail.com, cornelius.howl@gmail.com, dmitry@zend.com
Cc: fsb@thefsb.org, internals@lists.php.net

What do you think about default return values?

e.g.

function foo(): db_result = null {
}

function canLogin(): bool = false {
}

[RFC] Nullable Types

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL