One variable init form to rule them all, via mandatory elision

[Mark A. Gibbs]

Scott Meyers's recent post on initialization has brought up a long-time pet peeve of mine: defining new objects. My beef is not that there are multiple ways to do it, it's that there is no single way that Just Works(tm) everywhere, and does the right thing, with robust syntax. The "Almost Always auto" style proposed by Herb Sutter comes close, but there are some gotchas with it. It seems to me there is a very simple way to remove those gotchas, but I've never seen it proposed.

I'm going to start by explaining why I've chosen AAA as the basis for this proposal. If you're already down with AAA, you can skip to the tl;dr at the bottom.

Meyers enumerates 4 different ways to declare and initialize a new variable. With "type" being either a type name or "auto", and "val" being a lvalue of type "type", they are:

type v = val;    // #1
type v(val);     // #2
type v = {val};  // #3
type v{val};     // #4

Let's just write #2 off immediately, because of the most vexing arse - pardon the typo.

#4 is deeply problematic, because the behaviour has changed between C++14 and C++17. So let's drop that, too.

#3 has different behaviour whether "type" is an actually a type name or "auto". So let's put that aside for the moment.

That leaves us with:

type v = val;

Which, using int, can be either:

int v = 0;   // (a)
auto v = 0;  // (b)

(a) is fine, but somewhat redundant and occasionally dangerous - if the type isn't the same on the left and right, you may end up with a conversion that may be expensive, or may lose information.

So that brings us down to (b), and the whole train of logic above turns to be a reiteration of the "Almost Always auto" (AAA) argument. For those who aren't familiar, the AAA argument is that variables should always be defined using the pattern:

auto v = /* initial value */;

The benefits of this include:

• No unexpected conversions.
• Impossible to have an uninitialized variable.
• Consistent with other modern constructs, easy to read, hard to misunderstand.

Generally speaking, if you already have a value and you just want to initialize a copy or move it, you can just use:
auto v = val;

But if you don't have a value, or if you do but you want to be explicit about the type, you can use:

auto v = type{val};  // or any other constructor arguments, including none

In cases where you REALLY want that type, and you don't care if you're narrowing - or when you really want to use a specific constructor, and the arguments are not just a initializer list of values - then you can use:

auto v = type(val);  // Most vexing parse not a problem

The C++ standard allows compilers to elide the copy construction and move assignment (really a move construction) to a single construction... even though it may produce different observable behaviour. It is (AFAIK) the only optimization the standard allows that can do that. That means that:

auto v = val;        // a single copy construction
auto v = type{val};  // can be a single copy construction
auto v = type(val);  // can be a single copy construction

And all modern compilers worth mentioning do the elision.

This also means that:

auto v = type{};  // can be just default construction

So it seems we have a winner for the one, true variable definition format.

But not so fast....

As Meyers noted, this pattern has one case where it doesn't work: types that are non-copyable and non-movable.

The reasoning that even though the standard allows the move (or copy) construction to be elided, it doesn't require it. And compilers have to pretend they're still going to do it, even though they're not. That is why this won't compile:

auto v = std::atomic<int>{};

But this restriction is silly and pedantic. There is no way the line above can reasonably be interpreted as anything else but "I want v to be a default constructed std::atomic<int>".

And if anyone wants to try to argue that someone might actually want to do a default construction then move construction when writing that, I call shenanigans. Because that's not what they're going to get - in any compiler of note - and the standard blesses this.

Put yourself in the shoes of a C++ newbie who's just learning the language. Wanting to explore constructors and destructors, ze writes this simple class:

struct foo
{
  foo() { std::cout << "constructing foo\n"; }
  ~foo() { std::cout << "destructing foo\n"; }
 
  foo(foo const&) = delete;
  foo& operator=(foo const&) = delete;
 
  foo(foo&&) = delete;
  foo& operator=(foo&&) = delete;
};

int main()
{
  foo f;
}

// Output:
// constructing foo
// destructing foo

So far, no problems. But then ze decides to try using the AAA pattern to define "f":

int main()
{
  auto f = foo{};
}

This fails to compile, and the compiler explains that it's because "foo" is non-movable and non-copyable. "Ah!" says our newbie, thinking ze's learned something useful. "Well this makes perfect sense! I suppose I'm doing a construction on the right, and then an assignment to the variable on the left. Well played C++. Well, now let me experiment to see which special member function gets used to do the transfer from the right side to the left."

So now ze writes this:

struct foo
{
  foo() { std::cout << "constructing foo\n"; }
  ~foo() { std::cout << "destructing foo\n"; }
 
  foo(foo const&) { std::cout << "copy constructing foo\n"; }
  foo& operator=(foo const&) { std::cout << "copy assigning foo\n"; return *this; }
 
  foo(foo&&) { std::cout << "move constructing foo\n"; }
  foo& operator=(foo&&) { std::cout << "move assigning foo\n"; return *this; }
};

int main()
{
  auto f = foo{};
}

And how is our diligent newbie rewarded for zes experimentation? With this:

// Output:
// constructing foo
// destructing foo

"What... what the flagnar? None of the special functions are used? How can this be? The compiler said I needed to add them! Why would the compiler insist on having them if it never uses them! Is this a compiler bug? No? This absurdity is standard behaviour? To hell with C++. Bring me a Ruby book."

The cause of all this confusion is the requirement that statements of the form "type v = type{/*params*/};" or "auto v = type{/*params*/};" (or with parentheses rather than braces in both cases) MUST be interpreted as a construction on the right, then another (move/copy) construction to the variable on the left (and then a destruction of the temporary)... even though at the same time compilers are free to elide it all down to a single construction.

What if, instead, statements of the form "type v = type{/*params*/};" or "auto v = type{/*params*/};" were interpreted as a single construction, of the variable "v" which has type "type"?

This would only apply to any statement of the form "XXX varname = YYY{/*arguments*/};" or "XXX varname = YYY(/*arguments*/);", provided that "XXX" and "YYY" deduce to the same type (which is obviously true if "XXX" is "auto"). It would not apply to, for example "float v = int{42};". It would apply to "using number = int; number v = int{42};". It would be exactly equivalent to "YYY varname{/*arguments*/};" or "YYY varname(/*arguments*/);" (except, in the latter case, it will not be subject to the most vexing parse when that applies).

