Skip to content

Add support for single-expression methods#58

Open
thekid wants to merge 1 commit into
masterfrom
feature/single-expression-methods
Open

Add support for single-expression methods#58
thekid wants to merge 1 commit into
masterfrom
feature/single-expression-methods

Conversation

@thekid
Copy link
Copy Markdown
Member

@thekid thekid commented Jul 19, 2025

This PR adds syntactic support for single-expression methods

class Person {
  public function __construct(private string $name) { }

  // Equivalent of public function name() { return $this->name; }
  public function name() => $this->name;
}

See:

@thekid
Copy link
Copy Markdown
Member Author

thekid commented Aug 2, 2025

RFC has been declined

@thekid
Copy link
Copy Markdown
Member Author

thekid commented Oct 3, 2025

This would be consistent with the abbreviated property hooks syntax:

class User {
  public function __construct(private string $first, private string $last) {}
 
  // Long form
  public string $fullName {
    get { 
      return $this->first.' '.$this->last;
    }
  }

  // Short form
  public string $fullName {
    get => $this->first.' '.$this->last;
  }

  // Long form
  public string $username {
    set(string $value) {
      $this->username= strtolower($value);
    }
  }
 
  // Short form
  public string $username {
    set => strtolower($value);
  }
}

...which sets => [exor] as an equivalent of { return [expr]; }.

$parse->expecting('}', 'method declaration');
} else if ('=>' === $parse->token->value) { // Single expression
$parse->forward();
$statements= [new ReturnStatement($this->expression($parse, 0), $parse->token->line)];
Copy link
Copy Markdown
Member Author

@thekid thekid Oct 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is inconsistent with how short and long forms of property accessors are parsed - they make use of the Block class:

  • body for => [expr]: Expr
  • body for { [statement]; }: Block([Statement])

@thekid
Copy link
Copy Markdown
Member Author

thekid commented May 16, 2026

This adds an inconsistency with fn() => { ... } (see https://wiki.php.net/rfc/arrow_functions_v2#multi-statement_bodies) which is supported by this parser.

Idea

  • fn captures variables from the surrounding scope
  • function does not
  • => ... is short for { return ... }

What should work

Methods:

class T {
  public function name() => $this->name; // 🆕

  // Equivalent of
  // public function name() { return $this->name; }
}

Binding closures:

fn($a, $b) => $a + $b;

// Equivalent of
// fn($a, $b) { return $a + $b; } // 🆕

Closures:

function($a, $b) => $a + $b; // 🆕

// Equivalent of
// function($a, $b) { return $a + $b; }

Functions:

function add($a, $b) => $a + $b; // 🆕

// Equivalent of
// function add($a, $b) { return $a + $b; }

Consistency with other constructs

Property hooks:

class Entry implements Value {
  private $attributes= [];

  public string $slug {
    get => $this->attributes['slug'];

    // Equivalent of
    // get { return $this->attributes['slug']; }
  }
}

Match statement:

match ($response->status()) {
  204 => null,
  200 => $response->value(),
  404 {                         // 🆕 https://wiki.php.net/rfc/match_expression_v2#blocks
    if ($optional) return null;

    throw new NoSuchElementException('...');
  },
}

In all cases, a single expression should be parsed into the node representing it, while multiple statements should form a Block.


⚠️ The fn() => { ... } form should be deprecated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant