[fpc-devel] Blocks support
jonas.maebe at elis.ugent.be
Wed Jul 16 23:21:12 CEST 2014
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
>> 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.
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.
More information about the fpc-devel