For backwards compatibility, when "type" is movable or copyable, compilers still have the leeway to implement it as a construction then a move construction. I don't know of any compilers that actually do that, but, just in case. That means that the meaning of any code that compiles today will not change. The only thing that will change is the code that currently doesn't compile today - when "type" is non-movable and non-copyable - will now compile (and obviously will only be interpreted as a single construction, because it can't possibly be interpreted as a construction then move/copy). I can't imagine this adds any complexity to compilers, and in fact removes a completely unnecessary check that they do today (the check for move/copy constructability).

The result is we would get a way to define initialized variables that works consistently in every case, is fairly robust against mistakes and typos, and has obvious and logical semantics:

int i = 0;        // an int
int i = int{0};   // identical to first line (does narrowing check)
int i = int(0);   // identical to first line (no narrowing check)
auto i = 0;       // identical to first line
auto i = int{0};  // identical to first line (does narrowing check)
auto i = int(0);  // identical to first line (no narrowing check)

int i = int{};   // default construction
auto i = int{};  // identical to above

// Same semantics with types with UDLs
std::string s{"foo"};         // std::string
auto s = std::string{"foo"};  // identical to first line
auto s = "foo"s;              // using a UDL, (effectively) identical

std::string s = std::string{};  // default construction
auto s = std::string{};         // identical to above

// Non-copyable, non-movable types, too
std::atomic<int> i = 0;                     // an std::atomic<int>
std::atomic<int> i = std::atomic<int>{0};   // identical to first line
std::atomic<int> i = std::atomic<int>(0);   // identical to first line
auto i = std::atomic<int>{0};               // identical to first line
auto i = std::atomic<int>(0);               // identical to first line

std::atomic<int> i = std::atomic<int>{};   // default construction
auto i = std::atomic<int>{};               // identical to above

auto a = std::atomic<int>{42};
std::atomic<int> b = a; // won't compile (non-copyable)
auto b = a;             // same
std::atomic<int> b = std::move(a);  // won't compile (non-movable)
auto b = std::move(a);              // same

auto func() -> std::atomic<int>;
std::atomic<int> b = func();  // won't compile (non-movable)
auto b = func();              // same
std::atomic<int> b = std::atomic<int>{func()};  // Won't compile, because the
                                                // construction on the right
                                                // is invalid. Would work if
                                                // func() return an int.
auto b = std::atomic<int>{func()};              // same

// Familiar behaviours (that already assume elision) are unchanged
std::vector<int> v = std::vector<int>{};  // default construction
auto v = std::vector<int>{};              // same

std::vector<int> v = std::vector<int>{2, 3};  // list construction { 2, 3 }
auto v = std::vector<int>{2, 3};              // same

std::vector<int> v = std::vector<int>(2, 3);  // constructs vector { 3, 3 }
auto v = std::vector<int>(2, 3);              // same

// If you stick with the policy to always use auto on the left,
// even the initializer list issue that gnaws on Meyers becomes clear:
auto i = 0;       // i is int (what else would it be?)
auto i = {0};     // i is initializer_list<int> (what else would it be?)
auto i = int{0};  // i is int (what else would it be?)

// It only gets weird if you do:
int i = 0;       // Clear
int i = {0};     // What? You want to assign an initializer_list<int> to an int?
                 // Well, I guess it works if there's only one int in the list...
int i = int{0};  // Clear, but redundant
// Plus all the headaches mentioned in N4014
// But that's a style issue.

So here's the tl;dr bullet point version:

• The AAA style is awesome.
• It has only one gotcha - it fails for non-copyable, non-movable types.
• The language already allows the move/copy to be elided for copyable/moveable types, and all compilers do that. So the move/copy requirement is unnecessary. Let's ditch it.
• Let all statements of the form "XXX v = YYY{/*args*/};" where "XXX" resolves to the same type as "YYY" (which includes when "XXX" is "auto", obviously), be exactly equivalent to "YYY v{/*args*/};".
• Let all statements of the form "XXX v = YYY(/*args*/);" where "XXX" resolves to the same type as "YYY" (which includes when "XXX" is "auto", obviously), be exactly equivalent to "YYY v(/*args*/);"... ignoring the most vexing parse.
• For the sake of backward compatibility, give compilers the freedom - when the type is copyable and/or movable - to interpret "XXX v = YYY{/*args*/};" or "XXX v = YYY(/*args*/);" as a construction followed by a move/copy construction. (None do, and none likely will, but just in case. This behaviour could be deprecated, I suppose.)
• In other words, the currently standard-blessed optimization of eliding the unnecessary temporary construction and move would become not an optimization, but "the way it's done". Not eliding would become a "tolerated pessimization".
• Won't change the meaning of any old code. Will make code that currently won't compile - for silly, pedantic reasons - functional.
  

[Ville Voutilainen]

On 10 September 2015 at 02:27, Mark A. Gibbs

<indi.in....@gmail.com> wrote:
> But not so fast....
> As Meyers noted, this pattern has one case where it doesn't work: types that
> are non-copyable and non-movable.
> The reasoning that even though the standard allows the move (or copy)
> construction to be elided, it doesn't require it. And compilers have to
> pretend they're still going to do it, even though they're not. That is why
> this won't compile:
> auto v = std::atomic<int>{};
> But this restriction is silly and pedantic. There is no way the line above
> can reasonably be interpreted as anything else but "I want v to be a default
> constructed std::atomic<int>".

The EWG disagreed:
http://cplusplus.github.io/EWG/ewg-closed.html#124

[Mark A. Gibbs]

 
That doesn't seem to be the same point.

// I am talking about, for example. either of
tuple<int> t = tuple<int>{0};
auto       t = tuple<int>{0};
// I am not talking about:
tuple<int> t = {0};
// Which is what N4014 was about

[Ville Voutilainen]

On 10 September 2015 at 02:48, Mark A. Gibbs

The point is that EWG disagreed with the part which you claimed cannot be
reasonably be interpreted as anything else but default-constructing. We didn't
want to remove the semantic check for copy/move even for the case where the
copy/move is elided. That semantic check is what makes your example
be rejected.

[Mark A. Gibbs]

On Wednesday, 9 September 2015 20:26:36 UTC-4, Ville Voutilainen wrote:

The point is that EWG disagreed with the part which you claimed cannot be
reasonably be interpreted as anything else but default-constructing. We didn't
want to remove the semantic check for copy/move even for the case where the
copy/move is elided. That semantic check is what makes your example
be rejected.

It still doesn't look like the same point to me. The item you pointed to appears to be about explicit versus non-explicit construction, not copyability (or movability). I'm not talking about "type t = {};", I'm talking about "type t = type{};". What I'm proposing has absolutely no impact on explicitness, nor is it impacted by it. If there is actually an argument relevant to copy/movability, I'd like to hear it.

I have never seen anyone, anywhere, suggest that using the construct "auto x = T{};" (or "T x = T{};") is a way to test for copyability (or movability) in generic code. I have never seen anyone say: "I write 'T x{...};' in generic code when I only require that constructor signature, and I write 'auto x = T{...};' to additionally constrain for copy and/or movability." In fact, I would say anyone who did that was just creating maintenance headaches. By contrast, I have seen several beginners surprised and annoyed when it doesn't work for some types, like atomics, mutexes, locks, and other RAII-implementing types. (Even Meyers highlights this frustration, as his "Question 2".)

When someone wants to require copy/movability there are plenty of other, less obtuse, ways to do it:

auto t2 = t1
auto t2 = T{t1};
T t2{t1};
T t2 = t1;
T t2 = T{t1};
// etc., and of course traits, and eventually concepts

[David Krauss]

Let me start by saying, I hate the looseness of the elision rule too too. If I had more time, I’d be proposing to require elision where it’s de-facto standard.

On 2015–09–10, at 7:27 AM, Mark A. Gibbs <indi.in....@gmail.com> wrote:

Scott Meyers's recent post

http://scottmeyers.blogspot.com/2015/09/thoughts-on-vagaries-of-c-initialization.html

on initialization has brought up a long-time pet peeve of mine: defining new objects. My beef is not that there are multiple ways to do it, it's that there is no single way that Just Works(tm) everywhere, and does the right thing, with robust syntax. The "Almost Always auto" style proposed by Herb Sutter comes close, but there are some gotchas with it. It seems to me there is a very simple way to remove those gotchas, but I've never seen it proposed.

Elision hasn’t been mentioned yet :( .

No syntax Just Works™ because classes really do different things. Statements should not have unbounded meaning.

I'm going to start by explaining why I've chosen AAA as the basis for this proposal. If you're already down with AAA, you can skip to the tl;dr at the bottom.

Meyers enumerates 4 different ways to declare and initialize a new variable. With "type" being either a type name or "auto", and "val" being a lvalue of type "type", they are:

type v = val;    // #1
type v(val);     // #2
type v = {val};  // #3
type v{val};     // #4

Let's just write #2 off immediately, because of the most vexing arse - pardon the typo.

No, MVP happens only with an empty argument list. Otherwise #2 looks like a function call, so it’s appropriate for constructors that behave more like functions and less like aggregate initialization. As a special case, aggregating no values is the same as calling a nullary function. Adding values/parameters, the concepts diverge.

#2 is sometimes required to disambiguate an initializer list (aggregate-like) from a parameter list (function-like).

#4 is deeply problematic, because the behaviour has changed between C++14 and C++17. So let's drop that, too.

Huh? What change? I think that if the committee agreed with that consequence, they wouldn’t have changed it.

So now you’re saying that there should always be an equals sign, dropping all direct-initialization. This is drifting far away from the specific topic of elision.

An equals sign is reminiscent of mathematical values: It joins two mathematical objects and asserts their equality. I prefer to avoid it for things that don’t have values.

Ah, now Sutter’s article has loaded on my slow connection. C++17 deprecates treating a braced-init-list as an initializer_list value when there’s no equals sign. This makes sense, because initializer_list is definitely forming a new value there (although it doesn’t always behave with value semantics).

#3 has different behaviour whether "type" is an actually a type name or "auto". So let's put that aside for the moment.

That leaves us with:

type v = val;

… which, for nontrivial expressions that we encounter most often, suggests that val is a factory function call.

Which, using int, can be either:

When discussing elision, int, being trivially copyable, is not a good default illustrative type.

int v = 0;   // (a)
auto v = 0;  // (b)

(a) is fine, but somewhat redundant and occasionally dangerous - if the type isn't the same on the left and right, you may end up with a conversion that may be expensive, or may lose information.

Hence almost always auto. A lot of more-experienced programmers aren’t 100% on that bandwagon.

So that brings us down to (b), and the whole train of logic above turns to be a reiteration of the "Almost Always auto" (AAA) argument. For those who aren't familiar, the AAA argument is that variables should always be defined using the pattern:

auto v = /* initial value */;

The benefits of this include:

• No unexpected conversions.

Some sort of conversion is needed to obtain a value from an expression template object, so this isn’t axiomatic.

• Impossible to have an uninitialized variable.
• Consistent with other modern constructs, easy to read, hard to misunderstand.

If you extend the meaning of #1 to include #2, #3, and #4, won’t that increase the potential for misunderstanding?

Syntax has no inherent value by itself; it just stands for semantic concepts. If you think that #1 ain’t broke, why fix it? (Still no mention of elision in this post.)

Generally speaking, if you already have a value and you just want to initialize a copy or move it, you can just use:
auto v = val;

But if you don't have a value, or if you do but you want to be explicit about the type, you can use:

auto v = type{val};  // or any other constructor arguments, including none

Or a factory function, which furthermore needs to worry about the return statement.

(snip)

But not so fast....

As Meyers noted, this pattern has one case where it doesn't work: types that are non-copyable and non-movable.

Such types tend to lack value semantics. Not a coincidence that the equals sign becomes undefined.

The reasoning that even though the standard allows the move (or copy) construction to be elided, it doesn't require it. And compilers have to pretend they're still going to do it, even though they're not. That is why this won't compile:

auto v = std::atomic<int>{};

But this restriction is silly and pedantic. There is no way the line above can reasonably be interpreted as anything else but "I want v to be a default constructed std::atomic<int>”.

No, atomic variables have special synchronization requirements. They’re a refinement of volatile. I look at that statement and I see two distinct variables joined by an equals sign. Take away the object-ness of std::atomic and it becomes conceptually vague.

And if anyone wants to try to argue that someone might actually want to do a default construction then move construction when writing that, I call shenanigans. Because that's not what they're going to get - in any compiler of note - and the standard blesses this.

They don’t want that, and they won’t get it, because it’s nonsense. This argument is a logical fallacy of false supposition. The language is correct to prevent having two objects in that statement. Yet it would be incorrect to allow the statement to work with one object, because std::atomic is a type where one object emphatically never represents two values.

Put yourself in the shoes of a C++ newbie who's just learning the language. Wanting to explore constructors and destructors, ze writes this simple class:

Writing random code from no semantic premises, and guessing at meaning from the perspective of a naive person, is not part of language design.

The solution to this problem is that newbies shouldn’t write non-value-semantic classes. Deleting the move constructor is a red flag, indicating that programming assistance is needed.

(Snip — the newbie did not seek help. This seldom ends well in any language.)

Here’s my take:

The problem with copy-initialization is that it’s sometimes used with no equals sign, such as in passing, returning, and throwing. The language treats it as a conservative choice when it’s impossible to guarantee that two values are the same object. However, this guarantee can always be made when passing, throwing, or returning a prvalue. The language/ABI interface is interfering with the programmer’s stated intentions.

But the elision problem isn’t limited to copy-initialization at all. Consider:

struct s {

    explicit s() = default;

    s( s && ) = delete;

};

s f() { return s{}; } // No equals sign nor conversion, but still copy-initialization. Excessive language conservatism.

s q{ f() }; // Direct-initalization can also be ill-formed due to lack of move constructor.

I posit that the above snippet should work. It goes far enough out of its way to avoid suggesting value semantics, and all implementations can guarantee that the move constructor isn’t needed.

Unfortunately, I don’t have time right now for deeper discussion, much less to write a proposal.

And BTW, I agree with Ville’s that your proposal is closely aligned with N4014. They both result from blaming the problems of non-value-semantic classes on the equals sign instead of the class. The equals sign is a safety mechanism to protect you from thorny types; getting rid of its significance will only open the gates to more nastiness.

[David Krauss]

On 2015–09–10, at 10:53 AM, David Krauss <pot...@gmail.com> wrote:

No, MVP happens only with an empty argument list.

inb4 the pedants, with int q( int() ), there’s still an empty list in the inner expression/declarator, and disambiguation is accomplished by changing it, specifically, to braces: int q( int{} ).

[Ville Voutilainen]

On 10 September 2015 at 05:53, David Krauss <pot...@gmail.com> wrote:
> #4 is deeply problematic, because the behaviour has changed between C++14
> and C++17. So let's drop that, too.
>
>
> Huh? What change? I think that if the committee agreed with that
> consequence, they wouldn’t have changed it.

That's N3922..

> So now you’re saying that there should always be an equals sign, dropping
> all direct-initialization. This is drifting far away from the specific topic
> of elision.
> An equals sign is reminiscent of mathematical values: It joins two
> mathematical objects and asserts their equality. I prefer to avoid it for
> things that don’t have values.
> Ah, now Sutter’s article has loaded on my slow connection. C++17 deprecates
> treating a braced-init-list as an initializer_list value when there’s no
> equals sign. This makes sense, because initializer_list is definitely
> forming a new value there (although it doesn’t always behave with value
> semantics).

..but there's no deprecation, and N3922 applies as a Defect Report all the way
back to C++11, and gcc implements it in its C++11 mode. MSVC doesn't
have conformance modes, but they also already ship with the N3922
change included.

Then again, even with N3922,

auto x{atomic<int>{}};

still doesn't work because even there, a semantic check for copy/move
is performed.

[David Krauss]

> On 2015–09–10, at 1:14 PM, Ville Voutilainen <ville.vo...@gmail.com> wrote:
>
> ..but there's no deprecation, and N3922 applies as a Defect Report all the way
> back to C++11, and gcc implements it in its C++11 mode. MSVC doesn't
> have conformance modes, but they also already ship with the N3922
> change included.

OK, retroactive elimination and wiping-out. Stronger than deprecation.

> Then again, even with N3922,
>
> auto x{atomic<int>{}};
>
> still doesn't work because even there, a semantic check for copy/move
> is performed.

Right. I don’t favor that stylistically, but I’ll take it if it can’t be surgically separated from non-movable factory functions which are a hole in the language.

[Matthew Fioravante]

On Thursday, September 10, 2015 at 1:24:56 AM UTC-4, David Krauss wrote:

>
> still doesn't work because even there, a semantic check for copy/move
> is performed.

Right. I don’t favor that stylistically, but I’ll take it if it can’t be surgically separated from non-movable factory functions which are a hole in the language.

I would love to have factory functions for non-movable types. It seems that with return value optimization, most of the work is already

done. Unfortunately I think adding support would require new syntax of some kind.

 

Maybe an attribute [[emplace]]. This would force RVO, enabling support for "returning" a non-movable object and also allowing the programmer to enforce that RVO is used for functions which return movable types.

 

[[emplace]] Widget makeWidget() { return Widget(); }
[[emplace]] auto x = makeWidget();
[[emplace]] auto x = std::atomic<int>{};

 

Of course with that approach people might just end up sprinkling [[emplace]] in all of their functions to optimize and increase compatibility...

 

Another option could be a new "inplace" initialization operator to use instead of =. I don't have a full specification for such a thing but it might look something like this:

static_assert(is_movable<Widget>::value == false);

Widget makeWidget() <=; //Declare an inplace return function that must do RVO.
auto w <= makeWidget(); //inplace construct w
auto i <= std::atomic<int>{}; //inplace construct i

 

Such an operator could even be used for value semantic types to specify the specific intent of direct construction vs copying. Op <= is a strawman for bikeshedding, but I think it could work since the comparison <= doesn't make sense in a new variable declaration or function signature.

 

In general the C++ language is designed around value semantics (i.e. construct and move) but has pretty poor support for inplace construction of immobile types. There are many (I would argue artificial) holes in the language and library when you need to work with immobile types.

 

 

[David Krauss]

On 2015–09–11, at 12:34 AM, Matthew Fioravante <fmatth...@gmail.com> wrote:

I would love to have factory functions for non-movable types. It seems that with return value optimization, most of the work is already 

done. Unfortunately I think adding support would require new syntax of some kind.

I think it would only require guaranteeing elision when initializing from (or returning) a prvalue of the same type.

Named return values would be icing on the cake, but that’s more complicated.

[Richard Smith]

On Thu, Sep 10, 2015 at 9:34 AM, Matthew Fioravante <fmatth...@gmail.com> wrote:

On Thursday, September 10, 2015 at 1:24:56 AM UTC-4, David Krauss wrote:

>
> still doesn't work because even there, a semantic check for copy/move
> is performed.

Right. I don’t favor that stylistically, but I’ll take it if it can’t be surgically separated from non-movable factory functions which are a hole in the language.

I would love to have factory functions for non-movable types.

struct Immovable {

  Immovable(int, int);

  Immovable(const Immovable&) = delete;

  void operator=(const Immovable&) = delete;

};

Immovable factory() {

  return {1, 2};

}

auto &&val = factory();

It seems that with return value optimization, most of the work is already

done. Unfortunately I think adding support would require new syntax of some kind.

 

Maybe an attribute [[emplace]]. This would force RVO, enabling support for "returning" a non-movable object and also allowing the programmer to enforce that RVO is used for functions which return movable types.

 

[[emplace]] Widget makeWidget() { return Widget(); }
[[emplace]] auto x = makeWidget();
[[emplace]] auto x = std::atomic<int>{};

 

Of course with that approach people might just end up sprinkling [[emplace]] in all of their functions to optimize and increase compatibility...

 

Another option could be a new "inplace" initialization operator to use instead of =. I don't have a full specification for such a thing but it might look something like this:

static_assert(is_movable<Widget>::value == false);

Widget makeWidget() <=; //Declare an inplace return function that must do RVO.
auto w <= makeWidget(); //inplace construct w
auto i <= std::atomic<int>{}; //inplace construct i

 

Such an operator could even be used for value semantic types to specify the specific intent of direct construction vs copying. Op <= is a strawman for bikeshedding, but I think it could work since the comparison <= doesn't make sense in a new variable declaration or function signature.

 

In general the C++ language is designed around value semantics (i.e. construct and move) but has pretty poor support for inplace construction of immobile types. There are many (I would argue artificial) holes in the language and library when you need to work with immobile types.

 

 

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

[David Krauss]

On 2015–09–11, at 4:37 AM, Richard Smith <ric...@metafoo.co.uk> wrote:

struct Immovable {

  Immovable(int, int);

This should be explicit. After all, it’s not a value-semantic class.

  Immovable(const Immovable&) = delete;

  void operator=(const Immovable&) = delete;

};

Immovable factory() {

  return {1, 2};

Omitting Immovable from this line is exactly wrong.

}

auto &&val = factory();

Lifetime extension only works for scoped variables.

struct caps {

    Immovable member { factory() };

    Immovable * ptr = new Immovable { factory() };

};

[Matt Calabrese]

On Thu, Sep 10, 2015 at 1:37 PM, Richard Smith <ric...@metafoo.co.uk> wrote:

On Thu, Sep 10, 2015 at 9:34 AM, Matthew Fioravante <fmatth...@gmail.com> wrote:

On Thursday, September 10, 2015 at 1:24:56 AM UTC-4, David Krauss wrote:

>
> still doesn't work because even there, a semantic check for copy/move
> is performed.

Right. I don’t favor that stylistically, but I’ll take it if it can’t be surgically separated from non-movable factory functions which are a hole in the language.

I would love to have factory functions for non-movable types.

struct Immovable {

  Immovable(int, int);

  Immovable(const Immovable&) = delete;

  void operator=(const Immovable&) = delete;

};

Immovable factory() {

  return {1, 2};

}

auto &&val = factory();

Okay, that's twisted!!!

[Richard Smith]

On Thu, Sep 10, 2015 at 1:56 PM, David Krauss <pot...@gmail.com> wrote:

On 2015–09–11, at 4:37 AM, Richard Smith <ric...@metafoo.co.uk> wrote:

struct Immovable {

  Immovable(int, int);

This should be explicit. After all, it’s not a value-semantic class.

That is not the criterion I use for this decision. The question is, does the pair of ints describe the value of the object (implicit constructor) or does it describe a set of inputs to a /computation/ that will produce the value of the object (explicit constructor)?

  Immovable(const Immovable&) = delete;

  void operator=(const Immovable&) = delete;

};

Immovable factory() {

  return {1, 2};

Omitting Immovable from this line is exactly wrong.

 That's just, like, your opinion, man. =)

}

auto &&val = factory();

Lifetime extension only works for scoped variables.

Yes. Guaranteed copy elision from temporaries would provide a complete solution (and I might present a paper on that topic at Kona). Then we don't need those fancy tricks, and we can instead just write the natural code:

  Immovable factory() {

    return Immovable{1, 2}; // no copy here

  }

  auto val = factory(); // no copy here either

struct caps {

    Immovable member { factory() };

    Immovable * ptr = new Immovable { factory() };

};

[David Krauss]

On 2015–09–11, at 5:29 AM, Richard Smith <ric...@metafoo.co.uk> wrote:

On Thu, Sep 10, 2015 at 1:56 PM, David Krauss <pot...@gmail.com> wrote:

This should be explicit. After all, it’s not a value-semantic class.

That is not the criterion I use for this decision. The question is, does the pair of ints describe the value of the object (implicit constructor) or does it describe a set of inputs to a /computation/ that will produce the value of the object (explicit constructor)?

That's just, like, your opinion, man. =)

That was meant as a reference my first message. Value semantics are a bit subjective, but they’re anti-correlated with a deleted move constructor.

If you can’t have this:

Immovable do_ = Immovable{ 2, 2 };

then how can this be allowed?

Immovable do_ = { 2, 2 };

The only conceptual wiggle room is the fleeting idea that the list itself is a value.

Yes. Guaranteed copy elision from temporaries would provide a complete solution (and I might present a paper on that topic at Kona). Then we don't need those fancy tricks, and we can instead just write the natural code:

Hooray! Let me know if I can help.

  Immovable factory() {

    return Immovable{1, 2}; // no copy here

  }

  auto val = factory(); // no copy here either

Hmm, should that be allowed with copy-initialization, or should auto val{ factory() } be required?

[Richard Smith]

On Thu, Sep 10, 2015 at 6:57 PM, David Krauss <pot...@gmail.com> wrote:

On 2015–09–11, at 5:29 AM, Richard Smith <ric...@metafoo.co.uk> wrote:

On Thu, Sep 10, 2015 at 1:56 PM, David Krauss <pot...@gmail.com> wrote:

This should be explicit. After all, it’s not a value-semantic class.

That is not the criterion I use for this decision. The question is, does the pair of ints describe the value of the object (implicit constructor) or does it describe a set of inputs to a /computation/ that will produce the value of the object (explicit constructor)?

That's just, like, your opinion, man. =)

That was meant as a reference my first message. Value semantics are a bit subjective, but they’re anti-correlated with a deleted move constructor.

If you can’t have this:

Immovable do_ = Immovable{ 2, 2 };

then how can this be allowed?

Immovable do_ = { 2, 2 };

The only conceptual wiggle room is the fleeting idea that the list itself is a value.

Yes. Guaranteed copy elision from temporaries would provide a complete solution (and I might present a paper on that topic at Kona). Then we don't need those fancy tricks, and we can instead just write the natural code:

Hooray! Let me know if I can help.

I'll let you know once I have a draft. 

  Immovable factory() {

    return Immovable{1, 2}; // no copy here

  }

  auto val = factory(); // no copy here either

Hmm, should that be allowed with copy-initialization, or should auto val{ factory() } be required?

With the approach I'm intending to follow, that will be valid (and that seems necessary, given that 'return', argument passing, braced init lists, and so on all use copy-initialization).

[David Krauss]

On 2015–09–11, at 10:03 AM, Richard Smith <ric...@metafoo.co.uk> wrote:

With the approach I'm intending to follow, that will be valid (and that seems necessary, given that 'return', argument passing, braced init lists, and so on all use copy-initialization).

When there’s no equals sign (passing, returning, throwing), it might as well be direct-initialization:

The problem with copy-initialization is that it’s sometimes used with no equals sign, such as in passing, returning, and throwing. The language treats it as a conservative choice when it’s impossible to guarantee that two values are the same object. However, this guarantee can always be made when passing, throwing, or returning a prvalue. The language/ABI interface is interfering with the programmer’s stated intentions.

My guess at the rationale for copy-initialization being applied in those contexts is that the implementation detail of a copy might be required. But if we change that detail, the backwards application of syntax-oriented semantics might also change.

I might not ready to argue this in court, though :P .

[Mark A. Gibbs]

On Wednesday, 9 September 2015 22:53:52 UTC-4, David Krauss wrote:

Elision hasn’t been mentioned yet :( .

 
The first 3/4 of the original post was just a whirlwind rush through the rationale of why I'm proposing what I'm proposing, haphazardly glossing over numerous and sundry details that aren't really relevant. To reiterate the reasoning:

• There are myriad ways to define new objects.
• Every one of those ways has at least one fail case or gotcha.
• Most of the ways cannot be salvaged - the fail case or gotcha cannot be fixed without creating other headaches.
• But there is one way that is almost perfect, and for which a fix is plausible: the form "XXX x = YYY{...};", where "XXX" and "YYY" resolve to exactly the same type. (You can replace the braces with parentheses, too.)
• The only gotcha in that case is that it doesn't work for non-movable and non-copyable types (though it does work for non-movable/copyable and movable/non-copyable types).
• What makes this gotcha even more absurd is that, in reality, no move or copy ever happens, due to elision.
• This elision, which changes the observable behaviour of the program, is allowed by the standard, but not required... and this is why that form doesn't work for non-movable/non-copyable types.
• So what my proposal is, is make that elision "mandatory", in effect - or rather, reinterpret statements of the form "XXX x = YYY{...};" to be a "definition statement", which is identical in meaning to "YYY x{...};" (or you can substitute parentheses, and you won't get bitten by the MVP). In other words, making it a new form of direct construction expression.
• What this proposal does is:
• Gives us one perfect way to direct define/define new variables that works in all contexts, all the time, generic or not, no exceptions.
• With a syntax that is easy to understand, clear, familiar and consistent with other types of construction (such as copy/move/conversion construction "XXX x = val;").
• With all the flexibility you can possibly want (you can use braces or parentheses, as you please, and they will select list constructors or not as per current rules).
• Without breaking any currently legal code.
  

Note that this has nothing to do with factory functions - whether for non-value types or not - and so is unrelated to the discussion going on elsewhere.

Writing random code from no semantic premises, and guessing at meaning from the perspective of a naive person, is not part of language design.

The solution to this problem is that newbies shouldn’t write non-value-semantic classes. Deleting the move constructor is a red flag, indicating that programming assistance is needed.

(Snip — the newbie did not seek help. This seldom ends well in any language.)

Most of my best students are those who took the initiative to figure things out in the language via experimentation. When you can't do that - or worse, as in this situation, when experimentation leads you confidently to the wrong answer - that means the language simply doesn't make sense. I don't think the correct answer to that dilemma is "you shouldn't experiment". The problem is not the student, it's the language.

Nothing rules out consulting an expert, of course, but the point is that you have to know when to consult an expert, and what questions to ask. You can't simply walk up to a language expert and say "just tell me everything". All experts and help communities expect you to do your homework and come prepared only with those questions you can't figure out on your own. (And in this case, trying to figure it out on your own will lead you to the wrong answer. Thus, we have a problem.)

Actually, making the language make more sense to beginners is my primary motivation for proposing this change (but also, easier generic programming). I would love to be able to tell the people I teach, on day 1 with no hemming or hawing or qualification: "This is how you create a new object in C++. Just do this. Auto, name, equals, type, braces, semicolon. Done. Want to initialize with a specific value? Stick it in the braces. Yes, there are other ways that you'll certainly see in other people's code, and in time - when we cover more topics - we'll talk about the various pros, cons, and gotchas. For now, just do this. It works." Then I can move on to teaching them actually useful things, and not have them come up to me a couple days later, "um, I tried to use this lock guard, and...".

Simple things should be simple. There doesn't need to be a goblin lurking in every single corner of the language.
 

And BTW, I agree with Ville’s that your proposal is closely aligned with N4014. They both result from blaming the problems of non-value-semantic classes on the equals sign instead of the class. The equals sign is a safety mechanism to protect you from thorny types; getting rid of its significance will only open the gates to more nastiness.

Okay, I think I'm cluing in to what you and Ville are saying. When referring to the relationship to N4014, you are not actually referring to the actual content of the paper (or the note on why it was rejected), but rather to what I assume is a discussion that went on behind the scenes. That discussion was not just on the specific issue (of explicitness), but a broader discussion about protecting the purity of separation between value types and non-value types.

And I gather what you're saying is that you want the equals sign to be the line of separation between value types and non-value types - that is, when you're using an equal sign, you must be working with a value type.

Does that correctly summarize what you and Ville are getting at?

Assuming so, I have to disagree with the reasoning. I don't disagree with maintaining a bright line of separation between value types and non-value types (let's just go with VTs and NVTs) - what I disagree with is that the equal sign is worth defending for this cause. I would say that battle is over, and purity lost. Here's why:

atomic<int> x = {};

That works, but this doesn't:

atomic<int> x = atomic<int>{};

So logically that means that the first statement is not really constructing an atomic on the right - it's (in essence) assigning (which is really a conversion construction) the (empty) list object on the right to the atomic on the left.

But if that's so, then why doesn't it work with types with an explicit default constructor?

The fact that it fails when the constructor is explicit implies that there must be (implicitly) an atomic<int> construction going on on the right. I mean, you can't sanely argue that whatever is being constructed on the left isn't explicitly an atomic<int>, right?

Yet if that is what is happening, then why does the second form fail? Isn't it doing exactly the same thing. Only... *wince*... explicitly?

So the equal sign is already in a dire mess when it comes to drawing a bright line between VTs and NVTs. Digging in and defending it for that purpose seems quixotic.

I also don't see any point in blaming NVTs for the mess, and saying "types should always be VTs... except when they can't possibly, and in that case, damn them to hell". Or rather, "yes, this is a mess, but it's only a mess when you use NVTs, so don't use them... unless you really, really have to, and if you have to, well, just suck up and accept the pain" (which reminds me of that old joke about the doctor and "it hurts when I do this"). I do agree that you should strongly prefer value semantics for your types, but the reality is that there are types for which that simply doesn't work, and those types aren't exactly rare or obscure. (You can make a valid argument against using mutexes and atomics all over the place - and maybe even locks - because there are better options for concurrency and parallelism, but what about scope guard objects? Like things that manage commit-or-rollback for transaction-like operations.) Creating one universal way to create objects really doesn't open the floodgates to making NVTs generally easy to use. After all, if your coding standard specified always using non-auto copy-/direct-list-initialization, that ship's already sailed anyway.

What I'm proposing is to change the way you think about the equal sign in expressions of the form "XXX x = YYY{...};". Don't think of it as an assignment operation (which, frankly, it already isn't - it doesn't call any assignment operation, it does a (copy/move) construction). Think of it not as a mathematical "equality" (which it already isn't really) but rather as a "definition". Mentally replace it not with "takes the value of", but rather "is".

And there is precedence for this in C++.

// This is not an operation on values
using type = other_type;
// Neither is this
namespace ns = verbose::name::space;

In other words, in the context of statements of the form "XXX x = YYY{...};", where "XXX" and "YYY" resolve to exactly the same type, the equals doesn't describe a transmission of value, but rather an alias. You can view it as defining a label "x", which is interpreted as a "YYY" object (remember, "XXX" resolves to the exact same type, but "XXX" might be "auto" whereas "YYY" cannot be), that is bound to the temporary that is created on the right, and the lifetime of the temporary is extended for the lifetime of the label "x".

And this form of variable definition is not revolutionary. Many languages have similar constructs

// Perl
my $x = initializer;

// OCaml, Rust
let x = initializer;

// JavaScript, Swift
var x = initializer;

// C++, conceptually
auto x = initializer;

Obviously the circumstances are very different in those other languages, and I'm not suggesting the semantics be duplicated in C++. I'm just saying the form is familiar. It just "looks like" you're creating the object on the left, and describing an alias to it on the right.

Another side effect of this change would be creating a kind of beautiful, simplistic consistency in the language. Here is what it would look like if you are using explicit types (no "auto"):

type x = type{};  // (direct) default construction
type x = type();  // same
// Both of the above work for *all* types that have default constructors,
// regardless of whether it's explicit or not, regardless of whether the type
// is movable and/or copyable. It Just Works(tm).

type x = type{...};  // (explicit, direct) list initialization
type x = type(...);  // (explicit, direct) non-list initialization
// Both of the above work for *all* types that have the constructor with the
// given signature, regardless of whether it's explicit or not, regardless of
// whether the type is movable and/or copyable. As with today, an initializer
// list constructor gets priority in the first case, and a non-initializer-list
// constructor gets priority in the second case. It Just Works(tm).

type x = lvalue;              // copy construction (presumably)
type x = rvalue;              // move construction (presumably)
type x = std::move(lvalue);   // move construction (presumably)
type x = factory_function();  // move construction (presumably)
// The semantics of the above don't change - they only work for types that
// allow copy/move construction. These all Just Work(tm) for value types.

type x = 0;    // int
type x = {0};  // int
// The semantics of the above don't change.

// The type names don't need to be identical, they just need to resolve to the
// same type.
using alias = type;
alias x = type{};  // (direct) default construction
alias x = type();  // same
alias x = type{...};  // (explicit, direct) list initialization
alias x = type(...);  // (explicit, direct) non-list initialization

Things get even simpler, and more elegant, when you use "auto":

auto x = type{};  // (direct) default construction
auto x = type();  // same
// Both of the above work for *all* types that have default constructors,
// regardless of whether it's explicit or not, regardless of whether the type
// is movable and/or copyable. It Just Works(tm).

auto x = type{...};  // (explicit, direct) list initialization
auto x = type(...);  // (explicit, direct) non-list initialization
// Both of the above work for *all* types that have the constructor with the
// given signature, regardless of whether it's explicit or not, regardless of
// whether the type is movable and/or copyable. As with today, an initializer
// list constructor gets priority in the first case, and a non-initializer-list
// constructor gets priority in the second case. It Just Works(tm).

auto x = lvalue;              // copy construction (presumably)
auto x = rvalue;              // move construction (presumably)
auto x = std::move(lvalue);   // move construction (presumably)
auto x = factory_function();  // move construction (presumably)
// The semantics of the above don't change - they only work for types that
// allow copy/move construction. These all Just Work(tm) for value types.

auto x = 0;    // int
auto x = {0};  // std::initializer_list<int> (with one element, that is 0)
               // which is different from using explicit type (but still clear)
// The semantics of the above don't change.

// No issues with type aliasing

I can only think of two potential gotchas, but they're both rather esoteric cases.

Case 1 is code that relies on the current behaviour:

template <typename T>
auto func()
{
  // I expect this template function to only be instantiated for types that are
  // movable and/or copyable, and rather than expressing this via traits or
  // concepts, I'm relying on the current interpretation of the following lines:
  T t1 = T{};
  auto t1 = T{};
}

This function fails to compile today for non-movable/non-copyable types, but will with my proposed change.

However, I have never seen any code that relied on that, and I would argue any code that did was already a maintenance headache.

Case 2 is code that gets bitten by type aliasing:

// assuming type_1 is non-copyable and non-movable
using type_2 = type_1;

template <typename T, typename U>
auto func()
{
  // I expect this template function to do a default construction of a temporary
  // U object, then a conversion construction of a T using that temporary.
  // In fact, I *INSIST* on this behaviour, and even use a special compiler, or
  // compiler switches, to make it happen.
  T t = U{};
}

func<type_1, type_2>();

This function - assuming a compiler that does no elision, or that elision has been disabled - will always create the temporary then construct the object with it under current rules. With proposed change, it will continue to do that... except when T and U resolve to the same type. In that case, the statement is interpreted as a direct default construction of "t".

But of course, who seriously turns off elision, or requires that it be disabled? And if you really want that series of operations, relying on compiler switches means your code is unportable anyway. You could get the same behaviour, portably, by just writing it over two lines.

There are still some edge cases I'm not sure how to handle. For example, how to handle the case in "XXX x = YYY{...};" where the two types differ only in cv-qualification. Or referenceness. I'm inclined to say "ignore cv differences ("x" will have the cv qualifiers of "XXX", not "YYY"), but don't ignore referenceness (interpret that the same as today)".

[Tomasz]

W dniu czwartek, 10 września 2015 01:27:18 UTC+2 użytkownik Mark A. Gibbs napisał:

But if you don't have a value, or if you do but you want to be explicit about the type, you can use:

auto v = type{val};  // or any other constructor arguments, including none

I feel sad when a people want to eliminate all the work that was done on checking the units and the ratios on compile time, just to force the use of shinny new auto. Please assume that I want to receive a duration in seconds, and compare the results of:
std::chrono::seconds s = get_timeout();
auto s = std::chrono::seconds{s};
std::chrono::seconds s{get_timeout()};

To help out a bit, please consider following declarations:
int get_timeout(); //return number of seconds
std::chrono::seconds get_timeout();
And how the program will behave if one is replaced with another, or the unit is changed.

[Mark A. Gibbs]

 
Could you please explain exactly what behaviour you think would be surprising or problematic, with respect to the proposal in this topic?

[Tomasz]

The motivation behind proposed change is to allow "one proper" initialization syntax for the case, when the user want to commit to a specific type:
auto x = type{expr};
The example when the syntax are discussed usually present the situation when the expression has type visible at the point of variable declaration. Like constant in the blog example, but to see the difference and value of having direct and copy intialization we need to discuss a example when type of expr is not know or may be changed in the future - the cases when the variable is initialized from a return of the function foo().

The difference between direct and non-direct initialization give us two options:
Type x = foo();  //This will compile only if there is implicit conversion between result of foo() and Type
Type x(foo()); //Will compile when there is explicit conversion from result of foo() and Type
This is just other side of the coin, and allow to use the same conversion to pass result from callee to caller, as in passing argument form caller to callee.

Then there is a whole paradigm of having "meaningful types" that uses type checking do differentiate between number of seconds and milliseconds or between the weight of thing in newtons and mass in grams. Such "opaque" class usually marks constructors that add semantics information (from bare number to seconds) as explicit, so following will work:

std::chrono::seconds s = get_timeout();

Only if the get_timeout() will return a appropriate duration time. I am using the compiler to check if the conversion is safe and I actually getting the right number. But following:
std::chrono::seconds s(get_timeout());
Will work even if the get_timeout() is returning bare number. Now I am taking resposibility for making sure that the number is actually number of seconds not milliseconds.

Finally, returning to original topic. In case if we stick to use of the use of ETTI only:
auto s = std::chrono::seconds(get_timeout());
The programmer has no longer way to express the fact that he wants only implicit conversion to be invoked. This basically eliminates all the gain that was achieved by meaningful types, but introducing unintended conversion. I do think that teaching the initialization syntax that will eliminate gains for unit/ratio classes is good direction.

Ironically the poeple that are promoting auto everywhere syntax are given argument about lack of unintended conversion as argument for using it. While use ETTI (auto x = type(expr)) acutally introduce possibility of more bogus one. Just think of the Herb Sutter example:
auto x = unique_ptr<Base>{createDerived()};
It is working correctly in case when createDerived() is retruning unique_ptr<Derived>. But what if it will start to return raw pointer to class to object that has lifetime handled eslewhere? The syntax:
unique_ptr<Base> x = createDerived();
Will catch such change at compile time.

[David Krauss]

On 2015–09–11, at 12:02 PM, Mark A. Gibbs <indi.in....@gmail.com> wrote:

Most of my best students are those who took the initiative to figure things out in the language via experimentation. When you can't do that - or worse, as in this situation, when experimentation leads you confidently to the wrong answer - that means the language simply doesn't make sense. I don't think the correct answer to that dilemma is "you shouldn't experiment". The problem is not the student, it's the language.

I didn’t say not to experiment, I said that you get into trouble when you lose value semantics. The problem with the example is that its “experiment” just seems to be a random jumble of keywords, and then you say that the result is surprising. An experiment is something that tests a hypothesis, and the example never said what the student was after.

Nothing rules out consulting an expert, of course, but the point is that you have to know when to consult an expert, and what questions to ask. You can't simply walk up to a language expert and say "just tell me everything". All experts and help communities expect you to do your homework and come prepared only with those questions you can't figure out on your own. (And in this case, trying to figure it out on your own will lead you to the wrong answer. Thus, we have a problem.)

In this case, the question would be, “why doesn’t the equals sign work”? And the answer would be, “the right-hand side doesn’t behave as a value.”

Actually, making the language make more sense to beginners is my primary motivation for proposing this change (but also, easier generic programming).

The flip side of regular syntax with loose semantic constraints is getting unexpected meaning from templates. Some things aren’t supposed to compile.

I would love to be able to tell the people I teach, on day 1 with no hemming or hawing or qualification: "This is how you create a new object in C++. Just do this. Auto, name, equals, type, braces, semicolon. Done. Want to initialize with a specific value? Stick it in the braces. Yes, there are other ways that you'll certainly see in other people's code, and in time - when we cover more topics - we'll talk about the various pros, cons, and gotchas. For now, just do this. It works." Then I can move on to teaching them actually useful things, and not have them come up to me a couple days later, "um, I tried to use this lock guard, and…".

There’s a language for that: Java. (Except, scalars in Java are new objects without using the new keyword.)

The extra bits of C++ are useful to make it a richer language. We can’t just sweep them under the rug. You can use AAA as far as value semantics go, but that won’t get you a lock guard.

Simple things should be simple. There doesn't need to be a goblin lurking in every single corner of the language.
 

And BTW, I agree with Ville’s that your proposal is closely aligned with N4014. They both result from blaming the problems of non-value-semantic classes on the equals sign instead of the class. The equals sign is a safety mechanism to protect you from thorny types; getting rid of its significance will only open the gates to more nastiness.

Okay, I think I'm cluing in to what you and Ville are saying. When referring to the relationship to N4014, you are not actually referring to the actual content of the paper (or the note on why it was rejected), but rather to what I assume is a discussion that went on behind the scenes. That discussion was not just on the specific issue (of explicitness), but a broader discussion about protecting the purity of separation between value types and non-value types.

I never listened to any other discussion on N4014. Value vs. non-value isn’t black and white. I can’t speak for Ville. But yes, it’s a broader discussion. One of the more obvious artifacts was a debate over whether explicit constructors should be invoked by return statements, which generated about a half-dozen papers.

And I gather what you're saying is that you want the equals sign to be the line of separation between value types and non-value types - that is, when you're using an equal sign, you must be working with a value type.

Does that correctly summarize what you and Ville are getting at?

Assuming so, I have to disagree with the reasoning. I don't disagree with maintaining a bright line of separation between value types and non-value types (let's just go with VTs and NVTs) - what I disagree with is that the equal sign is worth defending for this cause. I would say that battle is over, and purity lost. Here's why:

atomic<int> x = {};

That works, but this doesn't:

atomic<int> x = atomic<int>{};

Because the second example isn’t equivalent to the first. It’s equivalent to this:

atomic<int > x = { 0 };

The RHS of = is supposed to be a value. That’s why the conversion implemented by the copy and move constructors is “lvalue-to-rvalue.” This applies equally to initialization and assignment.

If atomic’s conversion constructor from its initial value were explicit, then I think the default constructor would be as well.

Arguably this should work too:

atomic< int > x = 0;

I do think it’s a bit silly to convert to a temporary before initializing the named variable, but I can’t comment further without digging into the history of the language.

So logically that means that the first statement is not really constructing an atomic on the right - it's (in essence) assigning (which is really a conversion construction) the (empty) list object on the right to the atomic on the left.

But if that's so, then why doesn't it work with types with an explicit default constructor?

The fact that it fails when the constructor is explicit implies that there must be (implicitly) an atomic<int> construction going on on the right. I mean, you can't sanely argue that whatever is being constructed on the left isn't explicitly an atomic<int>, right?

On the right, just a plain int. If it were really atomic, then special semantics would apply to evaluating it for the sake of making a copy. (More so for non-lock-free types.)

True, you’re proposing to guarantee elision of that copy. But copy elision was never intended as a pillar of the language. Things are supposed to work without it; it’s not a failsafe bypass around the lvalue-to-rvalue conversion.

[Mark A. Gibbs]

On Friday, 11 September 2015 04:00:53 UTC-4, Tomasz wrote:

The difference between direct and non-direct initialization give us two options:

Type x = foo();  //This will compile only if there is implicit conversion between result of foo() and Type
Type x(foo()); //Will compile when there is explicit conversion from result of foo() and Type

What I'm proposing has no effect whatsoever on those two forms. You can still use them, with no change in semantics. You're not losing any flexibility. You're gaining a method that works for all types. It may not work precisely the way you want for a specific case, but if you have specific needs, go ahead and use one of the other forms. No one's tying your hands.
 

Ironically the poeple that are promoting auto everywhere syntax are given argument about lack of unintended conversion as argument for using it. While use ETTI (auto x = type(expr)) acutally introduce possibility of more bogus one. Just think of the Herb Sutter example:
auto x = unique_ptr<Base>{createDerived()};
It is working correctly in case when createDerived() is retruning unique_ptr<Derived>. But what if it will start to return raw pointer to class to object that has lifetime handled eslewhere? The syntax:
unique_ptr<Base> x = createDerived();
Will catch such change at compile time.

 
Okay, here's my counter example:

int get_count();

// Then later get_count() is changed to return a long. Or std::size_t.

int n = get_count();  // This will fail to detect the change. Bug reports of
                      // counts of -1234 objects ensue.

auto n = int{get_count()};  // This will detect the issue at compile time.

Now, as for my analysis of your example: When you change the interface contract of a function, and either don't change the return type - or change it to a type that is implicitly convertible to the original type in some situations - I don't know how you can seriously expect to rely on the language to save you from yourself.

No initialization syntax is perfect. But the difference between your example and mine is that mine is a plausible update to a code base to accommodate growth, whereas yours is really just a really dumb refactoring decision that someone hoped that compiler would spare them from the consequences of. The "auto" version catches the plausible modification, but misses the terrible refactoring job. The non-"auto" version catches the really dumb change that should never happen, but fails to catch the plausible modification. Frankly, I'd prefer the "auto" result, in practice. Oh, also, the "auto" version will crash the very first time the code that puts the result of createDerived() in a unique_ptr gets called - basically day 1 of testing - and debug mode will give you a message about the double-delete... meanwhile the bug in the non-"auto" version could go for years without being detected, unless and and until there happens to be a case when the result of get_count() is too large, which may only happen sporadically and be hard to reproduce. Advantage: auto.

Back to your example, relying on the semantics of "type x = factory_function();" is a bad idea. Unless you put a comment next to it explicitly explaining that that's what you intend, you risk someone coming along and thinking that "type x{factory_function()};" is a better idea, because it prevents narrowing, or something similar. The smart thing to do is this:

template <typename T, typename U>

auto as(U&& u) -> T
{
  return {u};
}

auto s = as<std::chrono::seconds>(get_timeout());
// or if you prefer a different name:
auto s = implicitly_as<std::chrono::seconds>(get_timeout());
auto s = safely_as<std::chrono::seconds>(get_timeout());

That will catch unwanted explicit conversions... and it will catch narrowing (and if you don't want that, drop the braces)... and it is self-documenting in code. And if you don't use the auto there, you have to repeat the type, which is a bad idea. For auto, I think that's game, set, and match.

Perhaps those of us who want to "force" everyone to use the "shiny new auto" have given this a bit more thought than you give us credit for.

Anyway, to be clear, I am not proposing a way to initialize objects that will solve every single possible problem imaginable. I am just proposing a way that will work for every type, and do a sensible thing in all cases. It may not work precisely the way you need it to for your specific instance, in which case you can use a more specific form.

[Mark A. Gibbs]

On Friday, 11 September 2015 04:11:43 UTC-4, David Krauss wrote:

I didn’t say not to experiment, I said that you get into trouble when you lose value semantics. The problem with the example is that its “experiment” just seems to be a random jumble of keywords, and then you say that the result is surprising.

That is saying "don't experiment", because experimenting means trying things that you don't know whether they'll work or not, and learning from the discovery of what happens. Okay, perhaps you're not saying "don't experiment ever", but you are saying "don't experiment with non-value types". Of course, the catch is that the beginner won't know that rule, and even if they do they won't know what non-value types are, so they won't know where they can or can't experiment. So, basically, "don't experiment".

Anyway, if it's just that you think the experimentation example wasn't realistic, I can easily provide you with a realistic one. I've seen it happen plenty of times.
 

An experiment is something that tests a hypothesis, and the example never said what the student was after.

Now you're just trying to be pedantic, but I can do that, too. A science experiment is one that involves hypothesis testing, but even then not all science experiments involve hypotheses: there is such a thing as "exploratory data analysis". Experimentation in the general sense is merely "trying shit to see what happens". The latter type may be non-rigorous, but it is very often the first stage in an investigation that will be followed up by the former type. Great scientific discoveries often start with "hm, I wonder what happens if...".

(Also, in the original example, there was a hypothesis being tested. Specifically, that one of the four special member functions copy/move construct/assign was being used in that initialization statement. The experiment was putting markers in the four functions to reveal which. You could consider that a "closed testing procedure" that tests multiple hypotheses - in this case, 4, each with its own null hypothesis - simultaneously.)
 

In this case, the question would be, “why doesn’t the equals sign work”?

Actually, the question is not "why doesn't the equal sign work", because "atomic<int> a = {};" works but "atomic<int> a = atomic<int>{};" doesn't. Clearly the equal sign does work. The question is why doesn't it work when I write the type twice, even though the braces on the right appear to be implying a default constructed atomic on the right that is being "put" in the atomic on the left - or aliased by the variable being declared on the left. And this behaviour appears to be what that construct implies, because that's what apparently happens according to "atomic<int> a = 0;" (doesn't work because non-copy/non-movable) and "tuple<int> t = {0};" (doesn't work because construction on the right is implicit).

I suggest that you are making a mistake by trying to interpret "type x = type{...};" as an assignment between two values. Firstly, that seems a suspicious argument right from the get go, because you don't have two values. In fact, you have none before, then one after. And unlike all other forms of initialization, in the interim you have two objects that were constructed out of whole cloth right there in the statement, unobservably (because of elision). (This is different from the cases of "type x = val;" and "type x = func_yielding_rvalue();", because in both those two cases, the RHS value is constructed elsewhere (though possibly elided).) The argument that you really, really want this ghost object that never really exists seems weak.

Secondly, the language refutes that interpretation. If a non-copy/non-move type has a constructor that takes an int, but no assignment operators that take an int, this still works: "type x = {0};". How can that be if this is actually a transfer of values? The type has no way to take an int (or an initializer list) except by construction, so it must therefore be constructing on the right... but that can't be, because the type is non-copy/non-movable, so if it were constructed on the right, it can't possibly be transferred to the left. Therefore there cannot be two values in that statement - there must only be one, the object on the right constructed with the int on the left. (Of course, the language then turns around and screws you again, if that constructor is explicit. As I keep saying, I think you're barking up the wrong tree trying to argue for consistency in construction statements. That ship has sailed.)
 

And the answer would be, “the right-hand side doesn’t behave as a value.”

 
Yet this works:

auto&& x = std::atomic<int>{};

So clearly the claim that "=" only works with value types just doesn't hold water.

"=" may be the dividing line between value types and non-value types in general code - when it is actually being used as an assignment. But in the context of initialization, it isn't, at least not consistently.

The flip side of regular syntax with loose semantic constraints is getting unexpected meaning from templates. Some things aren’t supposed to compile.

But as I pointed out, that argument doesn't really apply to declarations of the form "type x = type{...};". Nobody writes code like that with the expectation that it is the only thing keeping non-copy/non-move types out the door. Almost 20 years of C++ and 10 years of teaching it, I have never seen that done (and I've seen some crazy shit). Anybody who does that is being "clever" to the point of frustrating future maintenance of the code, so there is no reason the standard should have to bless that behaviour. There are better ways to prevent generic code from compiling in the face of a non-value type. We just don't need this particular case.

Also, I'm not proposing "loose" semantic constraints. I'm proposing very rigorous constraints... just constraints that are different from the existing ones in one specific context (which are specious).

You're making it sound like I'm proposing throwing all distinction between value and non-value types out - or perhaps removing the ability for "=" to distinguish in all cases. That's not so. I'm talking about taking one... specific... instance - just "type x = type{...};", and not even "type x = val;" or "type x = func();", those should still fail in the absence of copy/move ops - in a context where there are already lots of special cases and exceptions (initialization), and for the gain of ending the madness of having no way to construct a new object that works for all types. I think we can let this one go.

There’s a language for that: Java. (Except, scalars in Java are new objects without using the new keyword.)

I realize you're invoking Java as the exemplar of a language that prefers simplicity and consistency at the expense of flexibility, expressiveness and power... exactly what we don't want C++ to become. But frankly, if a bad language has a good idea... I'm a-gonna take it. I don't care if the rest of the design in that language is misguided - if it has something that works well, and it can be done in C++ without sacrificing anything important... yeah, I'll steal from Java. I don't have so much pride that I would refuse a good idea just because of its source.

Assuming so, I have to disagree with the reasoning. I don't disagree with maintaining a bright line of separation between value types and non-value types (let's just go with VTs and NVTs) - what I disagree with is that the equal sign is worth defending for this cause. I would say that battle is over, and purity lost. Here's why:

atomic<int> x = {};

That works, but this doesn't:

atomic<int> x = atomic<int>{};

Because the second example isn’t equivalent to the first.

I didn't claim they were equivalent. In fact, I obviously realize they aren't because the whole point of my proposal is to make them equivalent.

I pointed out that the claim that "=" implies value semantics is false. Atomics don't have value semantics, yet you can do "atomic<int> a = {};".

If it were really true that "=" really did imply value semantics in all cases, then I would have to acquiesce - you would be right, and maintaining a clear wall distinction between value types and non-value types is more important than convenience. But it doesn't always imply value semantics. There are already exceptions and gotchas... especially in the context I'm focused on. Since the wall is already full of holes, the argument for adding one more that makes things really convenient and consistent suddenly has merit.
 

Arguably this should work too:

atomic< int > x = 0;

I do think it’s a bit silly to convert to a temporary before initializing the named variable, but I can’t comment further without digging into the history of the language.

So why shouldn't this?:

atomic<int> a = atomic<int>{0};

What you're saying is that you think that it's reasonable that "atomic<int> a = 0;" should be interpreted as "atomic<int> a{0};", and not "atomic<int> a = atomic<int>{0};" (as it currently is). I agree - I see no sane reason why it shouldn't. It's obvious what you really mean, and there's really no reason a temporary has to be constructed then transferred to the named variable.

So if that's reasonable, why is interpreting "atomic<int> a = atomic<int>{0};" as "atomic<int> a{0};" so crazy? It's the exact... same... reasoning: It's obvious what you really mean, and there's really no reason a temporary has to be constructed then transferred to the named variable.

Remember, "atomic<int> a = {0};" is already interpreted as "atomic<int> a{0};". "{0}" just by itself is an initializer_list<int>, yet atomic<int> has no initializer_list<int> constructor, so that has to be what the interpretation of what's happening is - the "{0}" is not "an initializer list", but rather "the initializer list for the atomic being constructed". This is already a context were the "normal" rules of "=" just don't apply. What I'm proposing is basically just interpreting "atomic<int> a = atomic<int>{0};" as "atomic<int> a atomic<int>{0};", then dropping the redundant repetition of the type. (But, of course, ONLY in the case where the type actually is repeated.)
 

True, you’re proposing to guarantee elision of that copy. But copy elision was never intended as a pillar of the language. Things are supposed to work without it; it’s not a failsafe bypass around the lvalue-to-rvalue conversion.

 
Yes, and I am proposing to change that - in this one, specific syntactic construct. That's why elision is mentioned in the topic.

You're right, the current state of affairs is that elision is optional in all cases, even in the case that I'm focused on. My argument is if we change that rule just in this specific case, to make the elision effectively required - and "required" to the point that there is no moving at all, even conceptually - we gain:

• guaranteed efficiency (as opposed to almost-certain but not required efficiency)
• and a practical solution to the initialization madness that works in all cases (though may not do precisely what you specifically need in a specific case, in which case you still have the other options).
  

The only purposes behind keeping the requirement that the type be copy/movable are either a) to maintain language purity wrt the distinction of value/non-value types, or b) because it is a practical way to actually distinguish between value/non-value types in generic code.

For (a), I say that goal is already a lost cause, in this context. There are so many peculiarities in the interpretations of the various construction syntaxes, that this doesn't really seem the right place to be adamant about drawing this line.

For (b), I say: nobody does it for that purpose, nobody would understand that's what the intention was if it was actually used for that purpose, there are several other - better - ways of achieving the same goal, and finally, it just don't work anyway. There are more requirements to having value semantics than just being copy/movable, so a type that does not have value semantics but is copy/movable would pass the bar.

Given that the syntax doesn't actually distinguish anything but whether the type is non-copy/non-movable or not - it doesn't actually serve the purpose of detecting value semantics - and that construction in general is already a context where some things that look like copies/moves are not actually, I think we can get away with repurposing it, and gaining clarity and sanity in one of the most basic and important parts of the language: constructing objects.

[David Krauss]

On 2015–09–12, at 9:48 AM, Mark A. Gibbs <indi.in....@gmail.com> wrote:

On Friday, 11 September 2015 04:11:43 UTC-4, David Krauss wrote:

I didn’t say not to experiment, I said that you get into trouble when you lose value semantics. The problem with the example is that its “experiment” just seems to be a random jumble of keywords, and then you say that the result is surprising.

That is saying "don't experiment", because experimenting means trying things that you don't know whether they'll work or not,

How can you say whether something “worked” if there was no goal in the first place? You only mentioned "Wanting to explore constructors and destructors,” so from that perspective, the experiment was a resounding success.

and learning from the discovery of what happens. Okay, perhaps you're not saying "don't experiment ever", but you are saying "don't experiment with non-value types". Of course, the catch is that the beginner won't know that rule, and even if they do they won't know what non-value types are, so they won't know where they can or can't experiment. So, basically, "don't experiment”.

Don’t experiment unless you’re willing to discover something new. Don’t try to work in a vacuum, but maintain contact with the community of folks with related experience. These rules apply to all academia. Especially now, StackOverflow is always just a click away.

The confusion of the student in the second part of your example was due to copy elision, by the way, which isn’t guaranteed. Compilers still implement -fno-elide-copies last I checked. Although in your example, elision can effectively be guaranteed because the initializer is a prvalue, in other cases the move constructor is still really used. To cover all the bases, you’d need to subdivide copy-initialization into more different cases. It would not ultimately be a simplification, you’d just be sweeping a few things further under the rug.

Anyway, if it's just that you think the experimentation example wasn't realistic, I can easily provide you with a realistic one. I've seen it happen plenty of times.

Sure, fire away.

An experiment is something that tests a hypothesis, and the example never said what the student was after.

Now you're just trying to be pedantic, but I can do that, too. A science experiment is one that involves hypothesis testing, but even then not all science experiments involve hypotheses: there is such a thing as "exploratory data analysis". Experimentation in the general sense is merely "trying shit to see what happens". The latter type may be non-rigorous, but it is very often the first stage in an investigation that will be followed up by the former type. Great scientific discoveries often start with "hm, I wonder what happens if…".

If the student is only trying to learn the rules, then they’re not allowed to be upset when they find one.

I also recall learning about copy elision when copy constructor side effects disappeared. Even back then in the 90’s, there was literature to connect the surprising result to class value semantics, and turn the “exploratory data analysis” into a valuable learning experience.

Copy elision isn’t remotely new, nor is the element of surprise specific to non-value-semantic classes.

(Also, in the original example, there was a hypothesis being tested. Specifically, that one of the four special member functions copy/move construct/assign was being used in that initialization statement. The experiment was putting markers in the four functions to reveal which. You could consider that a "closed testing procedure" that tests multiple hypotheses - in this case, 4, each with its own null hypothesis - simultaneously.)

Another platform or another similar experiment would have resulted in the move constructor being called.

In this case, the question would be, “why doesn’t the equals sign work”?

Actually, the question is not "why doesn't the equal sign work", because "atomic<int> a = {};" works but "atomic<int> a = atomic<int>{};" doesn't. Clearly the equal sign does work. The question is why doesn't it work when I write the type twice, even though the braces on the right appear to be implying a default constructed atomic on the right

False supposition.

that is being "put" in the atomic on the left - or aliased by the variable being declared on the left. And this behaviour appears to be what that construct implies, because that's what apparently happens according to "atomic<int> a = 0;”

I’ll grant that atomic<int> a = 0 should work, but only because 0 is not an atomic. If you use {0}, there is no move (or elision) needed.

(doesn't work because non-copy/non-movable) and "tuple<int> t = {0};" (doesn't work because construction on the right is implicit).

This is already fixed.

I suggest that you are making a mistake by trying to interpret "type x = type{...};" as an assignment between two values. Firstly, that seems a suspicious argument right from the get go, because you don't have two values. In fact, you have none before, then one after.

The expression type{…}, like any expression, has a value. You want to use it as the initial value of a persistent object, but in the first place it exists as a value, regardless of its enclosing context.

Your model doesn’t seem to accommodate type x = derived_type{};

And unlike all other forms of initialization, in the interim you have two objects that were constructed out of whole cloth right there in the statement, unobservably (because of elision). (This is different from the cases of "type x = val;" and "type x = func_yielding_rvalue();", because in both those two cases, the RHS value is constructed elsewhere (though possibly elided).) The argument that you really, really want this ghost object that never really exists seems weak.

Secondly, the language refutes that interpretation. If a non-copy/non-move type has a constructor that takes an int, but no assignment operators that take an int, this still works: "type x = {0};”.

What do assignment operators have to do with this?

How can that be if this is actually a transfer of values? The type has no way to take an int (or an initializer list) except by construction, so it must therefore be constructing on the right... but that can't be, because the type is non-copy/non-movable, so if it were constructed on the right, it can't possibly be transferred to the left.

An int is constructed on the right and transferred to the left. Easy peasy.

Therefore there cannot be two values in that statement - there must only be one, the object on the right constructed with the int on the left. (Of course, the language then turns around and screws you again, if that constructor is explicit. As I keep saying, I think you're barking up the wrong tree trying to argue for consistency in construction statements. That ship has sailed.)

There’s plenty of literature on what explicit means, due to the recent return statement debate. Please review, for the sake of your students.

And the answer would be, “the right-hand side doesn’t behave as a value.”

 
Yet this works:

auto&& x = std::atomic<int>{};

So clearly the claim that "=" only works with value types just doesn't hold water.

"=" may be the dividing line between value types and non-value types in general code - when it is actually being used as an assignment. But in the context of initialization, it isn't, at least not consistently.

This is temporary lifetime extension. Is it impure to use = for reference binding? Interesting thought. However, the easy answer is that the value on the RHS is exactly preserved by reference binding, overriding class semantics. All expressions have values, after all, and “non-value-semantic” classes are only ones which may misbehave when some mathematical abstraction is assumed. “Value semantic” refers to the notion of separating a value from an object, not the existence of a value in the first place.

Reference binding gives expression templates conniptions: They use non-value types to represent mathematical values.

A reference stores an lvalue, i.e. an alias to an object which must remain valid — I’m content to leave it at that. (Well, not exactly satisfied… the language should do more validation, and user-defined types should have access to lifetime extension as well, hence my proposal bit.ly/genlife.)

The flip side of regular syntax with loose semantic constraints is getting unexpected meaning from templates. Some things aren’t supposed to compile.

But as I pointed out, that argument doesn't really apply to declarations of the form "type x = type{...};". Nobody writes code like that with the expectation that it is the only thing keeping non-copy/non-move types out the door. Almost 20 years of C++ and 10 years of teaching it,

Nobody in their right mind would write type on both sides of the equals sign before C++11. We’re both limited to 4-5 years experience with this.

I have never seen that done (and I've seen some crazy shit). Anybody who does that is being "clever" to the point of frustrating future maintenance of the code, so there is no reason the standard should have to bless that behaviour. There are better ways to prevent generic code from compiling in the face of a non-value type. We just don't need this particular case.

Also, I'm not proposing "loose" semantic constraints. I'm proposing very rigorous constraints... just constraints that are different from the existing ones in one specific context (which are specious).

To me, you sound specious. But I’m keeping an open mind; you’re the one pacing this discussion.

You're making it sound like I'm proposing throwing all distinction between value and non-value types out - or perhaps removing the ability for "=" to distinguish in all cases. That's not so. I'm talking about taking one... specific... instance - just "type x = type{...};", and not even "type x = val;" or "type x = func();", those should still fail in the absence of copy/move ops - in a context where there are already lots of special cases and exceptions (initialization), and for the gain of ending the madness of having no way to construct a new object that works for all types. I think we can let this one go.

What about type x = type{ func() }?

There’s a language for that: Java. (Except, scalars in Java are new objects without using the new keyword.)

I realize you're invoking Java as the exemplar of a language that prefers simplicity and consistency at the expense of flexibility, expressiveness and power... exactly what we don't want C++ to become. But frankly, if a bad language has a good idea... I'm a-gonna take it. I don't care if the rest of the design in that language is misguided - if it has something that works well, and it can be done in C++ without sacrificing anything important... yeah, I'll steal from Java. I don't have so much pride that I would refuse a good idea just because of its source.

Just as there’s C++-as-C, there’s also C++-as-Java — albeit with no garbage collector. (We should have a GC already, though!) Many instructors have really gone that route, to the chagrin of the rest of the community.

I didn't claim they were equivalent. In fact, I obviously realize they aren't because the whole point of my proposal is to make them equivalent.

I pointed out that the claim that "=" implies value semantics is false. Atomics don't have value semantics, yet you can do "atomic<int> a = {};”.

Hmm, you deleted the part where I explained that is equivalent to atomic<int> a = {0}; and then re-asked the question.

A: atomic<int> a = {};

B: atomic<int> a = {0};

C: atomic<int> a = atomic<int>{};

A is equivalent to B. Not by language semantics, but because the class defines it that way.

A is not equivalent to C. You propose to make them equivalent at the language level.

What about classes for which B is not equivalent to C?

If it were really true that "=" really did imply value semantics in all cases, then I would have to acquiesce - you would be right, and maintaining a clear wall distinction between value types and non-value types is more important than convenience. But it doesn't always imply value semantics. There are already exceptions and gotchas... especially in the context I'm focused on. Since the wall is already full of holes, the argument for adding one more that makes things really convenient and consistent suddenly has merit.
 

Arguably this should work too:

atomic< int > x = 0;

I do think it’s a bit silly to convert to a temporary before initializing the named variable, but I can’t comment further without digging into the history of the language.

So why shouldn't this?:

atomic<int> a = atomic<int>{0};

What you're saying is that you think that it's reasonable that "atomic<int> a = 0;" should be interpreted as "atomic<int> a{0};”

No, I’m saying it’s reasonable to interpret it as atomic<int> a = {0} with braces and the equals sign.

, and not "atomic<int> a = atomic<int>{0};" (as it currently is). I agree - I see no sane reason why it shouldn't. It's obvious what you really mean, and there's really no reason a temporary has to be constructed then transferred to the named variable.

So if that's reasonable, why is interpreting "atomic<int> a = atomic<int>{0};" as "atomic<int> a{0};" so crazy? It's the exact... same... reasoning: It's obvious what you really mean, and there's really no reason a temporary has to be constructed then transferred to the named variable.

No, because it should be possible to substitute a function, even returning a derived type, on the RHS.

Remember, "atomic<int> a = {0};" is already interpreted as "atomic<int> a{0};”.

Not at the language level; those behave differently given an explicit constructor.

"{0}" just by itself is an initializer_list<int>,

Not by a long shot.

yet atomic<int> has no initializer_list<int> constructor, so that has to be what the interpretation of what's happening is - the "{0}" is not "an initializer list", but rather "the initializer list for the atomic being constructed". This is already a context were the "normal" rules of "=" just don't apply.

The normal rule of = is lvalue-to-rvalue conversion on the RHS. As far as I know, pre-conversion to a temporary of the initialized type is a mere historical artifact. It would be interesting to see a well-researched proposal to regularize = x initializers with = {x}. I’m sure the guys who drafted the copy-list-initialization spec thought about the difference, and such research should not overlook the generalized initializer list proposals, which are numerous and deep.

What I'm proposing is basically just interpreting "atomic<int> a = atomic<int>{0};" as "atomic<int> a atomic<int>{0};", then dropping the redundant repetition of the type. (But, of course, ONLY in the case where the type actually is repeated.)
 

True, you’re proposing to guarantee elision of that copy. But copy elision was never intended as a pillar of the language. Things are supposed to work without it; it’s not a failsafe bypass around the lvalue-to-rvalue conversion.

 
Yes, and I am proposing to change that - in this one, specific syntactic construct. That's why elision is mentioned in the topic.

Applying it for class conversion expressions but not function calls: is that really going to improve teachability? Much less real-life usability?

Maybe it’s time to recognize the “almost” in AAA.

You're right, the current state of affairs is that elision is optional in all cases, even in the case that I'm focused on. My argument is if we change that rule just in this specific case, to make the elision effectively required - and "required" to the point that there is no moving at all, even conceptually - we gain:

• guaranteed efficiency (as opposed to almost-certain but not required efficiency)
• and a practical solution to the initialization madness that works in all cases (though may not do precisely what you specifically need in a specific case, in which case you still have the other options).
  

The only purposes behind keeping the requirement that the type be copy/movable are either a) to maintain language purity wrt the distinction of value/non-value types, or b) because it is a practical way to actually distinguish between value/non-value types in generic code.

For (a), I say that goal is already a lost cause, in this context. There are so many peculiarities in the interpretations of the various construction syntaxes, that this doesn't really seem the right place to be adamant about drawing this line.

You seem to be implicitly admitting that others have a broader perspective than yourself, but that you’re not willing to see the forest for the trees.

There’s no particular reason to expect AAA to work generically. It’s a recent invention since C++11, unrelated to earlier practice. Maybe a language can be designed around it, but a comprehensive retrofit to C++ is unlikely.

That said, given my accessor lifetime extension proposal and another one (not updated for Kona, but not dead) N4149 regarding expression template conversions, you could do

auto guard = make_guard();

wherein the “value” of a guard cannot be moved to a new object, but it can generate an accessor view to itself, leading to its self-preservation.

For (b), I say: nobody does it for that purpose, nobody would understand that's what the intention was if it was actually used for that purpose, there are several other - better - ways of achieving the same goal, and finally, it just don't work anyway. There are more requirements to having value semantics than just being copy/movable, so a type that does not have value semantics but is copy/movable would pass the bar.

Value vs. non-value isn’t black and white. Not sure exactly what goal you’re supposing.

To be sure, a template over numeric types should not accept atomic<int>. It’s a facility for managing integers safely against multithreaded aliasing. It can store and retrieve an integer value, even up to implicitly converting both ways, but that doesn’t actually make it a number.

Sure, it takes time to teach that to a student. But I think that’s time well spent.

Given that the syntax doesn't actually distinguish anything but whether the type is non-copy/non-movable or not - it doesn't actually serve the purpose of detecting value semantics - and that construction in general is already a context where some things that look like copies/moves are not actually, I think we can get away with repurposing it, and gaining clarity and sanity in one of the most basic and important parts of the language: constructing objects.

Maintaining sanity requires acknowledging subtle complexity.

It’s not too much to teach that 1) class value is the information that gets preserved by the lvalue-to-rvalue conversion, 2) as applied to the RHS of =, and 3) implemented by the copy and move constructors. This is not subtle; it should already be foundational knowledge. However, you can fairly substitute auto&& for auto as a fallback, and still call it AAA.

