[fpc-devel] C-block reference syntax (blocker for 3.2)

[Blaise at blaise.ru]

On 07.12.2019 14:21, Sven Barth wrote:

> I stand by my point that the combination of anonymous function variables with calling conventions and cblocks occurs very, very seldomly.

I am not necessarily disputing that point, I am disputing your design decision, which was misinformed, but you continue to stand by it.
My primary point: closures and calling conventions are orthogonal. Even if DCC did not support combining them, I would have implemented the support anyway.

> your argument with VarArgs does not count either: one can not access VarArgs parameters inside a Delphi function (without resorting to assembly)

Again, you are misinformed.
I understand that you may not use DCC as much or at all, but you have just indicated in an adjacent email that you do have access to it.
You made the original assumption that DCC does not accept calling convention directives on method references without actually checking or asking someone with DCC experience, and, despite me having indicated twice already that VARARGS is acceptable and works, you continue to argue that it does not. Based on what, if not on your vast DCC experience?

> So there is no real overlap here.

The "real overlap here" is that, depending on which $MODESWITCH happens to be in effect, the sequence of lexemes
	type M = reference to procedure cdecl;
have different semantics -- constructing different entities that can and should be allowed to coexist, even within a single unit, without the need to toggle $MODESWITCH back and forth.

> But if we want to change this syntax, we should definitely change this now before 3.2 is out of the door.

Jonas just said that he "indeed did not know" about the syntax collision.
And that baffles me the most. The issue may have gone unnoticed back in 2016, but you were definitely aware of it in 2018. So, back in August, I reasonably assumed that you were presenting the consolidated position of the team. Turns out, you have never brought it to the team, and made that questionable design decision on your own.
This warrants a discussion, the one I thought the team already had (hence my overly elaborate plea), and now we are blocking 3.2 at the finish line.


> Am 07.12.2019 um 01:00 schrieb Blaise at blaise.ru:
>> Jonas parses them via procvar_dec, and I parse closure reference types via parse_proc_dec under symtablestack.push(invokable_interface.symtable), and it makes perfect sense since such types /are/ interfaces (to the point that they are directly implementable on classes).
> 
> you should parse the declaration using procvar_dec (with possible extensions/checks) as well, because that handles procvar specific functionality

But I do not need the "procvar specific functionality". As I said, I need an interface type, thus it makes perfect sense to parse the declaration as a method header and to get almost everything handled "for free".

> Only afterwards you create an interface with an appropriate method.

And what do I do with the unneeded procvardef? :)
Again: I am not saying that "the non-existent unified C-block/closure reference parser" would be especially difficult to implement, I have merely pointed out that, implementation-wise, having two separate parsers makes sense since they can fully leverage the existing infrastructure.

-- 
βþ