[fpc-devel] C-block reference syntax (blocker for 3.2)
Blaise at blaise.ru
Blaise at blaise.ru
Sat Dec 7 22:46:36 CET 2019
On 07.12.2019 21:39, Sven Barth wrote:
> I'm arguing that there is no builtin way to *access* the parameters passed in such a way.
You are arguing that /now/, but it is not what you said earlier. You said, verbatim:
> one can not access VarArgs parameters inside a Delphi function (without resorting to assembly)
Like I said, this is factually incorrect.
> there are hacks
A custom va_list implementation, fully conforming to the ABI and particularities of the compiler, is not necessarily a hack. (In the sense that is not of questionable design, implementation quality, and maintainability.)
> but this is not guaranteed to work on every platform.
Where did that requirement of "every platform" suddenly come from? One needs to roll out their own va_list implementations only for the platforms A) that he targets, and B) on which the stock implementation is not provided.
> an anonymous function with varargs modifier will not be allowed anyway
Right. FTR, my patch will eventually allow exactly that, and so does DCC already.
Or are you still not aware of the latter? For the fourth time: VARARGS is allowed and works with DCC, on both sides, without BASM or ugly hacks, on more than one platform :) Some of them even have stock implementations of va_list, FPC should take a hint.
> You need procvar specific functionality, because you need to restrict the available modifiers to those available for procvars.
And if I use the procvardef parser, I, like Jonas, would need to prohibit "OF OBJECT" and "IS NESTED". One extra work for another.
> You extend tprocvardef.create with a doregister parameter
> you convert the procvar to an interface method and then free the no longer required procvardef.
Right. The unnecessary work I am currently avoiding.
Since I have not yet submitted that part for review, let us avoid premature pointless discussion.
> you're parsing something that's in essence a fancy procedure/method variable which is completely independant of it being implemented by an interface
You do realise that method reference types "being <...> interface[s]" is pretty much a part of the specification?
type M = reference to procedure (const N: Integer);
type C = class (TInterfacedObject, M)
procedure Invoke(const N: Integer); virtual; abstract;
More information about the fpc-devel