FWIW, to me, it’s a contortion to require that declarations should all begin with auto, and any resulting pain is deserved. If it hurts, stop doing it.

[Tomasz]

W dniu sobota, 12 września 2015 02:20:03 UTC+2 użytkownik Mark A. Gibbs napisał:

No initialization syntax is perfect. But the difference between your example and mine is that mine is a plausible update to a code base to accommodate growth, whereas yours is really just a really dumb refactoring decision that someone hoped that compiler would spare them from the consequences of. The "auto" version catches the plausible modification, but misses the terrible refactoring job. The non-"auto" version catches the really dumb change that should never happen, but fails to catch the plausible modification. Frankly, I'd prefer the "auto" result, in practice. Oh, also, the "auto" version will crash the very first time the code that puts the result of createDerived() in a unique_ptr gets called - basically day 1 of testing - and debug mode will give you a message about the double-delete... meanwhile the bug in the non-"auto" version could go for years without being detected, unless and and until there happens to be a case when the result of get_count() is too large, which may only happen sporadically and be hard to reproduce. Advantage: auto.

The same advantage applies for int x{get_count()} and this advantage applies only for the build-in arithmetic types that allows numeric conversion. 

Back to your example, relying on the semantics of "type x = factory_function();" is a bad idea. Unless you put a comment next to it explicitly explaining that that's what you intend, you risk someone coming along and thinking that "type x{factory_function()};" is a better idea, because it prevents narrowing, or something similar. The smart thing to do is this:

