Regarding type hinting for return values. The first that comes to mind may be adding the type before the name of the function in its definition:

function string foo() {
...
}

I don't think this is readable, I never thought C syntax was readable, we only understand it because we become used to it.

The other option is to put the returned type after the arguments. I've come up with a few alternatives:

1)

function foo(...) as string {
...
}

The as keyword is already taken and the use here can't be confused with its other uses. It's acceptably readable. But I think that this isn't cohesive with previous type hinting. It would be if "as" was used for all type hinting, compare:

function foo(int $arg1, array $arg2) as string { ... }

function foo($arg1 as int, $arg2 as array) as string { ... }

This is just because "as" is a word with ambiguous purpose. The same would happen with a keyword like "is":

function foo($arg1 is int, $arg2 is array) is string { ... }

Here, "is" sounds more pertinent, and would fallback more nicely when stepping forward to variable's type hinting. Compare:

$var as string;

$var is string;

class Foo {
  private $bar as string;
}

class Foo {
  private $bar is string;
}


2)

function foo(...) return string {
...
}

I think this increases readability, since its more explicit. The return keyword is reused, which is a plus, but it's close enough to the purpose of the keyword outside this context, that it might be confused.

Since "return" is a more explicit word than "as" or "is", it doesn't have the problem of cohesiveness. But it can only be used to type hint return types:

function foo(int $arg1, array $arg2) return string { ... }


3)

function foo(...) returns string {
...
}

Same as (2) but the keyword is more explicit, more readable and is less prone to confusion with the "return" keyword. But a new keyword is taken.