------=_Part_2182_4002164.1398562093313
Content-Type: text/plain; charset=UTF-8

Experience with C++11 and implementing some larger codebases targetting the
newer standards has led me (and, I feel, many of the rest of us) to prefer
unique_ptr over raw pointers in a large number of situations. Raw pointers
can go completely unused in many applications, possibly even most
applications, though obviously not all of them.

I've personally always been of the opinion that the common case (the things
you do most often) should be easier to do than the uncommon case in any
language or API. This is unfortunately totally untrue for large swaths of
C++, but pointers and unique_ptr are a particularly large pain point that
is more easily rectified than many other features in an easily
backward-compatible way.

Adding a new built-in for handling uniquely-owned pointers is IMO a good
idea. These would not wholly replace unique_ptr due to the latter's ability
to define custom deleters but a built-in would handle the common case.

Bike-shedding aside, I'd lean towards using ~ as a sigil for these types of
pointers like Rust does (albeit with a different grammar). I'd considered ^
since it's the popular choice for new pointer types but that's used for
shared-ownership semantics in C++CLI and C++RT so that seems like it might
be confusing.

This feature would also need a replacement for make_unique, of course. As a
first-try syntax, new Foo~ or new~ Foo comes to mind. I would suggest
making raw pointers not implicitly convertible to owned pointers, so code
like `Foo~ ptr = new Foo` would be a compilation error and `auto ptr = new~
Foo` would correctly give ptr the type Foo~. I'd prefer if the
new-replacement were more obvious than raw new, but I don't have any good
ideas on how to achieve that. An additional operator set (operator new~ and
operator delete~) could be defined that "fixes" some of the short-comings
of new/delete (always include sized-delete, always include alignment) and
which allows boxed items to be dealt with specially more easily or they
could of course just use the existing operators but result in a T~ instead
of a T*.

I'm not (yet) thinking much about handling uniquely-owned arrays. There's
definitely use cases for unique_ptr<T[]> (or a T~[] if you will) but one
could argue that any new variants of arrays should handle slices or be
aware of size or even handling resizing (and you can easily argue against
those) so I'm just not going to touch it for now. No arrays.

I have no strong opinion on whether uniquely-owned pointers would be
implicitly convertible to raw pointers. unique_ptr doesn't convert
implicitly, so I'd lean towards following that example.

I'm of the personal opinion that shared-ownership semantics (shared_ptr)
should be _much_ more rarely used and I actually prefer that they be as
unattractive as possible to avoid overuse, so I'm not personally interested
in proposing any built-in version of those (and they'd be much more
difficult to implement into the core language anyway; pass).

The benefits of built-in uniquely-owned pointers would be:
 - Uniquely-owned pointers become as easy to use as raw pointers (as
concise, no headers required, etc.)
 - Potentially improved compile times for some TUs (no need to pull in all
of <memory>)
 - `new~` (or equivalent syntax) doesn't have the associated danger and
ease-of-misuse that plain `new` has regarding exception-safety
 - The language is a bit simpler to teach; no need to explain headers and
templates and smart pointer classes just to (safely) handle free-store
allocation
 - Free-store-allocated objects finally become easier to use than they are
in C (again, no headers, no templates or pointer classes just to be safe)

Cons:
 - The usual cost of adding new language syntax and semantics to an
established language
 - Another sigil in a grammar that's already a little sigil-heavy in some
people's eyes
 - Would be (I think) the first primitive type that has a non-trivial
default constructor, non-trivial destructor, and is non-copyable
   (references already have deleted default constructors so this wouldn't
be the first non-POD type)

I'll likely write up a proposal for this some day no matter what, but any
thoughts that might help guide said paper would be appreciated ("don't
bother" comments included, though I'll most likely be stubborn and not
listen).

Some examples of syntax using the ~ sigil, just as food for thought, would
be:
 T~ ptr; // owned pointer to T
 T*~ pptr; // owned pointer to T*
 T&~ pref; // ILLEGAL, same as T&*
 T~* pptr; // raw pointer to T~
 T~& rptr = ptr; // reference to T~
 T const~ ptr; // owned pointer to a const T
 T ~const ptr; // const owned pointer to T, pointer cannot be assigned to
or moved from
 vector<T~> ptrs; // vector of owned pointers to T
 auto func(T~ ptr); // function taking an owned pointer to T
 auto func() -> T~; // function returning an owned pointer to T
 T~~ pptr; // owned pointer to an owned pointer to T
 T~ ptrs[]; // array of owned pointers to T
 new~ T{}; // owned pointer to an allocated and initialized T
 delete ptr; // ILLEGAL, cannot delete an owned pointer
 delete~ ptr; // UNSUPPORTED, no need for this, just assign nullptr instead
 T ptr~[]; // NOT part of this, but a possible extension to allow owned
arrays

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_2182_4002164.1398562093313
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Experience with C++11 and implementing some larger codebas=
es targetting the newer standards has led me (and, I feel, many of the rest=
 of us) to prefer unique_ptr over raw pointers in a large number of situati=
ons. Raw pointers can go completely unused in many applications, possibly e=
ven most applications, though obviously not all of them.<div><br></div><div=
>I've personally always been of the opinion that the common case (the thing=
s you do most often) should be easier to do than the uncommon case in any l=
anguage or API. This is unfortunately totally untrue for large swaths of C+=
+, but pointers and unique_ptr are a particularly large pain point that is =
more easily rectified than many other features in an easily backward-compat=
ible way.</div><div><br></div><div>Adding a new built-in for handling uniqu=
ely-owned pointers is IMO a good idea. These would not wholly replace uniqu=
e_ptr due to the latter's ability to define custom deleters but a built-in =
would handle the common case.</div><div><br></div><div>Bike-shedding aside,=
 I'd lean towards using ~ as a sigil for these types of pointers like Rust =
does (albeit with a different grammar). I'd considered ^ since it's the pop=
ular choice for new pointer types but that's used for shared-ownership sema=
ntics in C++CLI and C++RT so that seems like it might be confusing.</div><d=
iv><br></div><div>This feature would also need a replacement for make_uniqu=
e, of course. As a first-try syntax, new Foo~ or new~ Foo comes to mind. I =
would suggest making raw pointers not implicitly convertible to owned point=
ers, so code like `Foo~ ptr =3D new Foo` would be a compilation error and `=
auto ptr =3D new~ Foo` would correctly give ptr the type Foo~. I'd prefer i=
f the new-replacement were more obvious than raw new, but I don't have any =
good ideas on how to achieve that. An additional operator set (operator new=
~ and operator delete~) could be defined that "fixes" some of the short-com=
ings of new/delete (always include sized-delete, always include alignment) =
and which allows boxed items to be dealt with specially more easily or they=
 could of course just use the existing operators but result in a T~ instead=
 of a T*.</div><div><br></div><div>I'm not (yet) thinking much about handli=
ng uniquely-owned arrays. There's definitely use cases for unique_ptr&lt;T[=
]&gt; (or a T~[] if you will) but one could argue that any new variants of =
arrays should handle slices or be aware of size or even handling resizing (=
and you can easily argue against those) so I'm just not going to touch it f=
or now. No arrays.</div><div><br></div><div>I have no strong opinion on whe=
ther uniquely-owned pointers would be implicitly convertible to raw pointer=
s. unique_ptr doesn't convert implicitly, so I'd lean towards following tha=
t example.</div><div><br></div><div>I'm of the personal opinion that shared=
-ownership semantics (shared_ptr) should be _much_ more rarely used and I a=
ctually prefer that they be as unattractive as possible to avoid overuse, s=
o I'm not personally interested in proposing any built-in version of those =
(and they'd be much more difficult to implement into the core language anyw=
ay; pass).<br></div><div><br></div><div>The benefits of built-in uniquely-o=
wned pointers would be:<br></div><div>&nbsp;- Uniquely-owned pointers becom=
e as easy to use as raw pointers (as concise, no headers required, etc.)</d=
iv><div>&nbsp;- Potentially improved compile times for some TUs (no need to=
 pull in all of &lt;memory&gt;)</div><div>&nbsp;- `new~` (or equivalent syn=
tax) doesn't have the associated danger and ease-of-misuse that plain `new`=
 has regarding exception-safety</div><div>&nbsp;- The language is a bit sim=
pler to teach; no need to explain headers and templates and smart pointer c=
lasses just to (safely) handle free-store allocation</div><div>&nbsp;- Free=
-store-allocated objects finally become easier to use than they are in C (a=
gain, no headers, no templates or pointer classes just to be safe)</div><di=
v><br></div><div>Cons:</div><div>&nbsp;- The usual cost of adding new langu=
age syntax and semantics to an established language</div><div>&nbsp;- Anoth=
er sigil in a grammar that's already a little sigil-heavy in some people's =
eyes</div><div>&nbsp;- Would be (I think) the first primitive type that has=
 a non-trivial default constructor, non-trivial destructor, and is non-copy=
able</div><div>&nbsp; &nbsp;(references already have deleted default constr=
uctors so this wouldn't be the first non-POD type)<br></div><div><br></div>=
<div>I'll likely write up a proposal for this some day no matter what, but =
any thoughts that might help guide said paper would be appreciated ("don't =
bother" comments included, though I'll most likely be stubborn and not list=
en).</div><div><br></div><div><div>Some examples of syntax using the ~ sigi=
l, just as food for thought, would be:</div><div>&nbsp;T~ ptr; // owned poi=
nter to T</div><div>&nbsp;T*~ pptr; // owned pointer to&nbsp;T*</div><div>&=
nbsp;T&amp;~ pref; // ILLEGAL, same as T&amp;*&nbsp;</div><div>&nbsp;T~* pp=
tr; // raw pointer to T~</div><div>&nbsp;T~&amp; rptr =3D ptr; // reference=
 to T~</div><div>&nbsp;T const~ ptr; // owned pointer to a const T</div><di=
v>&nbsp;T ~const ptr; // const owned pointer to&nbsp;T,&nbsp;pointer cannot=
 be assigned to or moved from</div><div>&nbsp;vector&lt;T~&gt; ptrs; // vec=
tor of owned pointers to T</div><div>&nbsp;auto func(T~ ptr); // function t=
aking an owned pointer to T</div><div>&nbsp;auto func() -&gt;&nbsp;T~; // f=
unction returning an owned pointer to T</div><div>&nbsp;T~~ pptr; // owned =
pointer to an owned pointer to T</div><div>&nbsp;T~ ptrs[]; // array of own=
ed pointers to T</div><div>&nbsp;new~&nbsp;T{}; // owned pointer to an allo=
cated and initialized T<br></div></div><div>&nbsp;delete ptr; // ILLEGAL, c=
annot delete an owned pointer</div><div>&nbsp;delete~ ptr; // UNSUPPORTED, =
no need for this, just assign nullptr instead</div><div>&nbsp;T&nbsp;ptr~[]=
; // NOT part of this, but a possible extension to allow owned arrays<br></=
div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2182_4002164.1398562093313--

.

------=_Part_20_3412686.1398602048375
Content-Type: text/plain; charset=UTF-8

On Sunday, April 27, 2014 1:28:13 PM UTC+12, Sean Middleditch wrote:
>
> Experience with C++11 and implementing some larger codebases targetting
> the newer standards has led me (and, I feel, many of the rest of us) to
> prefer unique_ptr over raw pointers in a large number of situations. Raw
> pointers can go completely unused in many applications, possibly even most
> applications, though obviously not all of them.
>
> I've personally always been of the opinion that the common case (the
> things you do most often) should be easier to do than the uncommon case in
> any language or API. This is unfortunately totally untrue for large swaths
> of C++, but pointers and unique_ptr are a particularly large pain point
> that is more easily rectified than many other features in an easily
> backward-compatible way.
>
> Adding a new built-in for handling uniquely-owned pointers is IMO a good
> idea. These would not wholly replace unique_ptr due to the latter's ability
> to define custom deleters but a built-in would handle the common case.
>
> Bike-shedding aside, I'd lean towards using ~ as a sigil for these types
> of pointers like Rust does (albeit with a different grammar). I'd
> considered ^ since it's the popular choice for new pointer types but that's
> used for shared-ownership semantics in C++CLI and C++RT so that seems like
> it might be confusing.
>
> This feature would also need a replacement for make_unique, of course. As
> a first-try syntax, new Foo~ or new~ Foo comes to mind. I would suggest
> making raw pointers not implicitly convertible to owned pointers, so code
> like `Foo~ ptr = new Foo` would be a compilation error and `auto ptr = new~
> Foo` would correctly give ptr the type Foo~. I'd prefer if the
> new-replacement were more obvious than raw new, but I don't have any good
> ideas on how to achieve that. An additional operator set (operator new~ and
> operator delete~) could be defined that "fixes" some of the short-comings
> of new/delete (always include sized-delete, always include alignment) and
> which allows boxed items to be dealt with specially more easily or they
> could of course just use the existing operators but result in a T~ instead
> of a T*.
>
> I'm not (yet) thinking much about handling uniquely-owned arrays. There's
> definitely use cases for unique_ptr<T[]> (or a T~[] if you will) but one
> could argue that any new variants of arrays should handle slices or be
> aware of size or even handling resizing (and you can easily argue against
> those) so I'm just not going to touch it for now. No arrays.
>
> I have no strong opinion on whether uniquely-owned pointers would be
> implicitly convertible to raw pointers. unique_ptr doesn't convert
> implicitly, so I'd lean towards following that example.
>
> I'm of the personal opinion that shared-ownership semantics (shared_ptr)
> should be _much_ more rarely used and I actually prefer that they be as
> unattractive as possible to avoid overuse, so I'm not personally interested
> in proposing any built-in version of those (and they'd be much more
> difficult to implement into the core language anyway; pass).
>
> The benefits of built-in uniquely-owned pointers would be:
>  - Uniquely-owned pointers become as easy to use as raw pointers (as
> concise, no headers required, etc.)
>  - Potentially improved compile times for some TUs (no need to pull in all
> of <memory>)
>  - `new~` (or equivalent syntax) doesn't have the associated danger and
> ease-of-misuse that plain `new` has regarding exception-safety
>  - The language is a bit simpler to teach; no need to explain headers and
> templates and smart pointer classes just to (safely) handle free-store
> allocation
>  - Free-store-allocated objects finally become easier to use than they are
> in C (again, no headers, no templates or pointer classes just to be safe)
>
> Cons:
>  - The usual cost of adding new language syntax and semantics to an
> established language
>  - Another sigil in a grammar that's already a little sigil-heavy in some
> people's eyes
>  - Would be (I think) the first primitive type that has a non-trivial
> default constructor, non-trivial destructor, and is non-copyable
>    (references already have deleted default constructors so this wouldn't
> be the first non-POD type)
>
> I'll likely write up a proposal for this some day no matter what, but any
> thoughts that might help guide said paper would be appreciated ("don't
> bother" comments included, though I'll most likely be stubborn and not
> listen).
>
> Some examples of syntax using the ~ sigil, just as food for thought, would
> be:
>  T~ ptr; // owned pointer to T
>  T*~ pptr; // owned pointer to T*
>  T&~ pref; // ILLEGAL, same as T&*
>  T~* pptr; // raw pointer to T~
>  T~& rptr = ptr; // reference to T~
>  T const~ ptr; // owned pointer to a const T
>  T ~const ptr; // const owned pointer to T, pointer cannot be assigned to
> or moved from
>  vector<T~> ptrs; // vector of owned pointers to T
>  auto func(T~ ptr); // function taking an owned pointer to T
>  auto func() -> T~; // function returning an owned pointer to T
>  T~~ pptr; // owned pointer to an owned pointer to T
>  T~ ptrs[]; // array of owned pointers to T
>  new~ T{}; // owned pointer to an allocated and initialized T
>  delete ptr; // ILLEGAL, cannot delete an owned pointer
>  delete~ ptr; // UNSUPPORTED, no need for this, just assign nullptr instead
>  T ptr~[]; // NOT part of this, but a possible extension to allow owned
> arrays
>