Again, such refactoring only give a gains for a small set of types, i.e. built in arithmetic types, that allows narrowing conversion. The type x = factory_function() prevents explicit conversion for every other type. That is way I do not like pomotion of auto x = type{expr} syntax - the gain is achieved for very small set of types, versus possible safety loss of others.

 

template <typename T, typename U>
auto as(U&& u) -> T
{
  return {u};
}

auto s = as<std::chrono::seconds>(get_timeout());
// or if you prefer a different name:
auto s = implicitly_as<std::chrono::seconds>(get_timeout());
auto s = safely_as<std::chrono::seconds>(get_timeout());

That will catch unwanted explicit conversions... and it will catch narrowing (and if you don't want that, drop the braces)... and it is self-documenting in code. And if you don't use the auto there, you have to repeat the type, which is a bad idea. For auto, I think that's game, set, and match.

The new C++ cast was designed, they was intended to be long and ugly, to give a visible hint that something may be wrong. You are currently proposing that:
auto s = type{expr};
Syntax should be used for unsafe conversions. And:

auto s = as<std::chrono::seconds>(get_timeout());

auto s = implicitly_as<std::chrono::seconds>(get_timeout());
auto s = safely_as<std::chrono::seconds>(get_timeout());

For the one that was marked as safe by author of the class.
 

Perhaps those of us who want to "force" everyone to use the "shiny new auto" have given this a bit more thought than you give us credit for.

Anyway, to be clear, I am not proposing a way to initialize objects that will solve every single possible problem imaginable. I am just proposing a way that will work for every type, and do a sensible thing in all cases. It may not work precisely the way you need it to for your specific instance, in which case you can use a more specific form.

I do not think that invoking conversion that was marked as unsafe by the class author (marked explicit) is sensible default. And the avoidance of narrowing conversion for small set of types, does not justify it.

[Markus Grech]

Uniform initialization was one of the biggest mistakes in the language to date. I can therefore only agree with the idea to fix this issue to provide a true uniform syntax. Please do not forget arrays however, something like the following should work as well:

auto x = int[]{ 1, 2, 3 };

Not sure if this is doable without ambiguities.

[Martin Molzer]

Just want to post a question I asked on stackoverflow where a comment was that my code wasn't future proof. It was about a class that could not be created on the heap, relying on a deleted copy and move constructor and the fact that you can capture such a variable in a temporary:

http://stackoverflow.com/questions/34948403/

This proposal would destroy that use case, if it'd go through and actually open up a problem for me if there was no way to suppress the behaviour for a specific class.

I have no proposition on how to tell the compiler that a specific class would not allow copy/move elision but if it would, to be consistent, I'd make it forbidden to do so, even in the cases that are currently allowed by the standard. But there should be a way to forbid/restrict - see private/protected move and copy constructors.

[Nicol Bolas]

On Saturday, January 23, 2016 at 9:13:48 PM UTC-5, Martin Molzer wrote:

Just want to post a question I asked on stackoverflow where a comment was that my code wasn't future proof. It was about a class that could not be created on the heap, relying on a deleted copy and move constructor and the fact that you can capture such a variable in a temporary:

http://stackoverflow.com/questions/34948403/

This proposal would destroy that use case, if it'd go through and actually open up a problem for me if there was no way to suppress the behaviour for a specific class.

... and?

Here's the thing: C++ has no way to do what you want. And the language features you are (ab)using to achieve it are not intended to provide that functionality. So there's no reason we shouldn't have mandatory elision just because it stops you from doing this.

It would be far better to propose a language feature that would actually allow you to declare a class which can be forbidden from being heap allocated. Everyone would be better off that way.

Also, it would allow users to stack allocate them and return them, through forced elision, to whomever needed them within their scope. Thus making stack-only classes more inherently useful. There could also be syntax for storing them as NSDMs of other stack-only classes, again making it more useful than your narrow use case.
 

I have no proposition on how to tell the compiler that a specific class would not allow copy/move elision but if it would, to be consistent, I'd make it forbidden to do so, even in the cases that are currently allowed by the standard. But there should be a way to forbid/restrict - see private/protected move and copy constructors.

Forbidding or restricting what can and cannot be elided adds complexity for little gain. Again, simply providing syntax to say that this class cannot be heap allocated would be better.

[Vishal Oza]

would your  idea be something like this:

class foo stackonly
{
//
};

where the keyword stackonly tell the compiler to not ever use new or delete to allocate the object?
 

[Patrice Roy]

Wouldn't that choice of words imply introducing the very concept of a stack in the standard? As far as I know, it's not there currently (it's a good thing in some ways, and an annoyance in others).

Just asking...

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

[Nicol Bolas]

On Sunday, January 24, 2016 at 8:11:01 PM UTC-5, Patrice Roy wrote:

Wouldn't that choice of words imply introducing the very concept of a stack in the standard? As far as I know, it's not there currently (it's a good thing in some ways, and an annoyance in others).

We're not making a formal proposal; we know what we're talking about, so using loose language is fine.

My point was simply that his backdoor method for making such types would be better handled by an explicit feature, not by gimping a genuinely useful feature like guaranteed elision.

[Patrice Roy]

Cool; there's something there, though, which explains my enquiry.

For threads, there's an actual need for offering a way to specify the required stack size at construction time (this cannot be achieved with most operating systems once the thread has been created, which excludes using native_handle), so we'll have to work something on that side for some (important) specialized users.

It's not the subject of this discussion, so I did not want to pollute the exchanges with this topic (peripheral for the moment), but should the relation-to-stack issue remain relevant, we might have cross-concerns here.

Cheers!

--