2012/12/15 R. Martinho Fernandes <martinho.fernandes@gmail.com>:
> I have once before asked about this on Stack Overflow
> http://stackoverflow.com/questions/9157041/what-could-go-wrong-if-copy-list-initialization-allowed-explicit-constructors.
> I would really like to get rid of this nuissance.

I'm not convinced yet that there is a defect here in regard to
explicit constructors. I don't think that the problem is that you have
to to provide some explicit naming, the problem is some form of naming
duplication, which also has the tendency to be missed by code
refactorings. A possible solution could be based on a  language tool
that already exists for similar reasons, namely auto. What about:

std::unique_ptr<foo> bar(bool baz)
{
    if(baz)
        return {};

    return auto{ new foo };
}

This makes clear for the second return statement, that

a) we don't return foo, but we return the type already named as
function return type, suitably converted *from* "new foo"
b) it get rids of the naming duplication of the return type (which
might be changed to some other smart pointer type, for example)

This satisfies similar needs as auto for object declarations and is
more or the less the counterpart to lambda expression with auto-return
type deduction.

- Daniel

--




.

On Sat, Dec 15, 2012 at 7:06 AM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
> 2012/12/15 R. Martinho Fernandes <martinho.fernandes@gmail.com>:
>> I have once before asked about this on Stack Overflow
>> http://stackoverflow.com/questions/9157041/what-could-go-wrong-if-copy-l=
ist-initialization-allowed-explicit-constructors.
>> I would really like to get rid of this nuissance.
>
> I'm not convinced yet that there is a defect here in regard to
> explicit constructors. I don't think that the problem is that you have
> to to provide some explicit naming, the problem is some form of naming
> duplication, which also has the tendency to be missed by code
> refactorings. A possible solution could be based on a  language tool
> that already exists for similar reasons, namely auto. What about:
>
> std::unique_ptr<foo> bar(bool baz)
> {
>     if(baz)
>         return {};
>
>     return auto{ new foo };
> }
>
> This makes clear for the second return statement, that
>
> a) we don't return foo, but we return the type already named as
> function return type, suitably converted *from* "new foo"
> b) it get rids of the naming duplication of the return type (which
> might be changed to some other smart pointer type, for example)
>
> This satisfies similar needs as auto for object declarations and is
> more or the less the counterpart to lambda expression with auto-return
> type deduction.

A language extension isn't essential here if you're willing to accept
an extra token in the return:

template<typename T>
struct Converter {
  T val_;
  Converter(T val) : val_(std::forward<T>(val)) {}
  template<typename U> /*implicit*/ operator U() { return
U(std::forward<T>(t)); }
};
template<typename T>
Converter<T> convert(T&& val) { return Converter<T>(std::forward<T>(val)); =
}

std::unique_ptr<int> foo() {
  return convert(new int(3));
}

See the (non-public, sorry) thread including c++std-ext-14049.

Jeffrey

--=20




.

On Mon, Dec 17, 2012 at 9:42 PM, DeadMG <wolfeinstein@gmail.com> wrote:
> I think that for passing arguments, it is not so bad, because then you have
> overload resolution and such. However, when you are returning, there is only
> one type possibly under consideration, and it's quite explicit that you are
> constructing that type. Having to specify the return type again is just
> unnecessary code duplication.

That's the choice made when making a constructor explicit, isn't it?

Should those two be equivalent?
vector v(10);
vector v = 10;

Should return 10 work when the return type is vector? Should return {
10 }; work?

Are we looking for a middle ground between implcit and explicit for some cases?


--
Olaf

--




.

------=_Part_14_19509366.1355847344026
Content-Type: text/plain; charset=ISO-8859-1



Am Dienstag, 18. Dezember 2012 00:56:52 UTC+1 schrieb Olaf van der Spek:
>
> On Mon, Dec 17, 2012 at 9:42 PM, DeadMG <wolfei...@gmail.com <javascript:>>
> wrote:
> > I think that for passing arguments, it is not so bad, because then you
> have
> > overload resolution and such. However, when you are returning, there is
> only
> > one type possibly under consideration, and it's quite explicit that you
> are
> > constructing that type. Having to specify the return type again is just
> > unnecessary code duplication.
>
> That's the choice made when making a constructor explicit, isn't it?
>
> Should those two be equivalent?
> vector v(10);
> vector v = 10;
>
> Should return 10 work when the return type is vector? Should return {
> 10 }; work?
>
> Are we looking for a middle ground between implcit and explicit for some
> cases?
>
>
> --
> Olaf
>
Wouldn't return {10}; just call the initializer_list constructor?
Yes, I think we're looking for something inbetween implicit and explicit.

--




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

<br><br>Am Dienstag, 18. Dezember 2012 00:56:52 UTC+1 schrieb Olaf van der =
Spek:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Dec 17, 2012 at 9=
:42 PM, DeadMG &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"_aF4zloJRGMJ">wolfei...@gmail.com</a>&gt; wrote:
<br>&gt; I think that for passing arguments, it is not so bad, because then=
 you have
<br>&gt; overload resolution and such. However, when you are returning, the=
re is only
<br>&gt; one type possibly under consideration, and it's quite explicit tha=
t you are
<br>&gt; constructing that type. Having to specify the return type again is=
 just
<br>&gt; unnecessary code duplication.
<br>
<br>That's the choice made when making a constructor explicit, isn't it?
<br>
<br>Should those two be equivalent?
<br>vector v(10);
<br>vector v =3D 10;
<br>
<br>Should return 10 work when the return type is vector? Should return {
<br>10 }; work?
<br>
<br>Are we looking for a middle ground between implcit and explicit for som=
e cases?
<br>
<br>
<br>--=20
<br>Olaf
<br></blockquote><div>Wouldn't return {10}; just call the initializer_list =
constructor?<br>Yes, I think we're looking for something inbetween implicit=
 and explicit.<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_14_19509366.1355847344026--

.

On Tue, Dec 18, 2012 at 5:15 PM,  <stackmachine@hotmail.com> wrote:
> Wouldn't return {10}; just call the initializer_list constructor?

Yes, but suppose we've got a class that doesn't have such a constructor.



--
Olaf

--




.

------=_Part_66_19364043.1355848626480
Content-Type: text/plain; charset=ISO-8859-1



Am Dienstag, 18. Dezember 2012 17:17:00 UTC+1 schrieb Olaf van der Spek:
>
> On Tue, Dec 18, 2012 at 5:15 PM,  <stackm...@hotmail.com <javascript:>>
> wrote:
> > Wouldn't return {10}; just call the initializer_list constructor?
>
> Yes, but suppose we've got a class that doesn't have such a constructor.
>
>
>
> --
> Olaf
>
IMO, return { 10 }; should be allowed, return 10 shouldn't.

--




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

<br><br>Am Dienstag, 18. Dezember 2012 17:17:00 UTC+1 schrieb Olaf van der =
Spek:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Dec 18, 2012 at 5=
:15 PM, &nbsp;&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"kHWN0iUNQM8J">stackm...@hotmail.com</a>&gt; wrote:
<br>&gt; Wouldn't return {10}; just call the initializer_list constructor?
<br>
<br>Yes, but suppose we've got a class that doesn't have such a constructor=
..
<br>
<br>
<br>
<br>--=20
<br>Olaf
<br></blockquote><div>IMO, return { 10 }; should be allowed, return 10 shou=
ldn't.<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_66_19364043.1355848626480--

.