Re: [RFC][Discuss] Arrow Functions

Hi Ilija, For some reason I don’t see your original reply yet. Anyway… > On 4 Feb 2017, at 22:48, ilija.tovilo@me.com wrote: > > Ah, my example was of course wrong again -.- > > The caller should’ve looked like this (although I think you get the point): > > ```Swift > fetchUsers { users in > // users is inferred to be an array of > Users > } > ``` > > Regards > > > On 4 Feb 2017, 16:41 +0100, ilija.tovilo@me.com, wrote: >> Hey Stephen >> >>> You don't *have to* specify types at all. If you want to use PHP without >>> verifying/requiring types, thats your prerogative, but given the recent improvements to allow scalar >>> type hinting, I think it’s a mistake to say that *any* use of type hints is “not recommended”. >> >> Sure you don’t but then you loose all the benefits of specifying types. We want typing >> but only if we don’t have to specify types all over the place. I really dislike having to add >> PHPDocs everywhere just to get some proper autocompletions. >> You’re really starting to lose me now. You want types but don’t want to define them, and you’re somehow mixing phpdoc into this. Ultimately the common example everyone has for arrow functions/short closures is something like array_map or array_filter. Currently PHP has zero support for Foo[] (or array<Foo> if you prefer) as a type hint. In *theory* an IDE could use the calling scope’s context (assuming the source of the array is purely local or from arguments/return values that are typed) to infer types, but I haven’t seen it, and I would likely still use type hints, to cover the case where something changes elsewhere. >>> I'm not sure if you've mixed up your terms of if I'm too tired but I >>> don't understand what you mean here. The short arrow function *is* the callee, and that’s >>> where you’re suggesting we shouldn’t use type hints. >> >> Sorry, that was confusing. I was thinking of a situation like this one: >> >> ```Swift >> func fetchUsers(callback: ([User]) -> Void) { >> ... >> } >> ``` >> >> So, the callee (fetchUsers) defines what the provided >> closure must look like. >> The caller, on the other hand, doesn’t have to specify that again as you’re just >> repeating yourself. >> >> ```Swift >> fetchUsers { user in >> // user is inferred to be a >> User object >> } >> ``` >> >> So I don’t think the burden of providing typing information should be on the caller >> providing the closure. >> Ok so yes, you’re talking about the same thing as the two RFC’s I linked to. I would love to be able to say “I expect a callable that accepts Foo and returns an int”, but again, PHP doesn’t support that now, and frankly that doesn’t negate the need for type hints on short functions. >>> The whole issue with that is that using a pipe character could make things much less >>> clear/readable if the already established use of pipe for “type unions” (currently used in >>> multi-catch) were to be implemented for general type hint usage. >>> >>> Note: I’m not saying it’s not possible, but it’s *much* less readable, and any >>> “solution” just adds more characters, which is apparently the only reason to not use >>> function($foo) => $foo in the first place. >> >> But again, that’s personal preference. I like short a precise and think it’s more >> readable. Not everyone’s the same. >> >>> For most people readability isn't just about the number of characters. >> >> A lot of the time it is. What were you saying about not everyone being the same? >> Brains are very good at recognising patterns, they don’t need large keywords for that. >> As for me, I think it just adds clutter to the actual logic that I’m interested in. >>