220 25070 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: new auto Date: Tue, 8 Mar 2016 11:43:37 -0800 (PST) Lines: 524 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_751_1898878374.1457466217796" X-Trace: ger.gmane.org 1457466230 22054 80.91.229.3 (8 Mar 2016 19:43:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Mar 2016 19:43:50 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB26W7S3AKGQEWDIHHLI@isocpp.org Tue Mar 08 20:43:50 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f70.google.com ([209.85.192.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1adNXg-0007AF-Oa for gclcip-std-proposals@m.gmane.org; Tue, 08 Mar 2016 20:43:41 +0100 Original-Received: by mail-qg0-f70.google.com with SMTP id w19sf23612798qgw.1 for ; Tue, 08 Mar 2016 11:43:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive:sender :list-subscribe:list-unsubscribe; bh=VM98wV9Oqq3A1yqiA5qCiDvkKwaZxF/tdTUmAKlYR7Y=; b=GpMakCr+KLIT1/D4yWhqrdkMB20eYi7oJ3dKhyyu+oqRTnrqKBAjZQ/DU3Bu+Uq8A/ RCZb0JvSs6WKiavThq66JWLsUKDFDqMfFPXHLEuYmHJzme30wtoKyMfGIYYBKov34K5f QQN084v75KM33OCeS7Py9yPogXqIORsoHie+kyvcPJ4amc4+IqhUYx5Z4MkCD6zZODBg IoYPWORDEC7OkPro8loBGOyr9tvuAXKaOZG8+U9dAFOHneXJHOx1JzkUdrfq+S8P9asM qSuPN8RM/pyyijkLzUanBH8lU4k4fovahcv2joYk4CXoipPabLPZrDNigvTVukl8ZuNN gecA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive:sender :list-subscribe:list-unsubscribe; bh=VM98wV9Oqq3A1yqiA5qCiDvkKwaZxF/tdTUmAKlYR7Y=; b=oZZO2mDD5yGf3XEPoyk8BdC0YJdb8V0zhSt5dgrvVp5TaGrqgqnllM68/mtcTZtkky yd2Z0e6sYDhFr7zU90egHADJxpBI12T1yo/fx+7gCb+BB6okOg0tMnhEebVafzGFy3rx Zrv37p1x3+yauV0vmq0wSEAm7u8Va+PTAx21z48oPZ97EFHj7zcP5Ap10hi3ITXI8fF6 1Kc0zReKrqSqV8N1gFAdzLzXYhosrH6hwXFAMHCPrFFHXUWiymo4dW0lvwp4BQk+r9MI L60HOwhxK7NZwM+Vvp9fx/ru16GtG/Xdhpcri/MKxTFDjA8+lpRxDf7hKF9qaibSqS0Y owVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:sender:list-subscribe:list-unsubscribe; bh=VM98wV9Oqq3A1yqiA5qCiDvkKwaZxF/tdTUmAKlYR7Y=; b=WMuD+3Nf9bpwEMCgoxfZlIgliW3o8ctiShlxaFSOzJgi99SzyTN+gzKU3eDkjq/m4K SinOc1yVbFqsoH/IzBbvbCzgBg8Flp9AWZHuXbHMbwBZ/3NVzvS87Pdae67fEzxWKwsI pxTnuuVi89qak74NUt3W+mFOdPpYDDSlDmW/cr06S1QlB17R5HxlT6Qh0oSFYzs0OQkw ft24LGFSUonYYaTwID7bwIFluAPMSNZprEn+owq8qt6b0ag6o5okTbtFXWH1oV3ySr67 9LZc8UEIHAF6QJJd2Ov9KTnb3jkEEq/nzuVFnH4b795OFLMG19QPH5ovRvBMjd2YICXk 0HPw== X-Gm-Message-State: AD7BkJJ4CdhXTVqK5a6f7OGewev5lYlv1KfJi+R7w2vbKMTUSlMcRhsTHheBZTBRWrQa2w== X-Received: by 10.140.221.134 with SMTP id r128mr921589qhb.0.1457466219897; Tue, 08 Mar 2016 11:43:39 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.3.14 with SMTP id 14ls391714iod.2.gmail; Tue, 08 Mar 2016 11:43:38 -0800 (PST) X-Received: by 10.50.103.68 with SMTP id fu4mr379808igb.9.1457466218794; Tue, 08 Mar 2016 11:43:38 -0800 (PST) In-Reply-To: X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: Original-Sender: std-proposals@isocpp.org List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:25070 Archived-At: ------=_Part_751_1898878374.1457466217796 Content-Type: multipart/alternative; boundary="----=_Part_752_734926934.1457466217798" ------=_Part_752_734926934.1457466217798 Content-Type: text/plain; charset=UTF-8 On Tuesday, March 8, 2016 at 1:34:05 PM UTC-5, Dale Weiler wrote: > > Exibit > class A { > A(); > T *a; > }; > > > Need to know type of *a* here to call new correctly: > A::A() : a(new T) { } > > Imagine the class member type changes but implementing code stays the > same, thus it allocates an incorrect amount of memory for the object and > calls the wrong constructor. > > Unless the new type `U` has an implicit conversion from `T*` to `U*` (for example, if `U` is a base class of `T`), you get a *compiler error*, not allocating "an incorrect amount of memory". How do we solve this? > > I don't think this is a problem that needs to be solved. > A::A() : a (new typename remove_reference::type) { } > > > Not that pretty but does handle this case. What's interesting is in these > contexts the compiler knows the type from the binding side: > T *a = new T; > T *b(new T); > > > We can see this is true with container types too: > unique_ptr a = make_unique(...); > unique_ptr b(new T(...)); > shared_ptr c = make_shared(...); > shared_ptr d(new T(...)); > > Lets review our original example now with *new auto:* > A::A() : a(new auto) { } > > Changes of the class member type does not affect implementing code, > since *auto* knows the type > > Consistent with other forms of initialization as well: > T *a = new auto; > T *a(new auto); > > Ambigious > *new auto(expr)* already exists in C++, it's defined such that new allocates > storage for type of *expr* and constructs with value of *expr*. > > We argue this behavior is inconsistent with the rest of the language as*auto* is treated as a non-type and as a function-style cast in this example. > > How is it inconsistent? `new auto(expr)` doesn't treat `auto` as a type anymore than `auto x = expr` does. It treats `auto` as a type to be deduced based on `expr`. And let's pretend that it is inconsistent. So what? Being able to do `new auto(expr)` is *very useful*; you shouldn't take that away for something that is decidedly less useful. With explicit initialization this would be preferred behavior of the syntax, > which shouldn't break anything either: > T *a = new auto(...); > T *b(new auto(...)); > > Assuming existing C++ code uses *new auto(expr)*, the binding > side of the expression must have same type as the new expression, > otherwise a compile error results. The only time this is not the case > is when a *reinterpret_cast* is used on the result of the new expression which > is undefined unless the pointer types are compatible. When the binding side > is of the same type as the new expression the result is consistent with > this proposal and does not break existing C++ code that uses *new auto(expr)*. > > Unless of course you want to do this: auto p = new auto(expr); Where the type of `p` is determined based on the type of `expr`. Breaking existing programs is a non-starter for something like this. Visibility > > What we obtain is improved visibility for containment and consistency > with respect to *auto* and other language syntax. > > For example *make_unique* and *make_shared* can be made much simpler and > better: > template > unique_ptr make_unique(A&&... a) { > // Note we don't use new T here since that prevents visibility > return { new auto(forward(a)...) }; > } > template > shared_ptr make_shared(A&&... a) { > // Ditto no use of new T here either > return { new auto(forward(a)...) }; > } > > > Now *make_unique* and *make_shared* can access private constructors, > since `auto` avoids the visibility problem in this construct: > > class A { > A() { ... } > public: > void x() { > auto x = make_unique(); // Works! > ... > } > }; > > However outside class scope: > auto x = make_unique(); // Does not work since private (as expected) > > That... makes absolutely no sense. You are suggesting that we require the compiler to decide whether the code within that function is legal or not based on where it *gets called from*? That's *insane*. Even in the context of template instantiation, you're violating the One Definition Rule. The reason being that `make_unqiue` is a function. And in every translation unit, that function must have the same definition for the same A. You can't make one version of `make_unique` callable and a different version not callable based on where you call it from. If you want to allow some from of private forwarding, then you're going to have to do it the hard way. Like this: class A { static key_type key_; public: explicit A(key_type) { ... } void x() { auto x = make_unique(key_); // Works! ... } }; auto x = make_unique(A::key_); //Access to `A::key_` is restricted. Furthermore, this doesn't solve the visibility problem for things like `make_tuple`, since it doesn't use `new` at all. -- 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-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eaca51a5-050f-43f7-a4f0-84ea17ed9d90%40isocpp.org. ------=_Part_752_734926934.1457466217798 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, March 8, 2016 at 1:34:05 PM UTC-5, Dale Weiler= wrote:
E=
xibit


