wide function pointer type

[Martin Uecker]

Am Sonntag, den 10.10.2021, 10:49 -0700 schrieb Daniel Colascione:
> On October 10, 2021 10:44:32 Martin Uecker via Libffi-discuss 
> <libffi-discuss@sourceware.org> wrote:
> 
> > Am Sonntag, den 10.10.2021, 10:01 -0700 schrieb Kaz Kylheku (libffi):
> > > On 2021-10-10 04:32, Martin Uecker via Libffi-discuss wrote:
> > > > Hi all,
> > > > 
> > > > I will propose a wide function pointer type (actually
> > > > a wide function type) to WG14 for C23 as a common
> > > > type for callbacks, closures, which now require an
> > > > additional void pointer argument in C APIs. This
> > > > is intended to be compatible with ABIs with now
> > > > use a static chain register.
> > > 
> > > Opposed. There is nothing wrong with separate arguments
> > > for function pointer and context.
> > 
> > Noted.  Your argument sbelow all boil down to the point
> > that there are cases where it might not be the ideal
> > choice. But nobody forces anyone to use it.
> "I like it" is not by itself a rationale for including something in a core 
> language standard. This is not something that should be in C. Why, 
> precisely, can't you just define a struct with two fields and make that 
> your closure type?

Sure. There are at least five reasons:

 - one now does has to do it manually which is
inconvenient because it has to be done for each type,
although this a common pattern which is trivial
to automate. 

- APIs are often unsafe because they have to use
void pointer to be generic. When the void pointer
can be packaged into the wide pointer this problem
goes away.

- APIs are often different for no good reason.
Having a standard approach would make this more
canonical, hence simpler and less error prone,
and also more compatible - requiring less adapter
code.

- There are APIs where a pointer to a
function is expected but there is no data pointer.
Then other languages have a problem interfacing
with such APIs.   (or why does libffi generate
trampolines?)

- Finally, C might get lambda expressions
which are far more useful with such a pointer type.
(for nested function you could avoid executable
stack).


All five are good reasons to put a standard
approach in the core language in my opinion.


But I am actually not interested in this discussion
and do not have time for it.

I am more interested in constructive technical
feedback. 

Martin