This is a terrible idea.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_20_3412686.1398602048375
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, April 27, 2014 1:28:13 PM UTC+12, Sean Middledi=
tch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Exp=
erience with C++11 and implementing some larger codebases targetting the ne=
wer standards has led me (and, I feel, many of the rest of us) to prefer un=
ique_ptr over raw pointers in a large number of situations. Raw pointers ca=
n go completely unused in many applications, possibly even most application=
s, though obviously not all of them.<div><br></div><div>I've personally alw=
ays been of the opinion that the common case (the things you do most often)=
 should be easier to do than the uncommon case in any language or API. This=
 is unfortunately totally untrue for large swaths of C++, but pointers and =
unique_ptr are a particularly large pain point that is more easily rectifie=
d than many other features in an easily backward-compatible way.</div><div>=
<br></div><div>Adding a new built-in for handling uniquely-owned pointers i=
s IMO a good idea. These would not wholly replace unique_ptr due to the lat=
ter's ability to define custom deleters but a built-in would handle the com=
mon case.</div><div><br></div><div>Bike-shedding aside, I'd lean towards us=
ing ~ as a sigil for these types of pointers like Rust does (albeit with a =
different grammar). I'd considered ^ since it's the popular choice for new =
pointer types but that's used for shared-ownership semantics in C++CLI and =
C++RT so that seems like it might be confusing.</div><div><br></div><div>Th=
is feature would also need a replacement for make_unique, of course. As a f=
irst-try syntax, new Foo~ or new~ Foo comes to mind. I would suggest making=
 raw pointers not implicitly convertible to owned pointers, so code like `F=
oo~ ptr =3D new Foo` would be a compilation error and `auto ptr =3D new~ Fo=
o` would correctly give ptr the type Foo~. I'd prefer if the new-replacemen=
t were more obvious than raw new, but I don't have any good ideas on how to=
 achieve that. An additional operator set (operator new~ and operator delet=
e~) could be defined that "fixes" some of the short-comings of new/delete (=
always include sized-delete, always include alignment) and which allows box=
ed items to be dealt with specially more easily or they could of course jus=
t use the existing operators but result in a T~ instead of a T*.</div><div>=
<br></div><div>I'm not (yet) thinking much about handling uniquely-owned ar=
rays. There's definitely use cases for unique_ptr&lt;T[]&gt; (or a T~[] if =
you will) but one could argue that any new variants of arrays should handle=
 slices or be aware of size or even handling resizing (and you can easily a=
rgue against those) so I'm just not going to touch it for now. No arrays.</=
div><div><br></div><div>I have no strong opinion on whether uniquely-owned =
pointers would be implicitly convertible to raw pointers. unique_ptr doesn'=
t convert implicitly, so I'd lean towards following that example.</div><div=
><br></div><div>I'm of the personal opinion that shared-ownership semantics=
 (shared_ptr) should be _much_ more rarely used and I actually prefer that =
they be as unattractive as possible to avoid overuse, so I'm not personally=
 interested in proposing any built-in version of those (and they'd be much =
more difficult to implement into the core language anyway; pass).<br></div>=
<div><br></div><div>The benefits of built-in uniquely-owned pointers would =
be:<br></div><div>&nbsp;- Uniquely-owned pointers become as easy to use as =
raw pointers (as concise, no headers required, etc.)</div><div>&nbsp;- Pote=
ntially improved compile times for some TUs (no need to pull in all of &lt;=
memory&gt;)</div><div>&nbsp;- `new~` (or equivalent syntax) doesn't have th=
e associated danger and ease-of-misuse that plain `new` has regarding excep=
tion-safety</div><div>&nbsp;- The language is a bit simpler to teach; no ne=
ed to explain headers and templates and smart pointer classes just to (safe=
ly) handle free-store allocation</div><div>&nbsp;- Free-store-allocated obj=
ects finally become easier to use than they are in C (again, no headers, no=
 templates or pointer classes just to be safe)</div><div><br></div><div>Con=
s:</div><div>&nbsp;- The usual cost of adding new language syntax and seman=
tics to an established language</div><div>&nbsp;- Another sigil in a gramma=
r that's already a little sigil-heavy in some people's eyes</div><div>&nbsp=
;- Would be (I think) the first primitive type that has a non-trivial defau=
lt constructor, non-trivial destructor, and is non-copyable</div><div>&nbsp=
; &nbsp;(references already have deleted default constructors so this would=
n't be the first non-POD type)<br></div><div><br></div><div>I'll likely wri=
te up a proposal for this some day no matter what, but any thoughts that mi=
ght help guide said paper would be appreciated ("don't bother" comments inc=
luded, though I'll most likely be stubborn and not listen).</div><div><br><=
/div><div><div>Some examples of syntax using the ~ sigil, just as food for =
thought, would be:</div><div>&nbsp;T~ ptr; // owned pointer to T</div><div>=
&nbsp;T*~ pptr; // owned pointer to&nbsp;T*</div><div>&nbsp;T&amp;~ pref; /=
/ ILLEGAL, same as T&amp;*&nbsp;</div><div>&nbsp;T~* pptr; // raw pointer t=
o T~</div><div>&nbsp;T~&amp; rptr =3D ptr; // reference to T~</div><div>&nb=
sp;T const~ ptr; // owned pointer to a const T</div><div>&nbsp;T ~const ptr=
; // const owned pointer to&nbsp;T,&nbsp;pointer cannot be assigned to or m=
oved from</div><div>&nbsp;vector&lt;T~&gt; ptrs; // vector of owned pointer=
s to T</div><div>&nbsp;auto func(T~ ptr); // function taking an owned point=
er to T</div><div>&nbsp;auto func() -&gt;&nbsp;T~; // function returning an=
 owned pointer to T</div><div>&nbsp;T~~ pptr; // owned pointer to an owned =
pointer to T</div><div>&nbsp;T~ ptrs[]; // array of owned pointers to T</di=
v><div>&nbsp;new~&nbsp;T{}; // owned pointer to an allocated and initialize=
d T<br></div></div><div>&nbsp;delete ptr; // ILLEGAL, cannot delete an owne=
d pointer</div><div>&nbsp;delete~ ptr; // UNSUPPORTED, no need for this, ju=
st assign nullptr instead</div><div>&nbsp;T&nbsp;ptr~[]; // NOT part of thi=
s, but a possible extension to allow owned arrays<br></div></div></blockquo=
te><div><br></div><div>This is a terrible idea. &nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_20_3412686.1398602048375--

.

On 27 April 2014 04:28, Sean Middleditch <sean.middleditch@gmail.com> wrote:
> Experience with C++11 and implementing some larger codebases targetting the
> newer standards has led me (and, I feel, many of the rest of us) to prefer
> unique_ptr over raw pointers in a large number of situations. Raw pointers
> can go completely unused in many applications, possibly even most
> applications, though obviously not all of them.

Raw pointers can go more completely unused once we have a more comprehensive
set of shared/unique/cloned/dumb.

> I've personally always been of the opinion that the common case (the things
> you do most often) should be easier to do than the uncommon case in any
> language or API. This is unfortunately totally untrue for large swaths of
> C++, but pointers and unique_ptr are a particularly large pain point that is
> more easily rectified than many other features in an easily
> backward-compatible way.

I don't see what the "pain point" is. unique_ptr is a simple library facility
that combines simple core language rules. This is one of the traditional
design guidelines of C++, libraries built on top of a simple core language
being preferable over a more complex core language. Pulling unique_ptr
into the core language would need a VERY strong motivation. I dare claim
unique_ptr isn't even common enough to motivate having its counterpart in
the core language.

> Adding a new built-in for handling uniquely-owned pointers is IMO a good
> idea. These would not wholly replace unique_ptr due to the latter's ability
> to define custom deleters but a built-in would handle the common case.
> Bike-shedding aside, I'd lean towards using ~ as a sigil for these types of
> pointers like Rust does (albeit with a different grammar). I'd considered ^
> since it's the popular choice for new pointer types but that's used for
> shared-ownership semantics in C++CLI and C++RT so that seems like it might
> be confusing.

Well, ~ is used for destructors. I don't see how that would be anything but
confusing to use for a unique_ptr.

> This feature would also need a replacement for make_unique, of course. As a
> first-try syntax, new Foo~ or new~ Foo comes to mind. I would suggest making
> raw pointers not implicitly convertible to owned pointers, so code like
> `Foo~ ptr = new Foo` would be a compilation error and `auto ptr = new~ Foo`
> would correctly give ptr the type Foo~. I'd prefer if the new-replacement

But you would allow Foo~ ptr{new Foo}; ?

> The benefits of built-in uniquely-owned pointers would be:
>  - Uniquely-owned pointers become as easy to use as raw pointers (as
> concise, no headers required, etc.)

They are not supposed to be as easy to use as raw pointers, when it
comes to initializing or copying or converting to void*. Other than that,
they are syntactically just as easy as raw pointers, and easier from
the point of view of cleanup.

>  - Potentially improved compile times for some TUs (no need to pull in all
> of <memory>)

Well, for such improvement, I'd love to see measurement results.

>  - `new~` (or equivalent syntax) doesn't have the associated danger and
> ease-of-misuse that plain `new` has regarding exception-safety

How is new~ better than "plain new" in this regard?

>  - The language is a bit simpler to teach; no need to explain headers and
> templates and smart pointer classes just to (safely) handle free-store
> allocation

I don't think this simplicity will practically amount to much, and now we would
have more to teach, since this proposal will not replace anything, it will
just add more material to the core language to teach.

>  - Free-store-allocated objects finally become easier to use than they are
> in C (again, no headers, no templates or pointer classes just to be safe)

I don't need to teach templates to use a unique_ptr. I can tell people to
use a magical incantation of auto x = make_unique<YourType>();
I will have to teach storage durations regardless of how convenient
you make using a unique_ptr, so avoiding just a header inclusion
doesn't seem like a convincing reason.

> Cons:
>  - The usual cost of adding new language syntax and semantics to an
> established language
>  - Another sigil in a grammar that's already a little sigil-heavy in some
> people's eyes
>  - Would be (I think) the first primitive type that has a non-trivial
> default constructor, non-trivial destructor, and is non-copyable
>    (references already have deleted default constructors so this wouldn't be
> the first non-POD type)

The first two already make this idea a no-go for me. The cons, to me, outweigh
the pros, which are as far as I see it, questionable.

>
> I'll likely write up a proposal for this some day no matter what, but any
> thoughts that might help guide said paper would be appreciated ("don't
> bother" comments included, though I'll most likely be stubborn and not
> listen).

I will vote against the proposal on a national level if need be.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Sun, Apr 27, 2014 at 5:48 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 27 April 2014 04:28, Sean Middleditch <sean.middleditch@gmail.com> wrote:
> Raw pointers can go more completely unused once we have a more comprehensive
> set of shared/unique/cloned/dumb.

And they would all have the same unfortunate situation where `auto p =
new T;` or `void foo(T* p)` are significantly easier to (mis)use than
`#include <memory> auto p = std::make_unique<T>();` or `#include
<memory> void foo(std::unique_ptr<T> p)`, for students and old hats
alike. You are maybe underestimating the laziness of many programmers
(a trait sometimes considered a good thing in software engineering),
perhaps. :)

> This is one of the traditional
> design guidelines of C++, libraries built on top of a simple core language
> being preferable over a more complex core language.

T~ is not more complex than T* (unless you're coming from a C
background) and in many ways is a simpler conceptual model. The
argument I'm making is that it simplifies _usage_ of the language in
the common case, which makes significantly more sense to me than
optimizing things that everyday developers do far less often (design
and implement the language). Yes, it is purely implementable without
new core languages, but then so are lambdas, references, move
semantics, etc. The question (which you identified later) is simply a
judgement of the cost, not an automatic default to library solutions.
The library is (and has been) used to explore work-arounds to language
pitfalls which are sometimes integrated later. std::bind, for
instance, is scarce in almost all newer code I've seen given how much
easier it often is to declare a lambda doing the same thing.

> I dare claim
> unique_ptr isn't even common enough to motivate having its counterpart in
> the core language.

I'd like to hear justification for that claim. It flies in the face of
my own experience. Are you finding that shared_ptr or some other smart
pointer is more common? I find references are used more than any type
of pointer, but not by a particularly large ratio (and of course not
at all where ownership transferal is needed).

> Well, ~ is used for destructors. I don't see how that would be anything but
> confusing to use for a unique_ptr.

I did think of that. That use in destructors is fairly contained
enough not to be of immediate worry to me, but it's all just bike
shedding at this point. It can be % or ^ or $ or ~~ or @ for all it
matters, or a new keyword, or whatever. I'm not overly concerned about
small redundancies in sigil meaning given the chosen syntax for
rvalue-references, lambdas, universal initialization, etc. (when
[]()<>{} all became part of a valid generic lambda definition, I gave
up caring about token purity). I used ~ as an initial suggestion only
because it's what Rust uses for the same thing, but that's obviously
not a particularly strong argument for that specific character in the
context of C++.

> But you would allow Foo~ ptr{new Foo}; ?

There'd need to be some way to acquire ownership, and that seems the
most obvious. That also brings up the need to release ownership; no
good intrinsic syntax comes up, but that is a very rare need in my
experience and perhaps best handled with a library helper.

In general, I'd lean towards copying std::unique_ptr's semantics
without a strong counter-argument for anything I failed to mention.

>
>> The benefits of built-in uniquely-owned pointers would be:
>>  - Uniquely-owned pointers become as easy to use as raw pointers (as
>> concise, no headers required, etc.)
>
> They are not supposed to be as easy to use as raw pointers, when it
> comes to initializing or copying or converting to void*. Other than that,
> they are syntactically just as easy as raw pointers, and easier from
> the point of view of cleanup.

Sure. I'd more likely call those "ease of misuse," but those cases are
of course the point. The "ease of use" is declaring them, initializing
them _correctly_, avoiding accidental copies, and debugging them
(tools and debuggers typically handle templated smart pointers less
well than they handle raw pointers or references, and understandably
so).

>
>>  - Potentially improved compile times for some TUs (no need to pull in all
>> of <memory>)
>
> Well, for such improvement, I'd love to see measurement results.

Of course.

>
>>  - `new~` (or equivalent syntax) doesn't have the associated danger and
>> ease-of-misuse that plain `new` has regarding exception-safety
>
> How is new~ better than "plain new" in this regard?

new~ is the replacement for make_unique, which of course has important
reasons for existing wrt exceptions:

 foo(T~{new T}, T~{new T}); // if new T throws, we might leak
depending on how the compiler transforms this code

Also, consider these, and the implications on templates, overloading, etc.:
 auto p = new T; // decltype(p) is T*
 auto p = new~ T; // decltype(p) is T~

>
>>  - The language is a bit simpler to teach; no need to explain headers and
>> templates and smart pointer classes just to (safely) handle free-store
>> allocation
>
> I don't think this simplicity will practically amount to much, and now we would
> have more to teach, since this proposal will not replace anything, it will
> just add more material to the core language to teach.