class A {
=C2=A0 A();
=C2=
=A0 T *=
a;
<=
/span>};


Need to know type of a here to call new correctly:

=C2=A0A::<=
span style=3D"color:#000">A() : a(new T) { }

Imagine the class member type changes but implementing code stays the
same, thus it allocates an incorrect amount of memory for the object and
calls the wrong constructor.

Unless the new type= `U` has an implicit conversion from `T*` to `U*` (for example, if `U` is a= base class of `T`), you get a compiler error, not allocating "= an incorrect amount of memory".

 How do we solve this?

I don't think this is a problem that needs to be solved.
=C2=A0= 
A::A() : a (new<=
span style=3D"color:#000"> typename remove_reference<decltype(A::a=
)>::type) { }=



Not that pretty but does handle this case. What's interesting is in the=
se
contexts the compiler knows the type from the binding side:
T *a =3D new T;
T *b(ne=
w T);


We can see this is true with container types too:

unique_ptr<T> a =3D make_unique&=
lt;T>=
;(...);
unique_ptr<T> b(new T(...));
shared_ptr<=
T> c =3D make_shared<<=
/span>T>(..=
..); 
shared_ptr<T> d(new T(...));

Lets review our original example now with new auto:

A::A() : a(new auto) { }

Changes of the class member type does not affect =
implementing code,
since auto knows the type

