RFC: Return Types Update

The RFC is very consistent.
It proposes only a part of the desired type-hinting features, but this part
is not questionable for me.

+1

The implementation has some minor issues.
Levi, if you won't object, I would like to play with implementation a bit,
right before commit (if it accepted).

Thanks. Dmitry.

On Thu, Oct 16, 2014 at 8:39 AM, Levi Morrison levi_morrison@byu.edu
wrote:

Dear Internals,

I finally have a working implementation for return types RFC1 built
on top of master. There are a few notes in the PR2 about the
implementation. I invite you all to review the PR and provide
feedback.

This means that I will soon move the return types RFC to voting phase.
If you have not yet had time to review the RFC recently I invite you
to do so now.

The RFC has been slightly altered since the last discussion:

• The RFC now targets PHP 7 (previously PHP 5.7).
• There is a new section about disallowing return types on certain
  methods4.
• The design and accompanying section of reflection3 has been
  rewritten entirely.

Regardless of the result of the RFC, I want to thank the many people
who have been helpful to me as I have learned php-src and iterated
over this RFC.

On Thu, Oct 16, 2014 at 6:39 AM, Levi Morrison levi_morrison@byu.edu
wrote:

Dear Internals,

I finally have a working implementation for return types RFC[1] built
on top of master. There are a few notes in the PR[2] about the
implementation. I invite you all to review the PR and provide
feedback.

This means that I will soon move the return types RFC to voting phase.
If you have not yet had time to review the RFC recently I invite you
to do so now.

The RFC has been slightly altered since the last discussion:

• The RFC now targets PHP 7 (previously PHP 5.7).
• There is a new section about disallowing return types on certain
  methods[4].
• The design and accompanying section of reflection[3] has been
  rewritten entirely.

Regardless of the result of the RFC, I want to thank the many people
who have been helpful to me as I have learned php-src and iterated
over this RFC.

+1

What I like about this RFC:

• It only covers return types and nothing else (no nullable types, no
  scalar types, etc), thus avoiding unnecessary controversy.
• It uses postfix type notation, which is great for grep, is compatible
  with Hack and avoids weird syntax with anonymous functions (and also with
  method generics, should they be introduced in the future).
• Sticking with covariant return types, even though it was tricky to
  implement.

Nikita

• There is a new section about disallowing return types on certain methods[4].

Perhaps, along the same lines, we could error if you use a nonsensical type hint for magic methods?

For example, allow this:

class FooBar {
    public function __debugInfo(): array {
        return [’test’];
    }
}

But not this:

class FooBar {
    public function __debugInfo(): callable {
        return [’test’];
    }
}

It’s not strictly necessary, but it would catch out bugs at “compile-time” (i.e. script startup) rather than call-time.

Andrea Faulds
http://ajf.me/

I very much like this — though I would say it was dependent on the nullable
types RFC (like splat and variadics were codependent).

While I would like to see the introduction of a void type, I understand and
respect the limitations on the RFC.

However, one thing that I do think is missing, is the equivalent of Hacks
$this return type. You have self and parent, but I think without a
static equivalent you can break things:

class foo {
static public function instanceOf(): self {
return new static();
}
}

class bar extends foo { }

foo::instanceOf(); // new foo, this is fine, returns self.
bar::instanceOf(); // new bar, no longer self

On Thu, Oct 16, 2014 at 12:39 AM, Levi Morrison levi_morrison@byu.edu
wrote:

Dear Internals,

I finally have a working implementation for return types RFC1 built
on top of master. There are a few notes in the PR2 about the
implementation. I invite you all to review the PR and provide
feedback.

This means that I will soon move the return types RFC to voting phase.
If you have not yet had time to review the RFC recently I invite you
to do so now.

The RFC has been slightly altered since the last discussion:

• The RFC now targets PHP 7 (previously PHP 5.7).
• There is a new section about disallowing return types on certain
  methods4.
• The design and accompanying section of reflection3 has been
  rewritten entirely.

Regardless of the result of the RFC, I want to thank the many people
who have been helpful to me as I have learned php-src and iterated
over this RFC.

• The design and accompanying section of reflection3 has been
  rewritten entirely.

I've some comments about the Reflection API addition/changes:

1. "Note that getReturnType will always return a ReflectionType
   object, even if there is no return type declared."

That feels weird, TBH. Other parts of the Reflection-API don't do that,
they simply return false if I would call e.g. getParentClass() when
there's none.

2. "This API was designed so you could use ReflectionType::getKind()
   in a switch statement to cover all cases, rather than be forced to use
   an if/else structure that calls isArray(), isCallable, etc like the
   ReflectionParameter API does."

I don't like the deviation from the existing Reflection API. I'm not
saying it's perfect, but I fear a "haystack,needle vs. needle,haystack"
thing here and would prefer the existing convention for is*() methods.

I wouldn't see a conflict it providing both as I see the usefulness.

3. The new class is called "ReflectionType", shouldn't it be
   "ReflectionReturnType" ?

4. Other reflection classes, e.g. ReflectionParameter provides "missing
   link" methods, specifically I'm missing:

public ReflectionClass getDeclaringClass ( void );
public ReflectionFunctionAbstract getDeclaringFunction ( void );

5. I think, also like in ReflectionParameter, there should a direct
   shortcut to the class, if provided (and not just the string name):

public ReflectionClass getClass ( void );

thanks,

• Markus