A very small bit of fundmentally important concepts to teach, with the
bonus that you can just skip unique_ptr for most users. I've found
custom deleters to be relatively rare in my work (though clearly
they're critical in other places). Note that when I say "new users" I
mean both fresh-faced students and C++98 veterans. I've found the
latter group to be significantly harder to work with, if anything, and
more resilient to templates given old wounds with the compilers of
yesteryear.

>
>>  - Free-store-allocated objects finally become easier to use than they are
>> in C (again, no headers, no templates or pointer classes just to be safe)
>
> I don't need to teach templates to use a unique_ptr. I can tell people to
> use a magical incantation of auto x = make_unique<YourType>();
> I will have to teach storage durations regardless of how convenient
> you make using a unique_ptr, so avoiding just a header inclusion
> doesn't seem like a convincing reason.

Even programmers with decades of experience shouldn't need to type out
gobs of redundant template names for very common things (especially
given how poorly many tools handle said templates wrt auto-complete
and other bits of context).

It seems such a little thing by itself, but when you work on very
large programs and write or maintain millions of lines of code in the
course of a project, all of those little time wasters add up. The pain
we go through just to e.g. make a debugger not step into a smart
pointer's operator-> for instance, since it can make stepping through
simple-looking lines of code a major pain. It's the little things that
make a difference day-to-day.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 28 April 2014 00:51, Sean Middleditch <sean@middleditch.us> wrote:
> On Sun, Apr 27, 2014 at 5:48 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>> On 27 April 2014 04:28, Sean Middleditch <sean.middleditch@gmail.com> wrote:
>> Raw pointers can go more completely unused once we have a more comprehensive
>> set of shared/unique/cloned/dumb.
> And they would all have the same unfortunate situation where `auto p =
> new T;` or `void foo(T* p)` are significantly easier to (mis)use than
> `#include <memory> auto p = std::make_unique<T>();` or `#include
> <memory> void foo(std::unique_ptr<T> p)`, for students and old hats
> alike. You are maybe underestimating the laziness of many programmers
> (a trait sometimes considered a good thing in software engineering),
> perhaps. :)

Maybe I am. Such misuses don't exist in the world I work in, since they do not
pass code review.

>> This is one of the traditional
>> design guidelines of C++, libraries built on top of a simple core language
>> being preferable over a more complex core language.
> T~ is not more complex than T* (unless you're coming from a C
> background) and in many ways is a simpler conceptual model. The

The point is that a language with T, T* and T& is simpler than a language
with T, T*, T& and T~.

> argument I'm making is that it simplifies _usage_ of the language in
> the common case, which makes significantly more sense to me than

Yes, and I'm making the counter-argument that the case is so uncommon
that it doesn't deserve language support, especially since it has a perfectly
valid library solution that already ships in the standard.

> optimizing things that everyday developers do far less often (design
> and implement the language). Yes, it is purely implementable without
> new core languages, but then so are lambdas, references, move
> semantics, etc. The question (which you identified later) is simply a

I fail to see how you implement move semantics or lambdas without
language support. I haven't looked at move imitations much, but even
boost::lambda doesn't come close to a c++11 lambda in what it
can actually do.

> pitfalls which are sometimes integrated later. std::bind, for
> instance, is scarce in almost all newer code I've seen given how much
> easier it often is to declare a lambda doing the same thing.

bind can still do things lambdas can't do.

>
>> I dare claim
>> unique_ptr isn't even common enough to motivate having its counterpart in
>> the core language.
> I'd like to hear justification for that claim. It flies in the face of
> my own experience. Are you finding that shared_ptr or some other smart
> pointer is more common? I find references are used more than any type

I'm finding that value types are much more common than pointers, and
I find it hard to make a judgement on whether unique_ptr is more common
than shared_ptr.

No thanks. Feel free to propose it; I will vote against it, with all the power a
national body can muster. Having to deal with such a proposal is a waste
of my time, and imho a waste of the committee's time, and I plan to
spend a very minimal time on this proposal from this point onwards.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

The C++ community as a whole would be more welcoming to outsiders if
people could learn to disagree without marinating themselves in
toxicity.

On Sun, Apr 27, 2014 at 3:09 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 28 April 2014 00:51, Sean Middleditch <sean@middleditch.us> wrote:
>> On Sun, Apr 27, 2014 at 5:48 AM, Ville Voutilainen
>> <ville.voutilainen@gmail.com> wrote:
>>> On 27 April 2014 04:28, Sean Middleditch <sean.middleditch@gmail.com> wrote:
>>> Raw pointers can go more completely unused once we have a more comprehensive
>>> set of shared/unique/cloned/dumb.
>> And they would all have the same unfortunate situation where `auto p =
>> new T;` or `void foo(T* p)` are significantly easier to (mis)use than
>> `#include <memory> auto p = std::make_unique<T>();` or `#include
>> <memory> void foo(std::unique_ptr<T> p)`, for students and old hats
>> alike. You are maybe underestimating the laziness of many programmers
>> (a trait sometimes considered a good thing in software engineering),
>> perhaps. :)
>
> Maybe I am. Such misuses don't exist in the world I work in, since they do not
> pass code review.
>
>>> This is one of the traditional
>>> design guidelines of C++, libraries built on top of a simple core language
>>> being preferable over a more complex core language.
>> T~ is not more complex than T* (unless you're coming from a C
>> background) and in many ways is a simpler conceptual model. The
>
> The point is that a language with T, T* and T& is simpler than a language
> with T, T*, T& and T~.
>
>> argument I'm making is that it simplifies _usage_ of the language in
>> the common case, which makes significantly more sense to me than
>
> Yes, and I'm making the counter-argument that the case is so uncommon
> that it doesn't deserve language support, especially since it has a perfectly
> valid library solution that already ships in the standard.
>
>> optimizing things that everyday developers do far less often (design
>> and implement the language). Yes, it is purely implementable without
>> new core languages, but then so are lambdas, references, move
>> semantics, etc. The question (which you identified later) is simply a
>
> I fail to see how you implement move semantics or lambdas without
> language support. I haven't looked at move imitations much, but even
> boost::lambda doesn't come close to a c++11 lambda in what it
> can actually do.
>
>> pitfalls which are sometimes integrated later. std::bind, for
>> instance, is scarce in almost all newer code I've seen given how much
>> easier it often is to declare a lambda doing the same thing.
>
> bind can still do things lambdas can't do.
>
>>
>>> I dare claim
>>> unique_ptr isn't even common enough to motivate having its counterpart in
>>> the core language.
>> I'd like to hear justification for that claim. It flies in the face of
>> my own experience. Are you finding that shared_ptr or some other smart
>> pointer is more common? I find references are used more than any type
>
> I'm finding that value types are much more common than pointers, and
> I find it hard to make a judgement on whether unique_ptr is more common
> than shared_ptr.
>
> No thanks. Feel free to propose it; I will vote against it, with all the power a
> national body can muster. Having to deal with such a proposal is a waste
> of my time, and imho a waste of the committee's time, and I plan to
> spend a very minimal time on this proposal from this point onwards.
>
> --
>
> ---
> 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.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--Apple-Mail=_FAE8E4DB-2312-4EE7-868A-B9928A92F934
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-04-28, at 6:13 AM, Jeremy Ong <jeremycong@gmail.com> wrote:

> The C++ community as a whole would be more welcoming to outsiders if
> people could learn to disagree without marinating themselves in
> toxicity.

There's no institutional culture of hostility; Ville is among the friendlie=
st guys here. Is there another internationally-standardized language with a=
n evolutionary process as democratic as C++? Non-implementers can just walk=
 in here and suggest whatever they fancy. Bad ideas are a consequence of th=
at, but they still need to be called out.

Proposing new forms of operator new is not an activity for "outsiders." Any=
way, Sean isn't an outsider.

IMHO, merely typing unique_ptr is not too much boilerplate to express that =
sort of ownership. I don't use unique_ptr that often, and surely there are =
just as many people (or application domains) for whom shared_ptr is the def=
ault solution. Why the favoritism?

To avoid repetition of compound types or templates, use typedef.

We've gotten to a point where new-expressions are unconditionally a red fla=
g, and that's a good thing. I don't see how new~ sends the language in a be=
tter direction than make_unique.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_FAE8E4DB-2312-4EE7-868A-B9928A92F934
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;04&ndash;28, at 6:13 AM, Jeremy Ong &lt;<a href=3D"mailto:jeremycong@=
gmail.com">jeremycong@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-inte=
rchange-newline"><blockquote type=3D"cite">The C++ community as a whole wou=
ld be more welcoming to outsiders if<br>people could learn to disagree with=
out marinating themselves in<br>toxicity.<br></blockquote><div><br></div><d=
iv>There&rsquo;s no institutional culture of hostility; Ville is among the =
friendliest guys here. Is there another internationally-standardized langua=
ge with an evolutionary process as democratic as C++? Non-implementers can =
just walk in here and suggest whatever they fancy. Bad ideas are a conseque=
nce of that, but they still need to be called out.</div><div><br></div><div=
>Proposing new forms of <font face=3D"Courier">operator new</font> is not a=
n activity for &ldquo;outsiders.&rdquo; Anyway, Sean isn&rsquo;t an outside=
r.</div><div><br></div><div>IMHO, merely typing <font face=3D"Courier">uniq=
ue_ptr</font> is not too much boilerplate to express that sort of ownership=
.. I don&rsquo;t use unique_ptr that often, and surely there are just as man=
y people (or application domains) for whom <font face=3D"Courier">shared_pt=
r</font> is the default solution. Why the favoritism?</div><div><br></div><=
div>To avoid repetition of compound types or templates, use <font face=3D"C=
ourier">typedef</font>.</div><div><br></div><div>We&rsquo;ve gotten to a po=
int where new-expressions are&nbsp;unconditionally a red flag, and that&rsq=
uo;s a good thing. I don&rsquo;t see how <font face=3D"Courier">new~</font>=
 sends the language in a better direction than <font face=3D"Courier">make_=
unique</font>.</div><div><br></div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_FAE8E4DB-2312-4EE7-868A-B9928A92F934--

.

Em s=E1b 26 abr 2014, =E0s 18:28:13, Sean Middleditch escreveu:
>  auto func(T~ ptr); // function taking an owned pointer to T

That is, this function *deletes* the pointer at the end of the invocation,=
=20
right? You can call it like this:

 func(new~ Type);
or

 auto p =3D new~ Type;
 func(std::move(p));

but not:

 autp p =3D new~ Type;
 func(p);
 use(p);

In order to do the above, you'd need:

 void func(T~& ptr);

which would needlessly pass a reference to a pointer, instead of a real=20
pointer. One extra level of indirection...

For that matter, how do you propose one can extract the plain pointer from=
=20
this new construct so it can be passed to legacy or C functions?
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Sun, Apr 27, 2014 at 3:09 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> Maybe I am. Such misuses don't exist in the world I work in, since they do not
> pass code review.

I do envy you. :)

>
>>> This is one of the traditional
>>> design guidelines of C++, libraries built on top of a simple core language
>>> being preferable over a more complex core language.
>> T~ is not more complex than T* (unless you're coming from a C
>> background) and in many ways is a simpler conceptual model. The
>
> The point is that a language with T, T* and T& is simpler than a language
> with T, T*, T& and T~.

From the definition of how complex the spec that most regular
programmers never read is, sure. From the definition of how complex
the language is to use and interact with day-to-day, I strongly
disagree; adding 10 more pages to a spec that saves time in day-to-day
work by simplifying the mental model needed for the _common case_
(which I feel is the contention we have here; whether or not it truly
is all that common) makes the language simpler to use.

>
>> argument I'm making is that it simplifies _usage_ of the language in
>> the common case, which makes significantly more sense to me than
>
> Yes, and I'm making the counter-argument that the case is so uncommon
> that it doesn't deserve language support, especially since it has a perfectly
> valid library solution that already ships in the standard.

Fair enough. It just doesn't mesh with my experience. I see unique_ptr
(or pre-C++11 variations, like scoped_ptr) used quite extensively. If
someone brings up a question to me about raw pointers, my answer is
(often) "just use unique_ptr" (or that variation used in the project
at hand).

>
>> optimizing things that everyday developers do far less often (design
>> and implement the language). Yes, it is purely implementable without
>> new core languages, but then so are lambdas, references, move
>> semantics, etc. The question (which you identified later) is simply a
>
> I fail to see how you implement move semantics or lambdas without
> language support. I haven't looked at move imitations much, but even
> boost::lambda doesn't come close to a c++11 lambda in what it
> can actually do.

Move semantics are trivial. Macros or class tags that mark a type as
"trivially moveable" and then functions/methods that perform move have
been common enough for years before C++11/0x added them, and were
quite likely the inspiration for rvalue references in the first place.
They're a bit more cumbersome and don't work with standard containers,
of course, but they work well enough (and STL containers are rare in
the games industry; even std::vector is often reimplemented without
the out-of-bounds checks and "fat" iterators just to save that tiny
bit on run-time efficiency; see the EASTL paper (N2271) from some
years back for a better explanation on that tangent). The STL could
have been extended in a backward-compatible way to handle the main
bits of move semantics, but that would have been hacky and ugly and
rvalue references are clearly the more clean solution despite the
added language complexity (and a lot of it in that case).

This is similar-ish to how I'm leaning towards "copy semantics" these
days. Too many performance errors happen because of accidental copies,
even in cases the programmer thinks the code should be moving. A few
template wrappers, a helper function, and attention to how/when copy
constructors and assignment operators are used and the problem can be
solved (whether it's a worthwhile or good idea is another story which
I don't have enough experience with to have a strong opinion on, but
it's something I'm continuing to explore).

Regarding lambdas, expression templates can be made to handle most of
the common uses I see of lambdas. Building more complex lambdas is too
complex to be realistically done in expression templates, yes, but
then those can just be functor objects. Lamdas are a syntactic sugar
for something that was deemed too painful to do despite being possible
to do. The same goes for range-based for.

>> pitfalls which are sometimes integrated later. std::bind, for
>> instance, is scarce in almost all newer code I've seen given how much
>> easier it often is to declare a lambda doing the same thing.
>
> bind can still do things lambdas can't do.

Hmm, I am not able to think of any examples, at least if considering
C++14 generalized lamba capture.

>
>>
>>> I dare claim
>>> unique_ptr isn't even common enough to motivate having its counterpart in
>>> the core language.
>> I'd like to hear justification for that claim. It flies in the face of
>> my own experience. Are you finding that shared_ptr or some other smart
>> pointer is more common? I find references are used more than any type
>
> I'm finding that value types are much more common than pointers, and
> I find it hard to make a judgement on whether unique_ptr is more common
> than shared_ptr.

Fair enough. I'm not finding that to be the case much for our stuff.
Too many big, complex objects. Game objects/components, AI graphs,
various resources, scene nodes, audio queues, events, complex state,
etc. I've made the (half) joking argument that a vector (in terms of
linear algebra, not the container) is more common than a scalar number
in a lot of game code, which is quite possibly atypical to the rest of
the C++ community; perhaps the same is true of the kinds of objects we
work with. :)

>
> No thanks. Feel free to propose it; I will vote against it, with all the power a
> national body can muster. Having to deal with such a proposal is a waste
> of my time, and imho a waste of the committee's time, and I plan to
> spend a very minimal time on this proposal from this point onwards.

Thanks for the feedback nonetheless, Ville.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Sun, Apr 27, 2014 at 3:13 PM, Jeremy Ong <jeremycong@gmail.com> wrote:
> The C++ community as a whole would be more welcoming to outsiders if
> people could learn to disagree without marinating themselves in
> toxicity.