Consistent with other forms of initialization as well:
T *a =3D new <=
/span>auto;
T *a(<=
span style=3D"color:#008">new auto);


Ambigious

new auto(expr) already exists in C++, it's defined such that new=
 allocates
storage for type of expr and constructs with value of =
expr.

We argue this behavior is inconsistent with the rest of the language as
auto is treated as a non-type and as a function-style cast in this e=
xample.

How is it inconsistent? `new auto(expr)`= doesn't treat `auto` as a type anymore than `auto x =3D expr` does. It= treats `auto` as a type to be deduced based on `expr`.

And let'= s pretend that it is inconsistent. So what? Being able to do `new auto(expr= )` is very useful; you shouldn't take that away for something th= at is decidedly less useful.

With explicit initialization this would be preferred behav=
ior of the syntax,
which shouldn't break anything either:

T *a =3D new auto(...);
T *b(new auto(...));

Assuming existing C++ code uses <=
b>new auto(expr), the binding
side of the expression must have same =
type as the new expression,
otherwise a compile error results. The only =
time this is not the case
is when a reinterpret_cast is used on t=
he result of the new expression which
is undefined unless the pointer ty=
pes are compatible. When the binding side
is of the same type as the new=
 expression the result is consistent with
this proposal and does not bre=
ak existing C++ code that uses new auto(expr).

Unless of course you want to do this:

auto p =3D new a= uto(expr);
=

Where the type of `p` is determined based on the type of `expr`.<= br>
Breaking existing programs is a non-starter for something like this.= 

Visibility

What we obtain is improved visibility for c=
ontainment and consistency
with respect to auto and other language syntax.

For example make_unique and make_shared can be made much simp=
ler and=20
better:

template <=
span style=3D"color:#660"><typename T,=
 typename A...>
unique_ptr<T> make_unique(A&&... a) {
=C2=A0 // Note we don't use new T here since that prevents vis=
ibility
=C2=A0 return { new auto(forward<A>(a)...) };<=
br>}template <=
typename T, ty=
pename A...>
shared_ptr<T> make_shared(A&&... a) {
=C2=A0 // Ditto no use of new T here either
=C2=A0 return<=
/span> { new auto(forward<A>(a)...) };
} 
=



Now make_unique and make_shared can access private constructo=
rs,
since `auto` avoids the visibility problem in this construct:
class A {
=C2=A0 A() { ... }
public:
=C2=A0 void x() {
=C2=A0 =C2=A0 auto x =3D make_unique<A>();<=
span style=3D"color:#000"> // Works!
=C2=A0 =C2=A0 ...
=C2=A0 }
};

However outside class scope:
auto x =3D make_unique<=
A>(); // Does not =
work since private (as expected)


That... makes absolute= ly no sense. You are suggesting that we require the compiler to decide whet= her the code within that function is legal or not based on where it gets= called from? That's insane.

Even in the context of t= emplate instantiation, you're violating the One Definition Rule. The re= ason being that `make_unqiue<A>` is a function. And in every translat= ion unit, that function must have the same definition for the same A. You c= an't make one version of `make_unique` callable and a different version= not callable based on where you call it from.

If you want to allow = some from of private forwarding, then you're going to have to do it the= hard way. Like this:

class A {
= =C2=A0 sta= tic key_ty= pe key_;
<= span style=3D"color: #008;" class=3D"styled-by-prettify">public:
=C2=A0 explicit A(key_type) { ... }


=C2=A0 void x() {
=C2=A0 =C2=A0 auto x =3D make_unique<= A>(key_); // Works!
=C2=A0 =C2=A0 ...
=C2=A0 }
};

auto x =3D mak= e_unique&l= t;A= >(A::key_); //Access to `A::key_` is restricted.

Furthermore, this doesn't solve the visibility problem for things= like `make_tuple`, since it doesn't use `new` at all.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/eaca51a5-050f-43f7-a4f0-84ea17ed9d90= %40isocpp.org.
------=_Part_752_734926934.1457466217798-- ------=_Part_751_1898878374.1457466217796-- .