[fpc-devel] Blocks support

[Jonas Maebe]

On 16/07/14 21:19, Sven Barth wrote:
> On 16.07.2014 18:45, Jonas Maebe wrote:
>> While working on this, I didn't realise at all that Delphi had to have
>> rules already regarding capturing local variables for its own anonymous
>> method support. I've now read what it does and it indeed always has the
>> same behaviour as variables declared as "__block" in C blocks. So I
>> would propose to use this behaviour for consistency and leave out
>> support for capturing local variables as const/snapshot values.
>
> It would however be good if we'd at least have support for
> const/snapshot values so that we could easily add it once we come up
> with a suitable syntax.

The fewer kinds of behaviours are possible, the easier it is to see what 
the code does. I don't mind not supporting it at all. It can also be 
easily added later if really necessary (it's mainly a matter of /not/ 
generating certain metadata and copy/release helpers that we would 
generate otherwise).

>> Similarly, they also already have a syntax for "block type" variables
>> (var proc: reference to function(l: longint): longint;"), so I propose
>> to use that one as well instead of my "is block". Possibly with "cdecl;"
>> at the end to differentiate between C blocks and whatever the FPC
>> implementation will be, since some people will probably want to
>> reimplement the blocks runtime, or something similar, in Pascal
>> (definitely not me).
>
> I'm not that sure whether using the same syntax is a good idea... people
> want to have Delphi compatible anonymous functions which are basically
> reference counted interfaces instead of records...

Well, the block variable that's passed around is also a pointer. The 
record it points to can either be non-reference counted (in case it's a 
block for a global procedure/function, since those don't have context 
and hence can be reused for all instances) or reference counted. In the 
latter case, they start life on the stack, and are copied to the heap if 
necessary by the run time based on the copy/release calls that are 
made). In a sense, they behave a bit like an interface.

> Ah, they are block specific. That wasn't that clear to me before.
> *blush*

Sorry, I've been with my head in the blocks documentation since the 
start of the week, so I may not have been explicit regarding some things 
that I took implicitly for granted in the mean time.

> Ok, then the compiler can generate code for the reference
> counting (which it needs to do anyway) and we just leave non-ARC classes
> be... Delphi doesn't handle them specially either.

Ok.


Jonas