For the record, I don't feel this is the case at all, at least with
Ville's response.

Ville obviously disagrees very strongly with the idea, but I'm getting
no sense at all that there is any personal animosity going on. He not
once used any kind of ad hominen attack, pejorative, or anything
negative like that. He strongly disagrees the idea's merit, put effort
into explaining why, and handled his opinion on the topic very
professionally.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Sun, Apr 27, 2014 at 8:33 PM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> Em s=C3=A1b 26 abr 2014, =C3=A0s 18:28:13, Sean Middleditch escreveu:
>>  auto func(T~ ptr); // function taking an owned pointer to T
>
> That is, this function *deletes* the pointer at the end of the invocation=
,
> right? You can call it like this:
>
>         func(new~ Type);
> or
>
>         auto p =3D new~ Type;
>         func(std::move(p));
>
> but not:
>
>         autp p =3D new~ Type;
>         func(p);
>         use(p);

Right.

>
> In order to do the above, you'd need:
>
>         void func(T~& ptr);

Or just:

  void func(T& ref);

I don't find that the presented example makes much sense. If you're
passing in an object but don't intend for that function to take over
ownership then don't give it ownership. What useful stuff is func
going to do with a T~ that it isn't able to take ownership of that it
couldn't do with T&?

  T* is a memory address that (if you're very careful) points at a
live T, which you may or may not have ownership of (you can't tell
from the local code).

  T~ is a handle that always (excepting really hacky hacks) points at
a live T which you have ownership of.

  T& is a reference that always (excepting really hacky hacks)
references a live T which do not have ownership of.

Of the three, it's a lot easier IMO to make the argument that T* be
the second-class citizen (if we ignored all backwards-compatibility,
which we can't of course). Not being able to demote T* makes promoting
T~ or its ilk all the more important.

That's almost exactly what a reference is for. Rust handles this a
little bit more elegantly via its "borrowed reference" semantics, but
that's a _very_ complex feature I wouldn't dream of even idly
suggesting for C++ anytime soon.

>
> which would needlessly pass a reference to a pointer, instead of a real
> pointer. One extra level of indirection...
>
> For that matter, how do you propose one can extract the plain pointer fro=
m
> this new construct so it can be passed to legacy or C functions?

One possibility would be:

  T~ t =3D ...;
  static_cast<T*>(t);

or (and I like this less):

  T~ t =3D ...;
  T* tp{t}; // but NOT T* tp =3D t; the initialization must be explicit

The trickier case is releasing ownership, which maybe would be:

  T* tp{std::move(t)};

I'd formulate the rules with something like: T~ has the following
built-in conversion operators (slightly pseudo-code-y):

  T~::operator T*() const& { return __addressof(*this); }
  T~::operator T*() && { auto tmp =3D __addressof(*this); *this =3D
nullptr; return tmp; }

The state operations would be discouraged in general. The easy things
should be easy and the dangerous things should be hard (in order to
discourage accidental or naive misuse). Expanding that philosophy
fully, I state it as the given set of decreasing priorities for any
language, interface, or API design:

 1) Don't stop the user from doing things that need to be done.
 2) Make safe operations easier than unsafe ones.
 3) Make correct operations easier than incorrect ones.
 4) Make efficient operations easier than inefficient ones.

The motivation being that people tend to follow the path of least
resistance and that new users learn the easy methods before the hard
ones. C++ already fails consistently on prioritizing items 2-4 from my
perspective (often due to C's legacy), but that doesn't mean I want to
just give up on C++ (though unfortunately so many others do, as
evidenced by all the so-far failed attempts at creating a "C++
killer").

Different situations have to change up those priorities here and
there, of course. A sandboxed environment must swap 1&2 and then
restate the latter as "Don't allow unsafe operations," as one example.
Some situations have no real differences between unsafe and incorrect
(nuclear power plant monitoring software, not that I have any
experience writing such). In the space occupied by C++ and the sorts
of libraries and codebases I work on, I feel those priorities are
spot-on.

.... that was a big tangent, but hopefully helps to explain the
direction I'm coming from in thinking that a T~ would be a valuable
addition to the language.
--=20
Sean Middleditch
http://seanmiddleditch.com

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Sun, Apr 27, 2014 at 8:01 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9304=E2=80=9328, at 6:13 AM, Jeremy Ong <jeremycong@gmail.c=
om> wrote:
>
> The C++ community as a whole would be more welcoming to outsiders if
> people could learn to disagree without marinating themselves in
> toxicity.
>
>
> There=E2=80=99s no institutional culture of hostility; Ville is among the
> friendliest guys here. Is there another internationally-standardized
> language with an evolutionary process as democratic as C++? Non-implement=
ers
> can just walk in here and suggest whatever they fancy. Bad ideas are a
> consequence of that, but they still need to be called out.
>
> Proposing new forms of operator new is not an activity for =E2=80=9Coutsi=
ders.=E2=80=9D
> Anyway, Sean isn=E2=80=99t an outsider.
>
> IMHO, merely typing unique_ptr is not too much boilerplate to express tha=
t
> sort of ownership. I don=E2=80=99t use unique_ptr that often, and surely =
there are
> just as many people (or application domains) for whom shared_ptr is the
> default solution. Why the favoritism?

I've found shared ownership to simply be the rarer of the two, at
least in my domain. I obviously can't speak for all the domains I've
never worked in. :)

On technical grounds:
 - Shared ownership implies performance costs (especially if
thread-safe) that are not exactly obvious, even to people with years
of C++ experience.
 - Shared ownership also requires deeper impact into ABIs, object
layouts, and so on, making it too difficult to add in a way that will
satisfy a majority of use cases (I've seen a lot of shared_ptr vs
atomic_shared_ptr vs ref_ptr and so on to handle a wide variety of
specific shared ownership situations).
 - Simple shared ownership without an automatic GC leads to
reference-cycle bugs/leaks
 - Shared ownership leads to weak references, which is whole 'nother
can of worms
 - Anecdotal, but I've had to track down and solve far too many
difficult-to-diagnosis bugs with misuse of shared_ptr-like
reference-counted handles in large codebases).
 - Also anecdotal, but most cases I've seen a colleague use a
shared_ptr have been trivially reworked to use a unique_ptr

>
> To avoid repetition of compound types or templates, use typedef.

I have seen an awful lot of type `FooP =3D std::unique_ptr<Foo>` kinds
of things. Often then followed by developers (again, even experienced
ones) including oodles of headers to avoid redefining the simple
aliases.

> We=E2=80=99ve gotten to a point where new-expressions are unconditionally=
 a red
> flag, and that=E2=80=99s a good thing. I don=E2=80=99t see how new~ sends=
 the language in a
> better direction than make_unique.

I agree with the idea that `new` is and should be a red flag. T~ is
the main idea. new~ was just a placeholder spelling of the concept
that we would need a way to instantiate a T~ with a new value
_without_ `new` and its short-comings.

`new~ T{}` could just as easily be spelled `T~{}` or some other syntax
with no keyword involved. Or it could be a different novel keyword
like `boxval` or something. That bit is not important to the core idea
of built-in uniquely owned references.



Thanks to everyone for the feedback so far. At the very least I'm
seeing that to pursue this I will need to explain my purpose and
motivations in much more detail and with far better motivating
examples to have any reasonable hope of convincing most of the
committee to see things from my point of view on this issue. I also
could do more research into current thinking on ownership semantics
within the C++-using community as at least a few of you seem to have
wildly different and honestly unexpected thoughts on them than I do.

--=20
Sean Middleditch
http://seanmiddleditch.com

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_45_33331386.1398669927931
Content-Type: text/plain; charset=UTF-8

Great idea, please continue working on it. The burden of unique_ptr just
adds up to more than people think.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_45_33331386.1398669927931
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Great idea, please continue working on it. The burden of unique_ptr just adds up to more than people think.<br></div>

<p></p>

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

------=_Part_45_33331386.1398669927931--

.

Em dom 27 abr 2014, =E0s 22:13:22, Sean Middleditch escreveu:
> > In order to do the above, you'd need:
> >         void func(T~& ptr);
>=20
> Or just:
>=20
>   void func(T& ref);
>=20
> I don't find that the presented example makes much sense. If you're
> passing in an object but don't intend for that function to take over
> ownership then don't give it ownership. What useful stuff is func
> going to do with a T~ that it isn't able to take ownership of that it
> couldn't do with T&?

It can still do everything, but it might become uglier. For example, to ver=
ify=20
whether the passed pointer was null, it needs to do:

 if (!&ref)

which is very ugly. And that's assuming that T didn't override the unary=20
operator&. If you need to be safe, you'd need to use std::addressof.

>   T* is a memory address that (if you're very careful) points at a
> live T, which you may or may not have ownership of (you can't tell
> from the local code).
>=20
>   T~ is a handle that always (excepting really hacky hacks) points at
> a live T which you have ownership of.

Except when it isn't always a live T. Like I said, it can be null.

>   T& is a reference that always (excepting really hacky hacks)
> references a live T which do not have ownership of.

Except when it's also null, which it seldom is today, but your construct wo=
uld=20
make more of.

> > For that matter, how do you propose one can extract the plain pointer f=
rom
> > this new construct so it can be passed to legacy or C functions?
>=20
> One possibility would be:
>=20
>   T~ t =3D ...;
>   static_cast<T*>(t);

So

 delete static_cast<T *>(t);

> I'd formulate the rules with something like: T~ has the following
> built-in conversion operators (slightly pseudo-code-y):
>=20
>   T~::operator T*() const& { return __addressof(*this); }
>   T~::operator T*() && { auto tmp =3D __addressof(*this); *this =3D
> nullptr; return tmp; }

The above means doing:

 static_cast<T *>(std::move(p));

will effectively delete the held item. Note that it doesn't happen with=20
unique_ptr.

> ... that was a big tangent, but hopefully helps to explain the
> direction I'm coming from in thinking that a T~ would be a valuable
> addition to the language.

I think we understand why you want it. Doesn't mean people agree with you i=
t=20
should be a core language feature.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 28 April 2014 07:26, Sean Middleditch <sean@middleditch.us> wrote:
> For the record, I don't feel this is the case at all, at least with
> Ville's response.
> Ville obviously disagrees very strongly with the idea, but I'm getting
> no sense at all that there is any personal animosity going on. He not
> once used any kind of ad hominen attack, pejorative, or anything
> negative like that. He strongly disagrees the idea's merit, put effort
> into explaining why, and handled his opinion on the topic very
> professionally.


Thank you, Sean.

This is indeed not personal, I oppose the proposal's merits and its design,
and that's it.

Some perhaps philosophical points:

1) I'm not surprised to see Rust's borrowed pointers mentioned. I do understand
that they are not being proposed, but often this sort of core language extension
proposals arise from the convenience with which other languages provide
certain facilities. Python and Haskell are often sources of such ideas (yes,
python tuples, for example, are wonderfully convenient), and C++/CLI managed
pointers and C# nullable types are also often mentioned. I'm not entirely
sure that the latter two, for example, were such stellar ideas in the
aforementioned
languages, though.

2) ..which has lead to similar extension proposals before: people have suggested
std::array, std::tuple and std::bind (and probably other things) to be
candidates
for things that would be more efficient/convenient to have in the core language.

3) I understand that it may seem inconvenient to use library types for
things some
people deem fundamental (often based on their frequent use of such facilities),
having to include a header doesn't make a type "feel" part of a
language. A short
syntax for something (some) people use on an almost-daily-basis also seems very
attractive.

4) the problem in C++ is that the nice-looking terse syntaxes have been taken
a long time ago. To add further terse syntaxes, we don't achieve any similarity
with other languages, but have to add new and inventive punctuation for people
to learn.

In contrast, while rejecting such extensions may seem blunt, there are rational
reasons for it. Such as

1) Which things are truly fundamental and common? It's certainly
clearer to maintain the guideline
that if it doesn't have to be in core, and it can be in the library,
the library is where it should be.

2) Adding library extensions is vastly easier. Compilers certainly
need time to catch
up on C++11 still, and there's only one complete C++14 implementation. That
implementation (clang) got C++14-completed early and quickly, which is great,
but others are some ways behind. I at least view every language
extension proposal
with much higher scrutiny than library extensions, and I set the bar
very high on the
bang/buck ratio of everything that requires compiler changes. I do put
users before
implementation vendors in general, but I do not ignore implementation concerns,
because they sometimes lead to problems for users, due to lack of portability
between implementations. We can ship, and have shipped, third-party early
implementations of library extensions that are portable across implementations
without requiring the implementation vendor to chip in. This is more or less not
the case with language extensions.

3) Just having to include a header and to use a verbose type name in
declarations
are, at least to me, not significant problems compared to the work we
have to do to specify and implement a core language feature. That
applies in general to any feature, and even more significantly
to ones that are arguably just fine as library types, like the subject
of this discussion,
unique_ptr. Furthermore, having to use a (imho-not-too) verbose type
name in declarations
is a feature to me.

4) The aforementioned bang/buck ratio for something new in the core
language that does
more or less the same thing as an existing, shipping standard library
type (with shorter syntax
and yes, without having to include a header) just isn't there for me.

At the risk of a slight digression, some words about having to include a header:

- we've tried adding some sort of umbrella headers, like <std-all>
etc. That unfortunately
didn't end well because it's next to impossible to reach an agreement over what
an <essential_stuff> header should contain, and then there's
disagreement over whether
an <all> header does more harm than good, and the discussion reaches an impasse.

- I think it's been attempted to suggest some sort of
magical-inclusion; that doesn't
end well because people don't agree on whether it's reasonable to place the
burden of performing magic-inclusion on every implementation.
Quality-of-implementation
diagnostics and auto-fixes are sometimes suggested, but this doesn't
necessarily help the
users who have to write portable code on multiple implementations.

- and at the risk of sounding biased towards non-novices, I don't
think it's reasonable
to expect useful programs to be written by programmers if they have
trouble with the
concept of including header files - on any skill level. The simplest
hello world requires
headers. They are in-our-face from the get-go.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a11c3ee6a23b40104f81b7f28
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 28, 2014 at 1:48 AM, Sean Middleditch <sean@middleditch.us>wrot=
e:

> >
> > IMHO, merely typing unique_ptr is not too much boilerplate to express
> that
> > sort of ownership. I don=E2=80=99t use unique_ptr that often, and surel=
y there
> are
> > just as many people (or application domains) for whom shared_ptr is the
> > default solution. Why the favoritism?
>
> I've found shared ownership to simply be the rarer of the two, at
> least in my domain. I obviously can't speak for all the domains I've
> never worked in. :)
>
> On technical grounds:
>  - Shared ownership implies performance costs (especially if
> thread-safe) that are not exactly obvious, even to people with years
> of C++ experience.
>  - Shared ownership also requires deeper impact into ABIs, object
> layouts, and so on, making it too difficult to add in a way that will
> satisfy a majority of use cases (I've seen a lot of shared_ptr vs
> atomic_shared_ptr vs ref_ptr and so on to handle a wide variety of
> specific shared ownership situations).
>  - Simple shared ownership without an automatic GC leads to
> reference-cycle bugs/leaks
>  - Shared ownership leads to weak references, which is whole 'nother
> can of worms
>  - Anecdotal, but I've had to track down and solve far too many
> difficult-to-diagnosis bugs with misuse of shared_ptr-like
> reference-counted handles in large codebases).
>  - Also anecdotal, but most cases I've seen a colleague use a
> shared_ptr have been trivially reworked to use a unique_ptr
>
>

"A shared pointer is as good as a global variable" - Sean Parent.

Shared-pointers are useful in certain situations, but now that we have
unique_ptr, shared_ptr should typically be avoided. I haven't yet put them
in my "evil bucket" (where singletons and macros live), but some days I'd
like to.  If anyone has spent time fixing java bugs, you know how often
shared-ownership causes "how did *my* value change" bugs.  Thankfully C++
never made the "let's make shared-ownership the default" mistake of other
languages. Then it would be "evil".


I'm not against something like T~, but I also don't think we are done with
our list-of-pointers-for-every-occasion. Once we have the list more
complete, then it might make more sense to see if anything should get
elevated to core language.

Tony

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a11c3ee6a23b40104f81b7f28
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Mon, Apr 28, 2014 at 1:48 AM, Sean Middleditch <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:sean@middleditch.us" target=3D"_blank">sean@middledi=
tch.us</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">&gt;<br>
&gt; IMHO, merely typing unique_ptr is not too much boilerplate to express =
that<br>
&gt; sort of ownership. I don=E2=80=99t use unique_ptr that often, and sure=
ly there are<br>
&gt; just as many people (or application domains) for whom shared_ptr is th=
e<br>
&gt; default solution. Why the favoritism?<br>
<br>
</div>I&#39;ve found shared ownership to simply be the rarer of the two, at=
<br>
least in my domain. I obviously can&#39;t speak for all the domains I&#39;v=
e<br>
never worked in. :)<br>
<br>
On technical grounds:<br>
=C2=A0- Shared ownership implies performance costs (especially if<br>
thread-safe) that are not exactly obvious, even to people with years<br>
of C++ experience.<br>
=C2=A0- Shared ownership also requires deeper impact into ABIs, object<br>
layouts, and so on, making it too difficult to add in a way that will<br>
satisfy a majority of use cases (I&#39;ve seen a lot of shared_ptr vs<br>
atomic_shared_ptr vs ref_ptr and so on to handle a wide variety of<br>
specific shared ownership situations).<br>
=C2=A0- Simple shared ownership without an automatic GC leads to<br>
reference-cycle bugs/leaks<br>
=C2=A0- Shared ownership leads to weak references, which is whole &#39;noth=
er<br>
can of worms<br>
=C2=A0- Anecdotal, but I&#39;ve had to track down and solve far too many<br=
>
difficult-to-diagnosis bugs with misuse of shared_ptr-like<br>
reference-counted handles in large codebases).<br>
=C2=A0- Also anecdotal, but most cases I&#39;ve seen a colleague use a<br>
shared_ptr have been trivially reworked to use a unique_ptr<br>
<div class=3D""><br></div></blockquote></div></div><br><div class=3D"gmail_=
extra"><br></div><div class=3D"gmail_extra">&quot;A shared pointer is as go=
od as a global variable&quot; - Sean Parent.<br><br></div><div class=3D"gma=
il_extra">
Shared-pointers are useful in certain situations, but now that we have uniq=
ue_ptr, shared_ptr should typically be avoided. I haven&#39;t yet put them =
in my &quot;evil bucket&quot; (where singletons and macros live), but some =
days I&#39;d like to.=C2=A0 If anyone has spent time fixing java bugs, you =
know how often shared-ownership causes &quot;how did *my* value change&quot=
; bugs.=C2=A0 Thankfully C++ never made the &quot;let&#39;s make shared-own=
ership the default&quot; mistake of other languages. Then it would be &quot=
;evil&quot;.<br>
<br><br>I&#39;m not against something like T~, but I also don&#39;t think w=
e are done with our list-of-pointers-for-every-occasion. Once we have the l=
ist more complete, then it might make more sense to see if anything should =
get elevated to core language.<br>
<br></div><div class=3D"gmail_extra">Tony<br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3ee6a23b40104f81b7f28--

.

On Mon, Apr 28, 2014 at 12:38 AM, Thiago Macieira <thiago@macieira.org> wro=
te:
> Em dom 27 abr 2014, =C3=A0s 22:13:22, Sean Middleditch escreveu:
>>
>>   void func(T& ref);
>
> It can still do everything, but it might become uglier. For example, to v=
erify
> whether the passed pointer was null, it needs to do:
>
>         if (!&ref)
>
> which is very ugly. And that's assuming that T didn't override the unary
> operator&. If you need to be safe, you'd need to use std::addressof.

That's a good point. We use asserts in any attempt to dereference a
unique pointer, making sure the checks must happen at the call site
(or sooner), but that obviously couldn't be part of any built-in
work-alike.

>
> So
>
>         delete static_cast<T *>(t);

  int i;
  delete &i;

>>   T~::operator T*() const& { return __addressof(*this); }
>>   T~::operator T*() && { auto tmp =3D __addressof(*this); *this =3D
>> nullptr; return tmp; }
>
> The above means doing:
>
>         static_cast<T *>(std::move(p));
>
> will effectively delete the held item. Note that it doesn't happen with
> unique_ptr.

I don't follow that conclusion. It "releases" the pointer, similar to
std::unique_ptr<T>::release does.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

Em seg 28 abr 2014, =E0s 09:21:11, Sean Middleditch escreveu:
> >>   T~::operator T*() const& { return __addressof(*this); }
> >>   T~::operator T*() && { auto tmp =3D __addressof(*this); *this =3D
> >>
> >> nullptr; return tmp; }
> >=20
> > The above means doing:
> >         static_cast<T *>(std::move(p));
> >
> > will effectively delete the held item. Note that it doesn't happen with
> > unique_ptr.
>=20
> I don't follow that conclusion. It "releases" the pointer, similar to
> std::unique_ptr<T>::release does.

It's a surprise factor. You moved to (void) and yet it did something. There=
=20
was no explicit call to "release" or a delete in that statement. Yet memory=
=20
was released.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Mon, Apr 28, 2014 at 9:40 AM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> Em seg 28 abr 2014, =C3=A0s 09:21:11, Sean Middleditch escreveu:
>> >>   T~::operator T*() const& { return __addressof(*this); }
>> >>   T~::operator T*() && { auto tmp =3D __addressof(*this); *this =3D
>> >>
>> >> nullptr; return tmp; }
>> >
>> > The above means doing:
>> >         static_cast<T *>(std::move(p));
>> >
>> > will effectively delete the held item. Note that it doesn't happen wit=
h
>> > unique_ptr.
>>
>> I don't follow that conclusion. It "releases" the pointer, similar to
>> std::unique_ptr<T>::release does.
>
> It's a surprise factor. You moved to (void) and yet it did something. The=
re
> was no explicit call to "release" or a delete in that statement. Yet memo=
ry
> was released.

  static_cast<vector<int>>(std::move(vec));

This is similar to the delete example from the previous message. C++
lets you do all kinds of wonky things leading to undefined behavior,
well-defined but obviously wrong behavior (as here), or even
well-defined and correct but scary and smelly behavior.

As a QoI, Clang at least would give a warning about the above kind of
code (unused result of expression). GCC 4.9 does not by default, and I
haven't tested any others.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 2014-04-27 17:51, Sean Middleditch wrote:
> On Sun, Apr 27, 2014 at 5:48 AM, Ville Voutilainen wrote:
>> But you would allow Foo~ ptr{new Foo}; ?

Bleh. 'Foo~ ptr{/* args for Foo ctor */}', please! If we're going to
treat this like a first-class citizen (not that I'm convinced of the
necessity, mind), new~ should not be allowed to initialize a T~ from a
T*, except as T has a ctor taking a T*. (IOW, new~ T{...} should be
equivalent to make_unique<T>(...), not unique_ptr<T>(...).)

> That also brings up the need to release ownership; no good intrinsic
> syntax comes up, but that is a very rare need in my experience and
> perhaps best handled with a library helper.

We could borrow from Python and have an 'operator delete'. For example:

class Foo
{
   ...
   operator delete() { ... }
   ...
};

Foo foo;
delete foo; // calls Foo::operator delete()
foo = bar(); // note: 'foo' is still valid!

So one can easily imagine:

auto ptr = Bar~{};
....
delete ptr; // calls std::unique_ptr<Bar>::operator delete, which would
             // be equivalent to 'ptr.reset(nullptr)'

This might be interesting independent of unique_ptr as a built-in
pointer type.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 28 April 2014 20:28, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
> We could borrow from Python and have an 'operator delete'. For example:
>
> class Foo
> {
>   ...
>   operator delete() { ... }
>   ...
> };

We already have class-specific operator delete, I don't know which bit of it
is "borrowing from python".

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Em seg 28 abr 2014, =E0s 10:01:43, Sean Middleditch escreveu:
> On Mon, Apr 28, 2014 at 9:40 AM, Thiago Macieira <thiago@macieira.org>=20
wrote:
> > Em seg 28 abr 2014, =E0s 09:21:11, Sean Middleditch escreveu:
> >> >>   T~::operator T*() const& { return __addressof(*this); }
> >> >>   T~::operator T*() && { auto tmp =3D __addressof(*this); *this =3D
> >> >>=20
> >> >> nullptr; return tmp; }
> >> >=20
> >> > The above means doing:
> >> >         static_cast<T *>(std::move(p));
> >> >=20
> >> > will effectively delete the held item. Note that it doesn't happen w=
ith
> >> > unique_ptr.
> >>=20
> >> I don't follow that conclusion. It "releases" the pointer, similar to
> >> std::unique_ptr<T>::release does.
> >=20
> > It's a surprise factor. You moved to (void) and yet it did something.
> > There
> > was no explicit call to "release" or a delete in that statement. Yet
> > memory
> > was released.
>=20
>   static_cast<vector<int>>(std::move(vec));

That doesn't *actually* move the items out. They get moved only when they=
=20
assigned to another vector.

> As a QoI, Clang at least would give a warning about the above kind of
> code (unused result of expression). GCC 4.9 does not by default, and I
> haven't tested any others.

The above doesn't do anything, so it's not a problem of unused result.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 28 April 2014 20:37, Thiago Macieira <thiago@macieira.org> wrote:
>>   static_cast<vector<int>>(std::move(vec));
>
> That doesn't *actually* move the items out. They get moved only when they
> assigned to another vector.

Sure it does move, the result of such a static_cast is a temporary that is
initialized from the rvalue vec, and it will move the elements of vec.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-04-28 13:30, Ville Voutilainen wrote:
> On 28 April 2014 20:28, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
>> We could borrow from Python and have an 'operator delete'. For example:
>>
>> class Foo
>> {
>>    ...
>>    operator delete() { ... }
>>    ...
>> };
>
> We already have class-specific operator delete, I don't know which bit of it
> is "borrowing from python".

Hmm, maybe not. I was thinking about how in Python everything is a
pointer, but I guess __del__ is closer to a C++ destructor.

Anyway, the idea was that 'delete t' where 't' is not a pointer type
would call 'decltype(t)::operator delete(void)', but otherwise not
affect 't'. This would allow writing 'delete ptr' where 'ptr' is e.g. a
unique_ptr in order to release the memory referenced by 'ptr'.

This would be a non-breaking change since right now 'delete ptr' is of
course an error if 'ptr' is not a pointer type, and placement delete
takes arguments.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 28 April 2014 20:45, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
> Hmm, maybe not. I was thinking about how in Python everything is a pointer,
> but I guess __del__ is closer to a C++ destructor.
>
> Anyway, the idea was that 'delete t' where 't' is not a pointer type would
> call 'decltype(t)::operator delete(void)', but otherwise not affect 't'.
> This would allow writing 'delete ptr' where 'ptr' is e.g. a unique_ptr in
> order to release the memory referenced by 'ptr'.
>
> This would be a non-breaking change since right now 'delete ptr' is of
> course an error if 'ptr' is not a pointer type, and placement delete takes
> arguments.


If you're trying to make this idea even less palatable than it already is,
I should probably tell you that you're succeeding.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-04-27 23:33, Thiago Macieira wrote:
> For that matter, how do you propose one can extract the plain pointer from
> this new construct so it can be passed to legacy or C functions?

I'd say...

   auto ptr = T~{...}; // type of ptr is T~ / std::unique_ptr<T>
   auto raw = ptr.get(); // type of raw is T*

IOW, T~ really is just shorthand for std::unique_ptr<T> (or
std::make_unique<T> in certain cases).

I'm assuming that the proposal isn't intended to change access to the
underlying T from 'ptr->member' to 'ptr.member'...

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-04-28 13:49, Ville Voutilainen wrote:
> On 28 April 2014 20:45, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
>> Hmm, maybe not. I was thinking about how in Python everything is a pointer,
>> but I guess __del__ is closer to a C++ destructor.
>>
>> Anyway, the idea was that 'delete t' where 't' is not a pointer type would
>> call 'decltype(t)::operator delete(void)', but otherwise not affect 't'.
>> This would allow writing 'delete ptr' where 'ptr' is e.g. a unique_ptr in
>> order to release the memory referenced by 'ptr'.
>>
>> This would be a non-breaking change since right now 'delete ptr' is of
>> course an error if 'ptr' is not a pointer type, and placement delete takes
>> arguments.
>
> If you're trying to make this idea even less palatable than it already is,
> I should probably tell you that you're succeeding.

Fair enough :-), especially as I'm not entirely on board with it anyway.

I think both ~ as a 'pointer type' and operator delete(void) make sense
in and of themselves. However I am *not* convinced either makes sense to
the language as a whole.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 28 April 2014 21:03, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
> On 2014-04-28 13:49, Ville Voutilainen wrote:
>> If you're trying to make this idea even less palatable than it already is,
>> I should probably tell you that you're succeeding.
> Fair enough :-), especially as I'm not entirely on board with it anyway.
> I think both ~ as a 'pointer type' and operator delete(void) make sense in
> and of themselves. However I am *not* convinced either makes sense to the
> language as a whole.


I should probably elaborate. Having a useful set of smart pointers allows me to
banish the uses of delete from quite many codebases. Having the make_*
factory functions allows me to banish most of the uses of new. This
is a WONDERFUL direction, and I'd recommend against adding facilities
that go to the other direction. Even if it's new~ instead of new. I love being
able to simply grep codebases for delete and weeding them out, and doing the
same for new. Yes, I know, I can use a more elaborate search term, but I
don't want to increase the occurrences of those keywords, even if decorated with
"sigils".

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_3442_23587276.1398736204504
Content-Type: text/plain; charset=UTF-8

On Sunday, April 27, 2014 5:51:08 PM UTC-4, Sean Middleditch wrote:
>
> On Sun, Apr 27, 2014 at 5:48 AM, Ville Voutilainen
> <ville.vo...@gmail.com <javascript:>> wrote:
> > I don't need to teach templates to use a unique_ptr. I can tell people
> to
> > use a magical incantation of auto x = make_unique<YourType>();
>
> Even programmers with decades of experience shouldn't need to type out
> gobs of redundant template names for very common things (especially
> given how poorly many tools handle said templates wrt auto-complete
> and other bits of context).


This statement actually argues against your proposal.  There are no
redundant template names in
auto p = make_unique<T>();
as compared to
T~ p = new~ T();

In fact, it's exactly the opposite.  The latter says T twice, the former,
only once.  If you eliminate the first T, and allow auto to deduce a
unique_ptr from the new~, you end up with
auto p = new ~ T();

