C++ Logo

liaison

Advanced search

Re: [wg14/wg21 liaison] a common C/C++ core specification

From: Uecker, Martin <Martin.Uecker_at_[hidden]>
Date: Tue, 10 Mar 2020 20:27:35 +0000
Am Dienstag, den 10.03.2020, 20:59 +0100 schrieb Jens Gustedt via Liaison:
> on Tue, 10 Mar 2020 19:49:01 +0000 you ("Uecker, Martin via Liaison"
> <liaison_at_[hidden].org>) wrote:
>
> > Am Dienstag, den 10.03.2020, 20:16 +0100 schrieb Florian Weimer via
> > Liaison:
> > > Do you think there is a mechanical way to capture types and values
> > > so that each macro argument is expanded exactly once? Perhaps using
> > > lambdas?
> >
> > You can do this today using popular extensions:
> >
> > #define FOO(x) ({ __auto_type __x = (x); _Generic(__x, ... ); })
>
> Yes, with lambdas and "auto" we just would have a standardized version
> of that as
>
> #define FOO(x) [](auto __x){ return _Generic(__x, ... ); }(x)
>
> which has several advantages: a clearly marked `return` statement and
> encapsulation against inadvertedly reading state from the surrounding
> code.

I like the explicit return.

I am less sure about the [] syntax and the fact that
you can not simply access variables from enclosing
scopes or only with restrictions. The power of lambdas
comes exactly from accessing the variables of the
enclosing state. Making this harder than necessary
may not be ideal.

type inference for parameters for lambdas is
interesting, but somehow does not feel right.
It can't work for regular functions, so it is
another special rule that makes the language
more complicated.

I like simplicity. As a C person, I would simply
lift existing syntactical restrictions and allow
nested functions and lambdas using the syntax
of compound literals:

int foo(int x)
{
 int bar(int y) { return x + y; }

 int (*fp)(int) = (int(int x)){ return x + y; }
}

We may need a new type for pointers to
lambdas/nested functions.

Best,
Martin

Received on 2020-03-10 15:30:26