Hi Ilija,
For some reason I don’t see your original reply yet. Anyway…
> On 4 Feb 2017, at 22:48, ilija.tov...@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 `User`s
> }
> ```
>
> Regards
>
>
> On 4 Feb 2017, 16:41 +0100, ilija.tov...@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.
>>
