- This RFC does not add, modify, or remove keywords at all; this notably
excludes type-hints for scalars. Supporting scalar type declarations is
outside the scope of this RFC; if you are interested in supporting scalar
type declarations please discuss it elsewhere.
Well, I think that that should be added here also your future work of 'void'.
So, add: int, float, numeric (int or float), string, bool, void.Sorry.
Addressing scalar return hints in this proposal would be foolish without
also introducing scalar parameter typing. Beyond that, addressing scalars
would almost certainly doom the RFC to rejection as scalar typing is like
the Vietnam of php-src ;)
At first glance this looks to me like a workable solution precisely because
it allows progress while avoiding the scalar quagmire.
- This RFC does not add, modify, or remove keywords at all; this notably
excludes type-hints for scalars. Supporting scalar type declarations is
outside the scope of this RFC; if you are interested in supporting scalar
type declarations please discuss it elsewhere.Addressing scalar return hints in this proposal would be foolish without
also introducing scalar parameter typing. Beyond that, addressing scalars
would almost certainly doom the RFC to rejection as scalar typing is like
the Vietnam of php-src ;)
Maybe the Korea — there are still two sides, years after the war, and
occasional skirmishes. I'd say Unicode was our Vietnam. :)
At first glance this looks to me like a workable solution precisely because
it allows progress while avoiding the scalar quagmire.
Same. I haven't looked at the patch yet, but I like how clean (and
limited in scope) this is.
Levi, what's the syntax like for closures with use blocks? I can see
that looking a bit weird either way, since it's presumably either:
function ($foo): Bar use ($quux) {}
or:
function ($foo) use ($quux): Bar {}
Neither are exactly ideal, but that's the hand we've dealt ourselves, I guess.
Adam
Levi, what's the syntax like for closures with use blocks? I can see
that looking a bit weird either way, since it's presumably either:function ($foo): Bar use ($quux) {}
or:
function ($foo) use ($quux): Bar {}
Neither are exactly ideal, but that's the hand we've dealt ourselves, I
guess.
I believe it is the latter: function ($foo) use ($quux): Bar {}
I'll check with Joe Watkins. Do you have a case for one being superior to
the other?
Levi, what's the syntax like for closures with use blocks? I can see
that looking a bit weird either way, since it's presumably either:function ($foo): Bar use ($quux) {}
or:
function ($foo) use ($quux): Bar {}
Neither are exactly ideal, but that's the hand we've dealt ourselves, I
guess.I believe it is the latter: function ($foo) use ($quux): Bar {}
I'll check with Joe Watkins. Do you have a case for one being superior to
the other?
Not really — I think I prefer that one slightly, but they both require
a moment to parse. On the bright side, I don't see a lot of people
using return type declarations with closures.
Adam
Levi, what's the syntax like for closures with use blocks? I can see
that looking a bit weird either way, since it's presumably either:function ($foo): Bar use ($quux) {}
or:
function ($foo) use ($quux): Bar {}
Neither are exactly ideal, but that's the hand we've dealt ourselves, I
guess.I believe it is the latter: function ($foo) use ($quux): Bar {}
I'll check with Joe Watkins. Do you have a case for one being superior to
the other?Not really — I think I prefer that one slightly, but they both require
a moment to parse. On the bright side, I don't see a lot of people
using return type declarations with closures.
If we ever support type hints like function array_sort(array &$array, callable($a, $b): int $callback) then I can see us using type declarations
with closures. Maybe.
So in summary: after the use statement is visually a bit better. Perhaps
someone will think of one reason to do the former but I'll just plan on
documenting it as the latter option.