http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4074.pdf

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4131.html

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4094.html

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4029.pdf

See unpublished paper N3452.

Portland 2012:

Straw polls:

return as in the proposal: SF: 3 F: 2 N: 2 A: 4 SA: 5

arguments as in the proposal: SF: 2 F: 2 N: 1 A: 4 SA: 7

= {} vs. {} as in the proposal: SF: 2 F: 0 N: 4 A: 4 SA: 5

The author interprets these as dead, and does not plan to pursue this further.

Sutter reopened the issue in [c++std-ext-14770], Lavavej and Voutilainen reiterated reasons why the proposal was originally rejected. Sutter has indicated that he wishes to create a revised paper focusing on the return part, this issue is for him to reference in the paper.

Hinnant pointed to his response writeup in [c++std-ext-14883], and it was noted that [c++std-lib-34985] is also related, and mentions a paper by Krügler that would solve some of the library issues without introducing the problems Hinnant writes about.

Dimov presented a different incarnation of some of these problems in [c++std-lib-36408] "map<K,V>::emplace and explicit V constructors", and Krügler pointed out his paper solves that issue as well.

The Library issue related to Dimov's issue report is LWG 2397

Discussed in Rapperswil 2014.

Vandevoorde pointed out that he doesn't like returning an integer value and having that automatically convert to a vector. Vandevoorde said that the same arguments apply as with Josuttis's paper, because there's a difference between conversions and initializations, and that there are differences with auto. Sutter and Stroustrup suggested that the function author should know the return type of their function, so the argument that the return type isn't known doesn't hold water.

Voutilainen pointed out that there is a difference between initializations of local variables and returns, since the former allows deciding whether conversions are allowed, whereas this proposal would remove the ability to make that decision for returns.

Dennett thought that the diagnostic is not problematic because the worst kind of diagnostic is a missing diagnostic, especially ones that change a compiler error to a runtime error. Dennett asked what happens if a function vector f() {return {42};} has new semantics, and Vandevoorde warned that it seems like this would be a breaking change.

Voutilainen emphasized that this will turn compile-time errors into run-time errors, and warned about doing that lightly. Vandevoorde thought that this proposal makes code easier to write but not easier to read. Stroustrup disagreed with that point.

Voutilainen emphasized that in his opinion ownership transfer needs to stand out. Bos asked whether a compromise like return auto(2); would work. Dennett reported he has a wrap_unique() in internal use that solves the problem of having to repeat the type. Vandevoorde explained the difference between returning a value and returning a value constructed (possibly via conversion) from another value. Naumann pointed out the problems in refactoring code that returns a value but is changed to return eg. a vector, the status quo currently diagnoses those, but with this proposal, that wouldn't be the case.

Straw polls:

Proposal:

SF: 2 F: 5 N: 4 A: 3 SA: 5

Like the proposal, but just when braces are used:

SF: 3 F: 8 N: 3 A: 0 SA: 4

Sutter continued revising the proposal aiming for a solution that kicks in when braces are used. The current expectation is that the discussion will continue in Urbana, and there will be more papers related to this area.

N4094 contains a response to this proposal by Hinnant and Voutilainen.

Discussed in Urbana. EWG decided to reject the proposal due to problems it causes for the technique for transparently-explicit constructors and the problems pointed out in the response papers.