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 bla...@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.
--
βþ
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