So, the proposal is then to mainly replace make_unique<T> with new~ T.  As
Ville said, we should be trying to eliminate the use of "new", not add it,
even with a ~ after it.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_3442_23587276.1398736204504
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, April 27, 2014 5:51:08 PM UTC-4, Sean Middledit=
ch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sun, Apr 27, 2014 =
at 5:48 AM, Ville Voutilainen
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
6Cr10a-aNMkJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">ville.vo...@gmail.com</a>&gt; =
wrote:
<br>&gt; I don't need to teach templates to use a unique_ptr. I can tell pe=
ople to
<br>&gt; use a magical incantation of auto x =3D make_unique&lt;YourType&gt=
;();
<br><br>Even programmers with decades of experience shouldn't need to type =
out
<br>gobs of redundant template names for very common things (especially
<br>given how poorly many tools handle said templates wrt auto-complete
<br>and other bits of context).&nbsp;</blockquote><div><br></div><div>This =
statement actually argues against your proposal. &nbsp;<span style=3D"font-=
size: 13px;">There are no redundant template names in&nbsp;</span></div><di=
v>auto p =3D make_unique&lt;T&gt;();</div><div>as compared to</div><div>T~ =
p =3D new~ T();</div><div><br></div><div>In fact, it's exactly the opposite=
.. &nbsp;The latter says T twice, the former, only once. &nbsp;If you elimin=
ate the first T, and allow auto to deduce a unique_ptr from the new~, you e=
nd up with</div><div>auto p =3D new ~ T();</div><div><br></div><div>So, the=
 proposal is then to mainly replace make_unique&lt;T&gt; with new~ T. &nbsp=
;<span style=3D"font-size: 13px;">As Ville said, we should be trying to eli=
minate the use of "new", not add it, even with a ~ after it.</span></div><d=
iv><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3442_23587276.1398736204504--

.

On Mon, Apr 28, 2014 at 11:30 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> I should probably elaborate. Having a useful set of smart pointers allows me to
> banish the uses of delete from quite many codebases. Having the make_*
> factory functions allows me to banish most of the uses of new. This
> is a WONDERFUL direction, and I'd recommend against adding facilities
> that go to the other direction. Even if it's new~ instead of new. I love being

I'm on board with that sentiment entirely. new~ was but one
placeholder syntax. I know that's hardly the only serious concern
here, but let's just nip this one in the bud now. Nix new~ for now.

  auto p = ~T{ ... }; // might be an ambiguous parse inside definition
of T or its members; unsure
  auto p = T~::{ ... };
  auto p = someotherkeyword T{ ... };

or so on. That not a complete list of possible spellings, nor is it
necessarily representative of the best possible (especially given that
the use of ~ is by no means a given).

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--Apple-Mail=_D0E7890D-76C4-4AEA-9151-67A59C6B1316
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-04-29, at 10:26 AM, Sean Middleditch <sean@middleditch.us> wrote:

> I'm on board with that sentiment entirely. new~ was but one
> placeholder syntax. I know that's hardly the only serious concern
> here, but let's just nip this one in the bud now. Nix new~ for now.
>=20
>  auto p =3D ~T{ ... }; // might be an ambiguous parse inside definition
> of T or its members; unsure
>  auto p =3D T~::{ ... };
>  auto p =3D someotherkeyword T{ ... };

As for arbitrary punctuation, you could take the initials MU of make_unique=
 and define =B5<T>(...) as an alias for std::make_unique<T>. The core langu=
age isn't responsible for the verboseness of the current standard-by-defaul=
t style. But shaving characters isn't for everyone.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_D0E7890D-76C4-4AEA-9151-67A59C6B1316
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;04&ndash;29, at 10:26 AM, Sean Middleditch &lt;<a href=3D"mailto:sean=
@middleditch.us">sean@middleditch.us</a>&gt; wrote:</div><br class=3D"Apple=
-interchange-newline"><blockquote type=3D"cite">I'm on board with that sent=
iment entirely. new~ was but one<br>placeholder syntax. I know that's hardl=
y the only serious concern<br>here, but let's just nip this one in the bud =
now. Nix new~ for now.<br><br> &nbsp;auto p =3D ~T{ ... }; // might be an a=
mbiguous parse inside definition<br>of T or its members; unsure<br> &nbsp;a=
uto p =3D T~::{ ... };<br> &nbsp;auto p =3D someotherkeyword T{ ... };<br><=
/blockquote></div><br><div>As for arbitrary punctuation, you could take the=
 initials MU of <font face=3D"Courier">make_unique</font> and define <font =
face=3D"Courier">=B5&lt;T&gt;(&hellip;)</font> as an alias for&nbsp;<font f=
ace=3D"Courier">std::make_unique&lt;T&gt;</font>. The core language isn&rsq=
uo;t responsible for the verboseness of the current standard-by-default sty=
le. But shaving characters isn&rsquo;t for everyone.</div><div><br></div></=
body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_D0E7890D-76C4-4AEA-9151-67A59C6B1316--

.

--089e0149d0fa9f3f4804f832542d
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 28, 2014 at 10:54 AM, Tony V E <tvaneerd@gmail.com> wrote:

> "A shared pointer is as good as a global variable" - Sean Parent.
>
> Shared-pointers are useful in certain situations, but now that we have
> unique_ptr, shared_ptr should typically be avoided.
>

I believe this is a misrepresentation of what Sean stated. He was not
talking about 'std::shared_ptr', but about any pointer (or reference) that
is shared in different parts of the code.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0149d0fa9f3f4804f832542d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Mon, Apr 28, 2014 at 10:54 AM, Tony V E <span dir=3D"ltr">&lt;<a href=3D=
"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"h5"><div=
 class=3D"gmail_extra"><div class=3D"gmail_quote"><span style=3D"color:rgb(=
34,34,34)">&quot;A shared pointer is as good as a global variable&quot; - S=
ean Parent.</span><br>
</div></div></div></div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra">
Shared-pointers are useful in certain situations, but now that we have uniq=
ue_ptr, shared_ptr should typically be avoided.</div></div></blockquote><di=
v><br>I believe this is a misrepresentation of what Sean stated. He was not=
 talking about &#39;std::shared_ptr&#39;, but about any pointer (or referen=
ce) that is shared in different parts of the code.</div>
</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0149d0fa9f3f4804f832542d--

.

------JDFDZBB1OC9KARC6IMJGIO41KPG2LL
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

Please clarify: would you want to introduce a new operator - like syntax, a=
dd a keyword or make it part of the type signature? Adding a new keyword is=
n't much worth the trouble over std::unique_ptr. Using a new operator may c=
omplicate reading complex expressions. Making it part of the type signature=
 could require "pointer collapsing rules" between this and other pointer "k=
inds".

On April 29, 2014 5:26:22 AM EEST, Sean Middleditch <sean@middleditch.us> w=
rote:
>On Mon, Apr 28, 2014 at 11:30 AM, Ville Voutilainen
><ville.voutilainen@gmail.com> wrote:
>> I should probably elaborate. Having a useful set of smart pointers
>allows me to
>> banish the uses of delete from quite many codebases. Having the
>make_*
>> factory functions allows me to banish most of the uses of new. This
>> is a WONDERFUL direction, and I'd recommend against adding facilities
>> that go to the other direction. Even if it's new~ instead of new. I
>love being
>
>I'm on board with that sentiment entirely. new~ was but one
>placeholder syntax. I know that's hardly the only serious concern
>here, but let's just nip this one in the bud now. Nix new~ for now.
>
>  auto p =3D ~T{ ... }; // might be an ambiguous parse inside definition
>of T or its members; unsure
>  auto p =3D T~::{ ... };
>  auto p =3D someotherkeyword T{ ... };
>
>or so on. That not a complete list of possible spellings, nor is it
>necessarily representative of the best possible (especially given that
>the use of ~ is by no means a given).
>
>--=20
>
>---=20
>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.
>Visit this group at
>http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------JDFDZBB1OC9KARC6IMJGIO41KPG2LL
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><p dir=3D"ltr">Please clarify: would you want to i=
ntroduce a new operator - like syntax, add a keyword or make it part of the=
 type signature? Adding a new keyword isn't much worth the trouble over std=
::unique_ptr. Using a new operator may complicate reading complex expressio=
ns. Making it part of the type signature could require "pointer collapsing =
rules" between this and other pointer "kinds".</p>
<br><br><div class=3D"gmail_quote">On April 29, 2014 5:26:22 AM EEST, Sean =
Middleditch &lt;sean@middleditch.us&gt; wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 20=
4, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On Mon, Apr 28, 2014 at 11:30 AM, Ville Voutilainen<b=
r />&lt;ville.voutilainen@gmail.com&gt; wrote:<br /><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729f=
cf; padding-left: 1ex;"> I should probably elaborate. Having a useful set o=
f smart pointers allows me to<br /> banish the uses of delete from quite ma=
ny codebases. Having the make_*<br /> factory functions allows me to banish=
 most of the uses of new. This<br /> is a WONDERFUL direction, and I'd reco=
mmend against adding facilities<br /> that go to the other direction. Even =
if it's new~ instead of new. I love being<br /></blockquote><br />I'm on bo=
ard with that sentiment entirely. new~ was but one<br />placeholder syntax.=
 I know that's hardly the only serious concern<br />here, but let's just ni=
p this one in the bud now. Nix new~ for now.<br /><br />  auto p =3D ~T{ ..=
.. }; // might be an ambiguous parse inside definition<br />of T or its memb=
ers; unsure<br />  auto p =3D
T~::{ ... };<br />  auto p =3D someotherkeyword T{ ... };<br /><br />or so =
on. That not a complete list of possible spellings, nor is it<br />necessar=
ily representative of the best possible (especially given that<br />the use=
 of ~ is by no means a given).<br /></pre></blockquote></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------JDFDZBB1OC9KARC6IMJGIO41KPG2LL--


.

--001a113483101fb1aa04f833f721
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 29, 2014 at 2:09 PM, David Rodr=C3=ADguez Ibeas <dibeas@ieee.or=
g>wrote:

>
> On Mon, Apr 28, 2014 at 10:54 AM, Tony V E <tvaneerd@gmail.com> wrote:
>
>> "A shared pointer is as good as a global variable" - Sean Parent.
>>
>> Shared-pointers are useful in certain situations, but now that we have
>> unique_ptr, shared_ptr should typically be avoided.
>>
>
> I believe this is a misrepresentation of what Sean stated. He was not
> talking about 'std::shared_ptr', but about any pointer (or reference) tha=
t
> is shared in different parts of the code.
>
> --
>

Possibly, but I don't think so (he's said it to me directly, and in email,
when we were talking about shared_ptr, but I could have misunderstood).
With the magic of cc we can find out.  Either way, I think the thought
still stands on its own merit.  But I wouldn't want to misquote Sean.

Also, I would put shared_ptr in the category of "any pointer (or reference)
that is shared in different parts of the code".  shared_ptr does some nice
ref counting for you, but it is still sharing, and typically that is also a
problem of its own.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a113483101fb1aa04f833f721
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Apr 29, 2014 at 2:09 PM, David Rodr=C3=ADguez Ibeas <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@=
ieee.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote"><div class=3D"">On Mon, Apr 28, 2014 at 10:5=
4 AM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" =
target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><span style=3D"color:rgb(34,34,34)">&q=
uot;A shared pointer is as good as a global variable&quot; - Sean Parent.</=
span><br>

</div></div></div></div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra">
Shared-pointers are useful in certain situations, but now that we have uniq=
ue_ptr, shared_ptr should typically be avoided.</div></div></blockquote></d=
iv><div><br>I believe this is a misrepresentation of what Sean stated. He w=
as not talking about &#39;std::shared_ptr&#39;, but about any pointer (or r=
eference) that is shared in different parts of the code.</div>

</div></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br></div></div></blockquote><div><br></div></div>Possibly, but I don&#3=
9;t think so (he&#39;s said it to me directly, and in email, when we were t=
alking about shared_ptr, but I could have misunderstood).=C2=A0 With the ma=
gic of cc we can find out.=C2=A0 Either way, I think the thought still stan=
ds on its own merit.=C2=A0 But I wouldn&#39;t want to misquote Sean.<br>
<br>Also, I would put shared_ptr in the category of &quot;any pointer (or r=
eference) that is shared in different parts of the code&quot;.=C2=A0 shared=
_ptr does some nice ref counting for you, but it is still sharing, and typi=
cally that is also a problem of its own.</div>
<div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113483101fb1aa04f833f721--

.

--_000_1278C02F6C8D4ADA81BD3D3C07CEDA7Eadobecom_
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The quote referenced includes std::shared_ptr - sharing of data from differ=
ent locations in the code breaks local reasoning. A shared_ptr can be used =
in the implementation of a data structure, but should't be exposed directly=
..

I also object to unique_ptr, except as an implementation detail, but for di=
fferent reasons (unique_ptr strips copy and equality which must then be res=
tored by the owning object).

See Goal #3 in my C++ Seasoning Talk from GoingNative 2013.

Sean

Sent from my iPad

On Apr 29, 2014, at 1:07 PM, "Tony V E" <tvaneerd@gmail.com<mailto:tvaneerd=
@gmail.com>> wrote:




On Tue, Apr 29, 2014 at 2:09 PM, David Rodr?guez Ibeas <dibeas@ieee.org<mai=
lto:dibeas@ieee.org>> wrote:

On Mon, Apr 28, 2014 at 10:54 AM, Tony V E <tvaneerd@gmail.com<mailto:tvane=
erd@gmail.com>> wrote:
"A shared pointer is as good as a global variable" - Sean Parent.

Shared-pointers are useful in certain situations, but now that we have uniq=
ue_ptr, shared_ptr should typically be avoided.

I believe this is a misrepresentation of what Sean stated. He was not talki=
ng about 'std::shared_ptr', but about any pointer (or reference) that is sh=
ared in different parts of the code.

--

Possibly, but I don't think so (he's said it to me directly, and in email, =
when we were talking about shared_ptr, but I could have misunderstood).  Wi=
th the magic of cc we can find out.  Either way, I think the thought still =
stands on its own merit.  But I wouldn't want to misquote Sean.

Also, I would put shared_ptr in the category of "any pointer (or reference)=
 that is shared in different parts of the code".  shared_ptr does some nice=
 ref counting for you, but it is still sharing, and typically that is also =
