Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108067
MIME-Version: 1.0
References: <CAF+90c-vPOmHzjoDFNi3m+iTgfz6dJep1DAHuCFcQDctjeEJMg@mail.gmail.com>
 <e30686d8-4836-4403-851f-06f296ccbafd@www.fastmail.com> <CAH0Uv3Hp2GUwKX0YOs-E1-1W9LkXzc71pBsvNQRnRvNicw=YdQ@mail.gmail.com>
 <CALKiJKqTpuyUQ3gu=hVZumxdjut-9HiRBXLy9DRNf41bihe=pw@mail.gmail.com>
In-Reply-To: <CALKiJKqTpuyUQ3gu=hVZumxdjut-9HiRBXLy9DRNf41bihe=pw@mail.gmail.com>
Date: Thu, 9 Jan 2020 16:30:30 +0100
Message-ID: <CAF+90c8fuNLUy4drT1F84E6=WRe44VD9Zq6T+4bT+41BfD5q+Q@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006d5ab1059bb6b18a"
Subject: Re: [PHP-DEV] [RFC] Static return type
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000006d5ab1059bb6b18a
Content-Type: text/plain; charset="UTF-8"

On Thu, Jan 9, 2020 at 4:06 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> On Thu, 9 Jan 2020 at 14:23, Andreas Hennings <andreas@dqxtech.net> wrote:
>
> > > However, $this is not a real type, and it is unclear what the advantage
> > of specifying $this rather than static would be from a type system level
> > perspective.
> >
> > Perhaps not from a "type system level", but from a more broad "enforced
> > contract" level.
> > E.g. IDEs or code inspection tools can warn if a method will not return
> > $this.
> > This also means recursive calls also need to return $this instead of
> > static.
> >
> > class C {
> >   function foo(): static {
> >     return clone $this;
> >   }
> >   function bar(): $this {
> >     return $this->foo();  // IDE can complain.
> >   }
> > }
> >
>
>
> I think there are two different purposes for annotating return types:
>
> 1) Contracts that tell the caller what values they should expect when
> calling the function.
> 2) Constraints on the implementation which don't affect the caller, but
> allow the author to catch certain bugs.
>
> The primary purpose, in my mind, is (1), with (2) generally coming as a
> side-effect: if your contract is to return an int, then tools can warn you
> when you don't.
>
> All concrete types can be seen this way: scalars, classes, and pseudo-types
> like "iterable" are all contracts that calling code can rely on. "self",
> "parent", and "static" fit into that list fine, because they're ultimately
> specifying a class name.
>
> The special "void" keyword doesn't actually make sense as a contract given
> PHP's calling convention - as far as the calling code's concerned, it's
> equivalent to "null". So it exists only for purpose (2), constraining the
> implementation for the benefit of the function's author.
>
> $this would fit into the same category - as far as calling code is
> concerned it is equivalent to "static", unless they're doing something very
> specific with object identity. This makes it an odd constraint on
> interfaces, for example - DateTimeInterface exists specifically to have
> mutable and immutable implementations, and a return type of $this would
> explicitly prevent that.
>
> If we add ": $this" alongside ": void", I wonder where that takes us next -
> what other constraints on a function can be expressed using that notation
> which aren't contracts on the value seen by the caller? If we don't want to
> explore that question, should we avoid adding ": $this"?
>

An argument could be made that $this does also specify a certain contract
to the caller: That the API may be used fluently or not without change in
functionality. That is

    $foo->setBar();
    $foo->setBaz();

must be strictly equivalent to

    $foo
       ->setBar()
       ->setBaz()
    ;

The same is not the case for a plain "static" type. In fact, I think that
for all other uses of "static" outside of fluent interfaces, not using the
return value would be a programming error.

But still, this kind of contract is not a type-system contract, and I'm not
sure it's a good idea to mix other types of API contracts into the type
system in this fashion.

Regards,
Nikita

--0000000000006d5ab1059bb6b18a--