Re: inference of block return type
Re: inference of block return type
- Subject: Re: inference of block return type
- From: Bill Bumgarner <email@hidden>
- Date: Mon, 28 Jun 2010 15:12:23 -0700
Nah -- still Cocoa related.
The syntax serves two purposes:
(1) Allow for fully specified, fully typed, definitions of blocks.
(2) Allow for blocks to be used in the über-simple "unit-of-work" role offered by GCD where there are no arguments and no return values
Thus, the syntax full syntax is as I posted:
^<return-type> (<arg-list>) {<code>};
The return type is optional because there are so many cases where it can be automatically inferred (and the compiler will complain -- loudly -- when that isn't possible):
^ (<arg-list>) {<code>};
If there is no need for an argument list, then it can be omitted (achieving goal (2)):
^ {<code>};
While more complex than require all elements all the time, that it makes the dispatch_*() APIs much easier and more succinct to use (along with a number of other APIs) was deemed to be powerful enough to warrant the complexity implied by the additional flexibility.
You are correct that the documentation is lacking, but it is not completely non-existent.
This document does demonstrate declaring a return type, but only in the context of a typedef or block variable declaration (and not for a block literal):
http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/Blocks/Articles/bxDeclaringCreating.html#//apple_ref/doc/uid/TP40007502-CH4-SW1
The "Using Blocks" also shows declaring a return type, but only on the type definition and not on a block literal.
Many of the examples in "A Short Practical Guide To Blocks" also show declaring a block with an explicit return type:
http://developer.apple.com/iphone/library/featuredarticles/Short_Practical_Guide_Blocks/
I've filed <rdar://problem/8138925> asking for the documentation to treat the block literal syntax in detail.
b.bum
On Jun 28, 2010, at 2:56 PM, Tony Romano wrote:
> The syntax that Bill posted is not in the document. I hate the complexities in this syntax, there is no reason that I can think of to have multiple syntax to represent this object. Even talking to the GCD engineers at the show, they agrees it's overly complex for no apparent good reason.
>
> The syntax below to me seems inconsistent with the analogy the docs claim the block syntax came from (declaring C function ptrs) or at least I don't remember it ever using it in that form. (return type) (^blockname) (parameters) seems sufficient imo. The whole idea was to stick to a format that had precedence but use the new symbol ^(only remaining operator that is not overloadable in C++) instead of *(btw, that wasn't a block with a void return type :-).
>
> Anyhows, I no longer think this is a cocoa question...
> -Tony
>
> On 6/28/10 2:41 PM, Michael Ash wrote:
>> On Mon, Jun 28, 2010 at 4:48 PM, Bill Bumgarner<email@hidden> wrote:
>>
>>> On Jun 28, 2010, at 1:45 PM, Michael Ash wrote:
>>>
>>>
>>>> But I was unable to find any discussion of HOW you explicitly declare
>>>> the return value of a block expression.
>>>>
>>> ^<return-type> (<arg-list>) {<code>};
>>>
>> Sure, but is this documented in Apple's docs? The link to Blocks
>> Programming Topics posted by Tony Romano doesn't seem to include it,
>> although it alludes to its existence. That page does link to Apple's
>> submission to the standard committee which does show that syntax, but
>> it seems like the sort of thing that ought to be on apple.com too. Did
>> we miss it?
>>
>> Mike
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>>
>>
>>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden