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

(as a side note, few people can associate
document numbers with their own paper... I guess)

> 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.

That, is my motivation -- to reduce engineers'
time wasted on this issue.

> 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).

According to an EWG discussion in wg21,
there is no consensus for supporting C's block
lifetime semantics.

Given the discussion, I found that the main
problem of this paper is that it failed to
explain the semantics of compound literals
implemented as C++ extensions in todays'
compilers in great details. EWG, Clang, and
GCC are all different in certain contexts.

>
>

> 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>){};

I'm aware of that, and I find it being
accidental rather than something
we should build upon.

There are people interested in adding
`defer` to C http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2589.pdf
I'm excited by this effort and would like
to see a paper coming to this group.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsBzBAEBCAAGBQJgnCM6ACEJELvdJpAo+x+4FiEEq579O5Q2C/mSvp73u90m
kCj7H7hq9gf/e6ADnhtbiUmCUbYdQyA3heNk46XtXHyN+hPOE071NmGxOqqQ
FwU3kupCO/uCKrQoi5lJD8Vq21QmLAR4AUtReSgpGtKtt379ybb7f/pVGNQ/
bDH4cOHKyDBeHyzYMXtvWQgV9YO5AenItNsGLLKPxaSopjNr6PNoV9XLLvBG
7ShJUiknG7cllflmCDdVQE2i0qm5l11ia0EsjvSsuwRIgnkPNX7cu7wIC8Iy
0cyks9Lq3dMc6X35MvdERPjksBt4yjFR60Cl6SVeB0ohWH3PzsrIPx/7GjZ8
2T7Z/OzO0ccM04D+x9s5Mn84SXNppFCXyNo4SwShbM6FK0BLf9l6ZA==
=uu9g
-----END PGP SIGNATURE-----


-----------------------b472cb7823f9a2d90a88ae94f4ef5e58--