On Tue, May 11, 2021 at 6:11 PM Charlie Barto via Liaison <
liaison_at_[hidden]> wrote:

> This email brought to you by fixing an ffmpeg wrapper that wouldn’t
> compile on MSVC because we don’t implement compound literals in c++ mode.
>
>
>
> I’ve written a decent amount of wrapper code and/or Vulkan code that would
> have found compound literal support desirable. And from the looks of it the
> main problems with the proposal were that it didn’t follow the C lifetime
> semantics and that it didn’t really motivate itself (especially without the
> C lifetime semantics).
>
>
>
> I might be willing to help with motivation (like helping write it) if
> there’s still sufficient interest in continuing that paper. I suspect
> wording for the C lifetime version will be challenging. I can also see some
> of the safety issues as being challenges.
>

This would change the semantics of the compound-literals-in-C++ extension
already provided by more or less all major C++ implementations other than
MSVC, in which (T){x, y} is semantically identical to T{x, y}. Also, I
expect the C++ committee would not like a proposal in which the subtle
distinction between these two syntaxes has such a drastic difference in
semantics. As a result, I think following the C block scope semantics has
near-zero chance of success in WG21.

I think an approach following the C++ full-expression semantics, and
thereby standardizing existing practice, is much more likely to gain
traction. I suppose the question is whether that's sufficiently useful for
our purposes -- it would mean that code in the common subset of C and C++
cannot rely on compound literals living beyond the end of the statement (or
being lvalues).


> Note: my offer to help is only tenuously related to my job and employer, I
> won’t really be able to dedicate “work time” toward this effort.
>
>
>
>
>
> Sidenote:
>
>
>
> It occurs to me that C style compound literals may allow a real “defer”
> construct: consider
>
>
>
> template<void (*fn)()>
>
> struct defer {
>
> ~defer() {
>
> fn();
>
> }
>
> };
>
>
>
> right now we need to use this as:
>
>
>
> defer<some_function_call> _;
>
>
>
> (we need to name the local variable)
>
>
>
> with C style compound literals:
>
>
>
> (defer<some_function_call>){};
>
>
>
>
>
> … it’s not super motivating since that syntax is …. not ideal, and because
> the “real” solution is probably to just use some kind of reflection.
>
> Also you can kind of do it today with macro token pasting and
> source_location or __LINE__ and __FUNCTION__. Still, it’s neat.
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/05/0540.php
>