a problem of its own.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--_000_1278C02F6C8D4ADA81BD3D3C07CEDA7Eadobecom_
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body dir=3D"auto">
<div>The quote referenced includes std::shared_ptr - sharing of data from d=
ifferent locations in the code breaks local reasoning. A shared_ptr can be =
used in the implementation of a data structure, but should't be exposed dir=
ectly.</div>
<div><br>
</div>
<div>I also object to unique_ptr, except as an implementation detail, but f=
or different reasons (unique_ptr strips copy and equality which must then b=
e restored by the owning object).</div>
<div><br>
</div>
<div>See Goal #3 in my C&#43;&#43; Seasoning Talk from GoingNative 2013.</d=
iv>
<div><br>
</div>
<div>Sean</div>
<div><br>
Sent from my iPad</div>
<div><br>
On Apr 29, 2014, at 1:07 PM, &quot;Tony V E&quot; &lt;<a href=3D"mailto:tva=
neerd@gmail.com">tvaneerd@gmail.com</a>&gt; wrote:<br>
<br>
</div>
<blockquote type=3D"cite">
<div>
<div dir=3D"ltr"><br>
<div class=3D"gmail_extra"><br>
<br>
<div class=3D"gmail_quote">On Tue, Apr 29, 2014 at 2:09 PM, David Rodr&iacu=
te;guez Ibeas <span dir=3D"ltr">
&lt;<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@ieee.org</a=
>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">
<div class=3D"">On Mon, Apr 28, 2014 at 10:54 AM, Tony V E <span dir=3D"ltr=
">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmai=
l.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div>
<div>
<div class=3D"gmail_extra">
<div class=3D"gmail_quote"><span style=3D"color:rgb(34,34,34)">&quot;A shar=
ed pointer is as good as a global variable&quot; - Sean Parent.</span><br>
</div>
</div>
</div>
</div>
<div class=3D"gmail_extra"><br>
</div>
<div class=3D"gmail_extra">Shared-pointers are useful in certain situations=
, but now that we have unique_ptr, shared_ptr should typically be avoided.<=
/div>
</div>
</blockquote>
</div>
<div><br>
I believe this is a misrepresentation of what Sean stated. He was not talki=
ng about 'std::shared_ptr', but about any pointer (or reference) that is sh=
ared in different parts of the code.</div>
</div>
</div>
</div>
<div class=3D"HOEnZb">
<div class=3D"h5">
<p></p>
-- <br>
</div>
</div>
</blockquote>
<div><br>
</div>
</div>
Possibly, but I don't think so (he's said it to me directly, and in email, =
when we were talking about shared_ptr, but I could have misunderstood).&nbs=
p; With the magic of cc we can find out.&nbsp; Either way, I think the thou=
ght still stands on its own merit.&nbsp; But I
 wouldn't want to misquote Sean.<br>
<br>
Also, I would put shared_ptr in the category of &quot;any pointer (or refer=
ence) that is shared in different parts of the code&quot;.&nbsp; shared_ptr=
 does some nice ref counting for you, but it is still sharing, and typicall=
y that is also a problem of its own.</div>
<div class=3D"gmail_extra"><br>
</div>
</div>
</div>
</blockquote>
</body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--_000_1278C02F6C8D4ADA81BD3D3C07CEDA7Eadobecom_--

.

------=_Part_1623_33187297.1402540847796
Content-Type: text/plain; charset=UTF-8

sadly this was removed from Rust.

thing is, between keyboard macros and text editor abbreviations (e.g. emacs
'pretty-mode') we could make our own quick abbreviations for more verbose
symbols.
the fly in the ointment is the nesting of template<type_params>;

