On 4/28/14, 3:30 PM, Levi Morrison wrote:
As I write that I suspect it's because generators actually "return" an
interator object, and so the return type of the generator is being
interpreted relative to the construction, not iteration, of the generator.
That seems like a likely source of confusion, as I would, as a developer,
expect to be specifying the type that gets returned from iteration, not
from construction, so that my foreach loop (or similar) can rely on the
type being returned.
The type hint is purposefully not the type of the value returned; a
generator always returns a generator. I will clarify this in the RFC and
maybe adjust the wording in the error message as well to better indicate
this.
I think this part warrants further consideration. The rest of the RFC I
fully look forward to using.
Special casing a generator's return type would be an inconsistency in the
design. If you var_dump() something that returns generator it tells you it
is a generator; this should match the type of the return value and anything
else is unexpected. As an example, using a generator to fulfill an Iterator
return type should succeed; special casing the Generator would complicate
the code to achieve this. Special casing the generator would also infringe
on other future ideas, such as adding generics to the language. All in all,
special casing generators doesn't make sense.
As far as the order of keywords in a closure, what order does Hack use?
The rest of the syntax seems based on it, so it seems sensible to follow
suit. (I couldn't find that information from 60 seconds on hacklang.org,
but it may be there.)
At least in the 2.4 branch of HHVM (which I have installed) they put it
before the use statement. Now that I have thought about this more, this is
a poor decision:
* use statements are basically parameters at construction time instead of
runtime
* putting the return type before the use statement looks really ugly
I will attempt to contact the HHVM team (perhaps SaraG) to see if there was
a technical reason for it.