Ville,

on Mon, 27 Sep 2021 10:27:50 +0300 you (Ville Voutilainen
<ville.voutilainen_at_[hidden]>) wrote:

> On Mon, 27 Sept 2021 at 10:03, Jₑₙₛ Gustedt <jens.gustedt_at_[hidden]>
> wrote:
> > > Since this "lambda" isn't callable by other parts of the program,
> > > this looks like something that C should be able to express, too.
> > > It's less consistent with the current lambda proposals in C due to
> > > those not having all the bells and whistles, but, oh well.
> >
> > This triggers my interest ;-)
> >
> > First, I think that using lambas as proposed in the draft seems
> > really a smart idea. This is a good step forward.
> >
> > The missing thing that you are refering to is initialization of
> > reference/lvalue captures?
>
> Yes. C++ lambdas have init-captures, I'm unaware of any attempt for C
> lambdas to have them.

you are partially mistaken, the C proposal has init-captures, but only
for value captures, not for lvalue captures. We don't have an
equivalent of C++'s reference feature, so we can't do the latter.

> > AFAICS this is only necessary for the very specific feature of
> > naming a return value. So this would not be in conflict with the
> > lambda approach for C, where I tried just to be very careful not to
> > introduce aliasing to existing objects. Any "capture-like" syntax
> > that just gives a name and type to the return value/object, even as
> > the proposed `&name=return` looks good to me.
>
> It's more than just naming a return value; an init-capture allows you
> to perform an arbitrary
> transformation for how a capture is initialized. With it, you could
> dig inside a smart pointer and initialize
> a capture from the smart pointer's internal data even if the smart
> pointer itself isn't copyable.
> As an example, I can capture an int out of a smart pointer to int,
> https://wandbox.org/permlink/iWerXYkCC9SwD81f
> or as a more barebones example, I can capture an int out of a pointer
> to int, https://wandbox.org/permlink/c9fP2pr6nCnfAmsQ

Smart pointers are obviously out of the scope of C, but you could do
similar things with an init-capture to a pointer-typed capture (that
then would be `const` but not pointer-target-`const`).

> So, with this lambda-like precondition/postcondition facility, I can
> traverse object graphs in the 'init-capture',
> and save whatever values I like for later comparison by a
> postcondition expression, for instance.

So you could do the same/equivalent for C, just that you would only
have access to the traversal throught a pointer, not a C++ reference.

> I can express a postcondition that says "the function returns
> something that is less than the value the argument
> pointed to at the point of call", and the function can change what the
> argument pointed to without changing
> what the postcondition means. Meaning that I can have a postcondition
> expressed in terms of what the incoming
> values were even if the incoming values are later indirectly written
> to by the function.
>
> The whole reason for the const-restriction in postconditions of the
> current proposal is because of this, allowing writes would prevent
> expressing postconditions in the terms of the incoming values, because
> the function could change the values
> and the original incoming values would be lost. Saving them has a
> cost, and depending on the parameter types,
> doesn't work the same way for all types (C++ has move-only types that
> can't be copied, and you can't have a 'saved'
> value of a move-only type that's available both for the postcondition
> and for the function itself). Being able to
> init-capture the original value solves this problem. I can even "copy"
> an incoming move-only value like a unique_ptr
> by doing an init-capture of a new allocation created from the object
> pointed-to. I can just copy the underlying int.
> I can do whatever I like with an init-capture, and I can decide
> whether I capture by value, by reference, or by
> arbitrary transformation. This removes all limitations of what
> postconditions I can write and what the function
> is allowed to do to/via/through the parameter.

I think I understood that. I still think the main issue for interface
compatibility here would be the possibility to name the return
value. This is obviously something that you'd want for
post-conditions.

This is a missing feature in both languages, so maybe that could be
attacked directly.


Thanks
Jₑₙₛ

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::