Perhaps something like D's ability to instantiate a template with a single
sigil  "template_name!type_param_name" would be nice - because you could
insert and display the "template_name!" as a single contiguous string. even
then , maybe that could also be done as a visualisation in a text editor?
although thats harder- balancing < ... > which is itself ambiguous

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1623_33187297.1402540847796
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">sadly this was removed from Rust.<div><br></div><div>thing=
 is, between keyboard macros and text editor abbreviations (e.g. emacs 'pre=
tty-mode') we could make our own quick abbreviations for more verbose symbo=
ls.</div><div>the fly in the ointment is the nesting of template&lt;type_pa=
rams&gt;; &nbsp;&nbsp;</div><div><br></div><div>Perhaps something like D's =
ability to instantiate a template with a single sigil &nbsp;"template_name!=
type_param_name" would be nice - because you could insert and display the "=
template_name!" as a single contiguous string. even then , maybe that could=
 also be done as a visualisation in a text editor? although thats harder- b=
alancing &lt; ... &gt; which is itself ambiguous</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1623_33187297.1402540847796--

.

--089e0160bb6c4a584404fba37206
Content-Type: text/plain; charset=UTF-8

There are a couple of things that could help here, in particular:

auto p = std::make_unique(1);
std::unique_ptr p = new int(1);

The first will be in C++14 for sure, the second one I am not sure, but it
has at least been discussed (inferring template arguments from the
constructor), in neither of the you are naming the type 'int' directly. And
this is for those of us that don't even use IDE often, although I can
imagine smart auto complete system easing the typing.

Even if the typing is exactly as verbose as it is now in C++11, you write
code once, and read it many times. Paying a small higher cost in writing is
acceptable (to me) if that makes the code easier to read (is
'std::unique_ptr<int>' easier/harder to read than 'int~'?)

    David



On Wed, Jun 11, 2014 at 10:40 PM, walter1234 <walter2bz@gmail.com> wrote:

> sadly this was removed from Rust.
>
> thing is, between keyboard macros and text editor abbreviations (e.g.
> emacs 'pretty-mode') we could make our own quick abbreviations for more
> verbose symbols.
> the fly in the ointment is the nesting of template<type_params>;
>
> Perhaps something like D's ability to instantiate a template with a single
> sigil  "template_name!type_param_name" would be nice - because you could
> insert and display the "template_name!" as a single contiguous string. even
> then , maybe that could also be done as a visualisation in a text editor?
> although thats harder- balancing < ... > which is itself ambiguous
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0160bb6c4a584404fba37206
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There are a couple of things that could help here, in part=
icular:<br><br>auto p =3D std::make_unique(1);<br>std::unique_ptr p =3D new=
 int(1);<br><br>The first will be in C++14 for sure, the second one I am no=
t sure, but it has at least been discussed (inferring template arguments fr=
om the constructor), in neither of the you are naming the type &#39;int&#39=
; directly. And this is for those of us that don&#39;t even use IDE often, =
although I can imagine smart auto complete system easing the typing. <br>
<br>Even if the typing is exactly as verbose as it is now in C++11, you wri=
te code once, and read it many times. Paying a small higher cost in writing=
 is acceptable (to me) if that makes the code easier to read (is &#39;std::=
unique_ptr&lt;int&gt;&#39; easier/harder to read than &#39;int~&#39;?)<br>
<br>=C2=A0 =C2=A0 David=C2=A0<div><br></div></div><div class=3D"gmail_extra=
"><br><br><div class=3D"gmail_quote">On Wed, Jun 11, 2014 at 10:40 PM, walt=
er1234 <span dir=3D"ltr">&lt;<a href=3D"mailto:walter2bz@gmail.com" target=
=3D"_blank">walter2bz@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">sadly this was removed from=
 Rust.<div><br></div><div>thing is, between keyboard macros and text editor=
 abbreviations (e.g. emacs &#39;pretty-mode&#39;) we could make our own qui=
ck abbreviations for more verbose symbols.</div>
<div>the fly in the ointment is the nesting of template&lt;type_params&gt;;=
 =C2=A0=C2=A0</div><div><br></div><div>Perhaps something like D&#39;s abili=
ty to instantiate a template with a single sigil =C2=A0&quot;template_name!=
type_param_name&quot; would be nice - because you could insert and display =
the &quot;template_name!&quot; as a single contiguous string. even then , m=
aybe that could also be done as a visualisation in a text editor? although =
thats harder- balancing &lt; ... &gt; which is itself ambiguous</div>
</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0160bb6c4a584404fba37206--

.

On 12 June 2014 16:22, David Rodr=C3=ADguez Ibeas <dibeas@ieee.org> wrote:
> There are a couple of things that could help here, in particular:
>
> auto p =3D std::make_unique(1);
> std::unique_ptr p =3D new int(1);
>
> The first will be in C++14 for sure, the second one I am not sure, but it


The second one will not be in C++14.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--001a11c32c56f9891704fba5e98c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think you mean auto p =3D std::make_unique<int>(1);
On Jun 12, 2014 3:23 PM, "Ville Voutilainen" <ville.voutilainen@gmail.com>
wrote:

> On 12 June 2014 16:22, David Rodr=C3=ADguez Ibeas <dibeas@ieee.org> wrote=
:
> > There are a couple of things that could help here, in particular:
> >
> > auto p =3D std::make_unique(1);
> > std::unique_ptr p =3D new int(1);
> >
> > The first will be in C++14 for sure, the second one I am not sure, but =
it
>
>
> The second one will not be in C++14.
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a11c32c56f9891704fba5e98c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">I think you mean auto p =3D std::make_unique&lt;int&gt;(1);<=
/p>
<div class=3D"gmail_quote">On Jun 12, 2014 3:23 PM, &quot;Ville Voutilainen=
&quot; &lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen=
@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
On 12 June 2014 16:22, David Rodr=C3=ADguez Ibeas &lt;<a href=3D"mailto:dib=
eas@ieee.org">dibeas@ieee.org</a>&gt; wrote:<br>
&gt; There are a couple of things that could help here, in particular:<br>
&gt;<br>
&gt; auto p =3D std::make_unique(1);<br>
&gt; std::unique_ptr p =3D new int(1);<br>
&gt;<br>
&gt; The first will be in C++14 for sure, the second one I am not sure, but=
 it<br>
<br>
<br>
The second one will not be in C++14.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c32c56f9891704fba5e98c--

.

--001a113a772096df3404fba8a434
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Never used them... still living in C++03, no boost. Now that is an
interesting realization, you *need* to provide the type to `make_unique`,
and that brings the question of whether this needs to be so or whether an
additional overload could be added with a single template argument that
could be deduced:

template <typename T>
std::unique_ptr<typename std::remove_const<typename
std::remove_reference<T>::type>::type>
make_unique(T&&);

Or something similar to this that provides. If no template argument is
provided, the existing overloads are discarded as the type of the
'unique_ptr' to create cannot be deduced, and this would be picked up as
the only viable alternative, creating a unique pointer to the same type
that was passed as argument to the function.

I am not 100% sure how overload resolution would select this or the
existing overloads when user code provides the template argument and a
single function argument that is a potentially cv-qualified T. I don't
think this would cause an ambiguity, and which overload gets picked should
not really matter as the behavior should be exactly the same either way.

    David

BTW, the same could also be applied to std::make_shared



On Thu, Jun 12, 2014 at 12:18 PM, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:

> I think you mean auto p =3D std::make_unique<int>(1);
> On Jun 12, 2014 3:23 PM, "Ville Voutilainen" <ville.voutilainen@gmail.com=
>
> wrote:
>
>> On 12 June 2014 16:22, David Rodr=C3=ADguez Ibeas <dibeas@ieee.org> wrot=
e:
>> > There are a couple of things that could help here, in particular:
>> >
>> > auto p =3D std::make_unique(1);
>> > std::unique_ptr p =3D new int(1);
>> >
>> > The first will be in C++14 for sure, the second one I am not sure, but
>> it
>>
>>
>> The second one will not be in C++14.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>  --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a113a772096df3404fba8a434
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Never used them... still living in C++03, no boost. Now th=
at is an interesting realization, you *need* to provide the type to `make_u=
nique`, and that brings the question of whether this needs to be so or whet=
her an additional overload could be added with a single template argument t=
hat could be deduced:<br>
<br>template &lt;typename T&gt;<br>std::unique_ptr&lt;typename std::remove_=
const&lt;typename std::remove_reference&lt;T&gt;::type&gt;::type&gt; <br>ma=
ke_unique(T&amp;&amp;);<br><br>Or something similar to this that provides. =
If no template argument is provided, the existing overloads are discarded a=
s the type of the &#39;unique_ptr&#39; to create cannot be deduced, and thi=
s would be picked up as the only viable alternative, creating a unique poin=
ter to the same type that was passed as argument to the function.<br>
<br>I am not 100% sure how overload resolution would select this or the exi=
sting overloads when user code provides the template argument and a single =
function argument that is a potentially cv-qualified T. I don&#39;t think t=
his would cause an ambiguity, and which overload gets picked should not rea=
lly matter as the behavior should be exactly the same either way.<br>
<br>=C2=A0 =C2=A0 David<br><br>BTW, the same could also be applied to std::=
make_shared<br><br></div><div class=3D"gmail_extra"><br><br><div class=3D"g=
mail_quote">On Thu, Jun 12, 2014 at 12:18 PM, Andrew Tomazos <span dir=3D"l=
tr">&lt;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrew=
tomazos@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><p dir=3D"ltr">I think you mean auto p =3D s=
td::make_unique&lt;int&gt;(1);</p><div class=3D"HOEnZb"><div class=3D"h5">
<div class=3D"gmail_quote">On Jun 12, 2014 3:23 PM, &quot;Ville Voutilainen=
&quot; &lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank"=
>ville.voutilainen@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">

On 12 June 2014 16:22, David Rodr=C3=ADguez Ibeas &lt;<a href=3D"mailto:dib=
eas@ieee.org" target=3D"_blank">dibeas@ieee.org</a>&gt; wrote:<br>
&gt; There are a couple of things that could help here, in particular:<br>
&gt;<br>
&gt; auto p =3D std::make_unique(1);<br>
&gt; std::unique_ptr p =3D new int(1);<br>
&gt;<br>
&gt; The first will be in C++14 for sure, the second one I am not sure, but=
 it<br>
<br>
<br>
The second one will not be in C++14.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113a772096df3404fba8a434--

.

--047d7b5d2deac1ac7704fba8d23f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 12 June 2014 14:34, David Rodr=C3=ADguez Ibeas <dibeas@ieee.org> wrote:

> Never used them... still living in C++03, no boost. Now that is an
> interesting realization, you *need* to provide the type to `make_unique`,
> and that brings the question of whether this needs to be so or whether an
> additional overload could be added with a single template argument that
> could be deduced:
>
> template <typename T>
> std::unique_ptr<typename std::remove_const<typename
> std::remove_reference<T>::type>::type>
> make_unique(T&&);
>

You pass constructor *parameters* to make_unique.  It is impossible from
the parameters to deduce what type to actually construct.

For instance:

struct A
{
    A(int) {}
};

struct B
{
    B(int) {}
};

What should your make_unique(0) construct?  unique_ptr<A>, unique_ptr<B>,
unique_ptr<int> or something else?




>
> Or something similar to this that provides. If no template argument is
> provided, the existing overloads are discarded as the type of the
> 'unique_ptr' to create cannot be deduced, and this would be picked up as
> the only viable alternative, creating a unique pointer to the same type
> that was passed as argument to the function.
>
> I am not 100% sure how overload resolution would select this or the
> existing overloads when user code provides the template argument and a
> single function argument that is a potentially cv-qualified T. I don't
> think this would cause an ambiguity, and which overload gets picked shoul=
d
> not really matter as the behavior should be exactly the same either way.
>
>     David
>
> BTW, the same could also be applied to std::make_shared
>
>
>
> On Thu, Jun 12, 2014 at 12:18 PM, Andrew Tomazos <andrewtomazos@gmail.com=
>
> wrote:
>
>> I think you mean auto p =3D std::make_unique<int>(1);
>> On Jun 12, 2014 3:23 PM, "Ville Voutilainen" <ville.voutilainen@gmail.co=
m>
>> wrote:
>>
>>> On 12 June 2014 16:22, David Rodr=C3=ADguez Ibeas <dibeas@ieee.org> wro=
te:
>>> > There are a couple of things that could help here, in particular:
>>> >
>>> > auto p =3D std::make_unique(1);
>>> > std::unique_ptr p =3D new int(1);
>>> >
>>> > The first will be in C++14 for sure, the second one I am not sure, bu=
t
>>> it
>>>
>>>
>>> The second one will not be in C++14.
>>>
>>> --
>>>
>>> ---
>>> 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.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>  --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>



--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7b5d2deac1ac7704fba8d23f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 12 June 2014 14:34, David Rodr=C3=ADguez Ibeas <span di=
r=3D"ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@i=
eee.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">Never used them... still living in C++03, no boost. Now th=
at is an interesting realization, you *need* to provide the type to `make_u=
nique`, and that brings the question of whether this needs to be so or whet=
her an additional overload could be added with a single template argument t=
hat could be deduced:<br>


<br>template &lt;typename T&gt;<br>std::unique_ptr&lt;typename std::remove_=
const&lt;typename std::remove_reference&lt;T&gt;::type&gt;::type&gt; <br>ma=
ke_unique(T&amp;&amp;);<br></div></blockquote><div><br></div><div>You pass =
constructor <i>parameters</i>=C2=A0to make_unique. =C2=A0It is impossible f=
rom the parameters to deduce what type to actually construct.</div>

<div><br></div><div>For instance:</div><div><br></div><div>struct A</div><d=
iv>{</div><div>=C2=A0 =C2=A0 A(int) {}</div><div>};</div><div><br></div><di=
v>struct B</div><div>{</div><div>=C2=A0 =C2=A0 B(int) {}</div><div>};</div>=
<div><br></div>
<div>
What should your make_unique(0) construct? =C2=A0unique_ptr&lt;A&gt;, uniqu=
e_ptr&lt;B&gt;, unique_ptr&lt;int&gt; or something else?</div><div><br></di=
v><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><br>Or something similar to this that provides. If no temp=
late argument is provided, the existing overloads are discarded as the type=
 of the &#39;unique_ptr&#39; to create cannot be deduced, and this would be=
 picked up as the only viable alternative, creating a unique pointer to the=
 same type that was passed as argument to the function.<br>


<br>I am not 100% sure how overload resolution would select this or the exi=
sting overloads when user code provides the template argument and a single =
function argument that is a potentially cv-qualified T. I don&#39;t think t=
his would cause an ambiguity, and which overload gets picked should not rea=
lly matter as the behavior should be exactly the same either way.<br>


<br>=C2=A0 =C2=A0 David<br><br>BTW, the same could also be applied to std::=
make_shared<br><br></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=
=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Jun 12, 2014 at=
 12:18 PM, Andrew Tomazos <span dir=3D"ltr">&lt;<a href=3D"mailto:andrewtom=
azos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</a>&gt;</span> wr=
ote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><p dir=3D"ltr">I think you mean auto p =3D s=
td::make_unique&lt;int&gt;(1);</p><div><div>
<div class=3D"gmail_quote">On Jun 12, 2014 3:23 PM, &quot;Ville Voutilainen=
&quot; &lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank"=
>ville.voutilainen@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">



On 12 June 2014 16:22, David Rodr=C3=ADguez Ibeas &lt;<a href=3D"mailto:dib=
eas@ieee.org" target=3D"_blank">dibeas@ieee.org</a>&gt; wrote:<br>
&gt; There are a couple of things that could help here, in particular:<br>
&gt;<br>
&gt; auto p =3D std::make_unique(1);<br>
&gt; std::unique_ptr p =3D new int(1);<br>
&gt;<br>
&gt; The first will be in C++14 for sure, the second one I am not sure, but=
 it<br>
<br>
<br>
The second one will not be in C++14.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@=
eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (8=
47) 691-1404
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b5d2deac1ac7704fba8d23f--

.

--047d7bdc96c84641bb04fba9b364
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

What I was thinking is that, if the type of the unique_ptr to be created is
not provided by the user, the library could assume that this was meant to
use copy construction, in the same way that std::make_pair does. I haven't
thought this through, but I don't see this as a horrible breaking change.

For existing code, the user is providing the type to use in the unique
pointer and that is fine and will continue working.

The type of the unique pointer would become optional only in the 1 argument
construction, and would default to the deduced type of the argument
(barring cv-qualifiers and references).

// Currently legal
auto a =3D make_unique<int>(1.);      // a is unique_ptr<int>

// Currently illegal:
auto b =3D make_unique(1);               // b is also unique_ptr<int>
auto c =3D make_unique(1.);              / c is unique_ptr<double>

I don't think that the behavior of the last two lines would be particularly
confusing for users. If you need to pass more than one argument, or if you
want to construct something that is not of the type of the first argument,
then user code needs to provide the type (as it does today).

    David


On Thu, Jun 12, 2014 at 3:46 PM, Nevin Liber <nevin@eviloverlord.com> wrote=
:

> On 12 June 2014 14:34, David Rodr=C3=ADguez Ibeas <dibeas@ieee.org> wrote=
:
>
>> Never used them... still living in C++03, no boost. Now that is an
>> interesting realization, you *need* to provide the type to `make_unique`=
,
>> and that brings the question of whether this needs to be so or whether a=
n
>> additional overload could be added with a single template argument that
>> could be deduced:
>>
>> template <typename T>
>> std::unique_ptr<typename std::remove_const<typename
>> std::remove_reference<T>::type>::type>
>> make_unique(T&&);
>>
>
> You pass constructor *parameters* to make_unique.  It is impossible from
> the parameters to deduce what type to actually construct.
>
> For instance:
>
> struct A
> {
>     A(int) {}
> };
>
> struct B
> {
>     B(int) {}
> };
>
>  What should your make_unique(0) construct?  unique_ptr<A>, unique_ptr<B>=
,
> unique_ptr<int> or something else?
>
>
>
>
>>
>> Or something similar to this that provides. If no template argument is
>> provided, the existing overloads are discarded as the type of the
>> 'unique_ptr' to create cannot be deduced, and this would be picked up as
>> the only viable alternative, creating a unique pointer to the same type
>> that was passed as argument to the function.
>>
>> I am not 100% sure how overload resolution would select this or the
>> existing overloads when user code provides the template argument and a
>> single function argument that is a potentially cv-qualified T. I don't
>> think this would cause an ambiguity, and which overload gets picked shou=
ld
>> not really matter as the behavior should be exactly the same either way.
>>
>>     David
>>
>> BTW, the same could also be applied to std::make_shared
>>
>>
>>
>> On Thu, Jun 12, 2014 at 12:18 PM, Andrew Tomazos <andrewtomazos@gmail.co=
m
>> > wrote:
>>
>>> I think you mean auto p =3D std::make_unique<int>(1);
>>> On Jun 12, 2014 3:23 PM, "Ville Voutilainen" <
>>> ville.voutilainen@gmail.com> wrote:
>>>
>>>> On 12 June 2014 16:22, David Rodr=C3=ADguez Ibeas <dibeas@ieee.org> wr=
ote:
>>>> > There are a couple of things that could help here, in particular:
>>>> >
>>>> > auto p =3D std::make_unique(1);
>>>> > std::unique_ptr p =3D new int(1);
>>>> >
>>>> > The first will be in C++14 for sure, the second one I am not sure,
>>>> but it
>>>>
>>>>
>>>> The second one will not be in C++14.
>>>>
>>>> --
>>>>
>>>> ---
>>>> 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.
>>>> Visit this group at
>>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>>
>>>  --
>>>
>>> ---
>>> 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.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
>
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7bdc96c84641bb04fba9b364
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">What I was thinking is that, if the type of the unique_ptr=
 to be created is not provided by the user, the library could assume that t=
his was meant to use copy construction, in the same way that std::make_pair=
 does. I haven&#39;t thought this through, but I don&#39;t see this as a ho=
rrible breaking change.<br>
<br>For existing code, the user is providing the type to use in the unique =
pointer and that is fine and will continue working.<br><br>The type of the =
unique pointer would become optional only in the 1 argument construction, a=
nd would default to the deduced type of the argument (barring cv-qualifiers=
 and references).<br>
<br>// Currently legal<br>auto a =3D make_unique&lt;int&gt;(1.); =C2=A0 =C2=
=A0 =C2=A0// a is unique_ptr&lt;int&gt;<div><br>// Currently illegal:<br>au=
to b =3D make_unique(1); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=
/ b is also unique_ptr&lt;int&gt;<br>auto c =3D make_unique(1.); =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ c is unique_ptr&lt;double&gt;<br>
<br>I don&#39;t think that the behavior of the last two lines would be part=
icularly confusing for users. If you need to pass more than one argument, o=
r if you want to construct something that is not of the type of the first a=
rgument, then user code needs to provide the type (as it does today).<br>
<br>=C2=A0 =C2=A0 David</div></div><div class=3D"gmail_extra"><br><br><div =
class=3D"gmail_quote">On Thu, Jun 12, 2014 at 3:46 PM, Nevin Liber <span di=
r=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">n=
evin@eviloverlord.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"">On 12 June =
2014 14:34, David Rodr=C3=ADguez Ibeas <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:dibeas@ieee.org" target=3D"_blank">dibeas@ieee.org</a>&gt;</span> wrote=
:<br>
</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D""=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">Never used them... still living in C++03, no boost. Now th=
at is an interesting realization, you *need* to provide the type to `make_u=
nique`, and that brings the question of whether this needs to be so or whet=
her an additional overload could be added with a single template argument t=
hat could be deduced:<br>



<br>template &lt;typename T&gt;<br>std::unique_ptr&lt;typename std::remove_=
const&lt;typename std::remove_reference&lt;T&gt;::type&gt;::type&gt; <br>ma=
ke_unique(T&amp;&amp;);<br></div></blockquote><div><br></div></div><div>
You pass constructor <i>parameters</i>=C2=A0to make_unique. =C2=A0It is imp=
ossible from the parameters to deduce what type to actually construct.</div=
>

<div><br></div><div>For instance:</div><div><br></div><div>struct A</div><d=
iv>{</div><div>=C2=A0 =C2=A0 A(int) {}</div><div>};</div><div><br></div><di=
v>struct B</div><div>{</div><div>=C2=A0 =C2=A0 B(int) {}</div><div>};</div>=
<div><br></div>

<div>
What should your make_unique(0) construct? =C2=A0unique_ptr&lt;A&gt;, uniqu=
e_ptr&lt;B&gt;, unique_ptr&lt;int&gt; or something else?</div><div><div cla=
ss=3D"h5"><div><br></div><div><br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">


<div dir=3D"ltr"><br>Or something similar to this that provides. If no temp=
late argument is provided, the existing overloads are discarded as the type=
 of the &#39;unique_ptr&#39; to create cannot be deduced, and this would be=
 picked up as the only viable alternative, creating a unique pointer to the=
 same type that was passed as argument to the function.<br>



<br>I am not 100% sure how overload resolution would select this or the exi=
sting overloads when user code provides the template argument and a single =
function argument that is a potentially cv-qualified T. I don&#39;t think t=
his would cause an ambiguity, and which overload gets picked should not rea=
lly matter as the behavior should be exactly the same either way.<br>



<br>=C2=A0 =C2=A0 David<br><br>BTW, the same could also be applied to std::=
make_shared<br><br></div><div><div><div class=3D"gmail_extra"><br><br><div =
class=3D"gmail_quote">On Thu, Jun 12, 2014 at 12:18 PM, Andrew Tomazos <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_bla=
nk">andrewtomazos@gmail.com</a>&gt;</span> wrote:<br>



<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><p dir=3D"ltr">I think you mean auto p =3D s=
td::make_unique&lt;int&gt;(1);</p><div><div>
<div class=3D"gmail_quote">On Jun 12, 2014 3:23 PM, &quot;Ville Voutilainen=
&quot; &lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank"=
>ville.voutilainen@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">




On 12 June 2014 16:22, David Rodr=C3=ADguez Ibeas &lt;<a href=3D"mailto:dib=
eas@ieee.org" target=3D"_blank">dibeas@ieee.org</a>&gt; wrote:<br>
&gt; There are a couple of things that could help here, in particular:<br>
&gt;<br>
&gt; auto p =3D std::make_unique(1);<br>
&gt; std::unique_ptr p =3D new int(1);<br>
&gt;<br>
&gt; The first will be in C++14 for sure, the second one I am not sure, but=
 it<br>
<br>
<br>
The second one will not be in C++14.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div></div></div><span class=3D"HOEnZb"><font col=
or=3D"#888888"><br><br clear=3D"all"><div><br></div>-- <br>=C2=A0Nevin &quo=
t;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com=
" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 <a href=3D"tel:%28=
847%29%20691-1404" value=3D"+18476911404" target=3D"_blank">(847) 691-1404<=
/a>
</font></span></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bdc96c84641bb04fba9b364--

.

--f46d0435c05257c4d804fbaa8135
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 12 June 2014 15:49, David Rodr=C3=ADguez Ibeas <dibeas@ieee.org> wrote:

> What I was thinking is that, if the type of the unique_ptr to be created
> is not provided by the user, the library could assume that this was meant
> to use copy construction, in the same way that std::make_pair does.
>

Do you have a particularly compelling use case?  Even though every idea has
at least one use case, just because we *can* do something doesn't mean we
*should* do something.

More often than not, the uses of unique_ptr involve non-copyable types,
non-moveable types and polymorphic types.  Your feature would be useless
for the first two, and error prone for the third (accidental slicing).  I
find it very rare that I want to copy (as opposed to cloning a polymorphic
type already stored on the heap) a currently existing object into a
unique_ptr.

In short, so far I would be strongly against such a change in interface.

> --
>
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--f46d0435c05257c4d804fbaa8135
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 12 June 2014 15:49, David Rodr=C3=ADguez Ibeas <span di=
r=3D"ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@i=
eee.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">What I was thinking is that, if the type of the unique_ptr=
 to be created is not provided by the user, the library could assume that t=
his was meant to use copy construction, in the same way that std::make_pair=
 does.=C2=A0</div>

</blockquote><div><br></div><div>Do you have a particularly compelling use =
case? =C2=A0Even though every idea has at least one use case, just because =
we <i>can</i> do something doesn&#39;t mean we <i>should</i> do something.<=
/div>

<div><br></div><div>More often than not, the uses of unique_ptr involve non=
-copyable types, non-moveable types and polymorphic types. =C2=A0Your featu=
re would be useless for the first two, and error prone for the third (accid=
ental slicing). =C2=A0I find it very rare that I want to copy (as opposed t=
o cloning a polymorphic type already stored on the heap) a currently existi=
ng object into a unique_ptr.</div>

<div><br></div><div>In short, so far I would be strongly against such a cha=
nge in interface.</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">--=
=C2=A0<br>

</div></blockquote></div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto=
:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilover=
lord.com</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--f46d0435c05257c4d804fbaa8135--

.

------=_Part_822_1358413728.1406395140599
Content-Type: text/plain; charset=UTF-8

i would like to see something like this but more so if it could be done by
some sort of general operator overload/ 'sigil-overloading'.

i was very disappointed when Rust lost this feature. it had a certain
elegance IMO, the way the most common collections and types melted away and
left you reading meaningful names in your source.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_822_1358413728.1406395140599
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">i would like to see something like this but more so if it =
could be done by some sort of general operator overload/ 'sigil-overloading=
'.<div><br><div>i was very disappointed when Rust lost this feature. it had=
 a certain elegance IMO, the way the most common collections and types melt=
ed away and left you reading meaningful names in your source.</div></div></=
div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_822_1358413728.1406395140599--

.

On Sat, Jul 26, 2014 at 7:19 PM, walter1234 wrote:
> i would like to see something like this but more so if it could be done by
> some sort of general operator overload/ 'sigil-overloading'.

I don't. It just adds to the core language with little benefit and a
couple of disadvantages. See below.

> i was very disappointed when Rust lost this feature. it had a certain
> elegance IMO, the way the most common collections and types melted away
> and left you reading meaningful names in your source.

There are good reasons why ~T turned into a library type Box<T> in
Rust. These reasons also apply to C++. The primary reason being that
Box<T> (and unique_ptr<T>) support different deleters. They have a
second generic type parameter that is typically defaulted. Another
(IMHO) good reason would be that ~T makes the core language more
complicated. There is really no need for special casing something like
this which could just as well be a library type. And finally, I find
the "~T" syntax not beginner-friendly. "Box<T>" is a bit more
self-explanatory.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.