------=_Part_5804_490335835.1412188987617
Content-Type: text/plain; charset=UTF-8

Paragraph 7.1.6.4/7 [dcl.type.elab] specifies that a variable declaration
using "auto" behaves pretty much (concerning type deduction) like a
function template call with a fictitious argument, so the problem of
determining the type of "i" below:

const auto &i = expr;

Is mechanically translated into the problem of determining the type of "u"
below when calling "f(expr)":

template <class U> void f(const U& u);

Currently, the following declaration is not legal:

std::unique_ptr<auto> p = foo();

As far as I can tell, this is just one particular instance of the same
problem. The type of "p" above would be the same as the type of the
parameter "u" below when calling "f(foo())":

template <class U> void f(std::unique_ptr<U> u);

Do you think it makes sense to generalize the rule and allow
initializations like the one above?

Of course this would then apply to generic lambdas as well, and to terse
syntax for function templates introduced by Concepts Lite:

auto l = [] (std::unique_ptr<auto> p) { ... };

void foo(std::vector<auto> const& v) { ... }

Kind regards,

Andy

--

---
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_5804_490335835.1412188987617
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Paragraph 7.1.6.4/7 [dcl.type.elab] specifies that a varia=
ble declaration using "auto" behaves pretty much (concerning type deduction=
) like a function template call with a fictitious argument, so the problem =
of determining the type of "i" below:<br><br><div class=3D"prettyprint" sty=
le=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgrou=
nd-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">con=
st</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">i </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> expr</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span></div></code></div><br>Is mechanically translate=
d into the problem of determining the type of "u" below when calling "f(exp=
r)":<div><br></div><div><div class=3D"prettyprint" style=3D"border: 1px sol=
id rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 25=
0, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">template</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> U</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> U</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> u</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span></div></code></div><br>Currently, the =
following declaration is not legal:<br><br><div class=3D"prettyprint" style=
=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; background=
-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">unique_ptr</span><sp=
an style=3D"color: #080;" class=3D"styled-by-prettify">&lt;auto&gt;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> p </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">();</span></div></code></div><br>As fa=
r as I can tell, this is just one particular instance of the same problem. =
The type of "p" above would be the same as the type of the parameter "u" be=
low when calling "f(foo())":<br><br><div class=3D"prettyprint" style=3D"bor=
der: 1px solid rgb(187, 187, 187); font-size: 13.3333330154419px; word-wrap=
: break-word; background-color: rgb(250, 250, 250);"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">template</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> U<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">unique_ptr</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">U</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> u</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></=
div>&nbsp;<br>Do you think it makes sense to generalize the rule and allow =
initializations like the one above?<br><br>Of course this would then apply =
to generic lambdas as well, and to terse syntax for function templates intr=
oduced by Concepts Lite:<br><br><div class=3D"prettyprint" style=3D"border:=
 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb=
(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> l </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">[]</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=
:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">unique_pt=
r</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;auto&=
gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> p</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><font color=3D"#666600"><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">...</span></font><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">vector=
</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;auto&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><font=
 color=3D"#666600"><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">}</span></font></div></code></div><br>Kind regards,<br><br>A=
ndy</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_5804_490335835.1412188987617--

.

On 1 October 2014 21:43, Andy Prowl <andy.prowl@gmail.com> wrote:
> Currently, the following declaration is not legal:
>
> std::unique_ptr<auto> p = foo();
>
> As far as I can tell, this is just one particular instance of the same
> problem. The type of "p" above would be the same as the type of the
> parameter "u" below when calling "f(foo())":
>
> template <class U> void f(std::unique_ptr<U> u);
>
> Do you think it makes sense to generalize the rule and allow initializations
> like the one above?


Yes, I think it would. Do remember, though, that if we allow, say

pair<auto, auto> x = foo();

it's somewhat likely that someone somewhere will ask "how do I express a pair
where the types must not be the same?"

--

---
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_474_1824188928.1412189595077
Content-Type: text/plain; charset=UTF-8

Good point, I don't have an answer to that. Do you think it's a blocking
problem?

Andy

--

---
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_474_1824188928.1412189595077
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Good point,&nbsp;I don't have an answer to that. Do you think it's a blocking problem?<br><div><br>Andy</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 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_474_1824188928.1412189595077--

.

------=_Part_552_1316350822.1412190708741
Content-Type: text/plain; charset=UTF-8

Actually, wouldn't it be enough to add a static_assert after the
declaration?

pair<auto, auto> x = foo();
static_assert(decltype(x.first) != decltype(x.second), "Error");

Andy

--

---
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_552_1316350822.1412190708741
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Actually, wouldn't it be enough to add a static_assert aft=
er the declaration?<br><br><div class=3D"prettyprint" style=3D"border: 1px =
solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250,=
 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">pair</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">auto</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">static_assert</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">decltype</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">first</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">!=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">second</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">),</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettif=
y">"Error"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
);</span></div></code></div><br>Andy</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_552_1316350822.1412190708741--

.

------=_Part_4044_904365835.1412190759482
Content-Type: text/plain; charset=UTF-8

Err, pardon:

static_assert(!std::is_same<decltype(x.first), decltype(x.second)>(),
"Error");

Andy

--

---
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_4044_904365835.1412190759482
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Err, pardon:<br><br><div class=3D"prettyprint" style=3D"bo=
rder: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color=
: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><span style=3D"color: #008;" class=3D"styled-by-prettify">static_asse=
rt</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(!</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">is_same</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">decltype</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">x</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">first</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>),</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">second</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">)&gt;(),</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">"Error"</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">);</span></div></code></div><br><div>Andy</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_4044_904365835.1412190759482--

.

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

To do that, you should expand 'auto' semantics to allow parameter type iden=
tifiers to be explicitly specified, instead of being implicit (plain auto).=
 Which just leads you to using template parameters as an already existing s=
yntax. Also remember that identifiers declared with 'auto' refer to values.=
 So you can't do what Ville said without messing auto, seriously.


On October 1, 2014 9:53:15 PM EEST, Andy Prowl <andy.prowl@gmail.com> wrote=
:
>Good point, I don't have an answer to that. Do you think it's a
>blocking=20
>problem?
>
>Andy
>
>--=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/.

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

<html><head></head><body><p dir=3D"ltr">To do that, you should expand 'auto=
' semantics to allow parameter type identifiers to be explicitly specified,=
 instead of being implicit (plain auto). Which just leads you to using temp=
late parameters as an already existing syntax. Also remember that identifie=
rs declared with 'auto' refer to values. So you can't do what Ville said wi=
thout messing auto, seriously.<br>
</p>
<br><br><div class=3D"gmail_quote">On October 1, 2014 9:53:15 PM EEST, Andy=
 Prowl &lt;andy.prowl@gmail.com&gt; wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 2=
04); padding-left: 1ex;">
<div dir=3D"ltr">Good point,&nbsp;I don't have an answer to that. Do you th=
ink it's a blocking problem?<br /><div><br />Andy</div></div>

<p></p>
</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 />

------4AZOIFOYRLOIYPO4NHJUP2ZOJVRMKY--


.

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

You are then unable to provide a match for your proposed std::pair<auto,aut=
o> in a function type signature, function template overload, class template=
 partial specialization for where different types are required, without mak=
ing this a 'catch-all' pattern in a deducible context of a template paramet=
er list. Therefore, because of this implicit assumption, you are continuous=
ly forced to use sfinae (and expand the rules for it) every time you'd use =
such syntax.

Consider also interaction with concepts and variadics. Not a pretty or unam=
biguous sight.


On October 1, 2014 10:12:39 PM EEST, Andy Prowl <andy.prowl@gmail.com> wrot=
e:
>Err, pardon:
>
>static_assert(!std::is_same<decltype(x.first), decltype(x.second)>(),=20
>"Error");
>
>Andy
>
>--=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/.

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

<html><head></head><body><p dir=3D"ltr">You are then unable to provide a ma=
tch for your proposed std::pair&lt;auto,auto&gt; in a function type signatu=
re, function template overload, class template partial specialization for w=
here different types are required, without making this a 'catch-all' patter=
n in a deducible context of a template parameter list. Therefore, because o=
f this implicit assumption, you are continuously forced to use sfinae (and =
expand the rules for it) every time you'd use such syntax.</p>
<p dir=3D"ltr">Consider also interaction with concepts and variadics. Not a=
 pretty or unambiguous sight.<br>
</p>
<br><br><div class=3D"gmail_quote">On October 1, 2014 10:12:39 PM EEST, And=
y Prowl &lt;andy.prowl@gmail.com&gt; wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, =
204); padding-left: 1ex;">
<div dir=3D"ltr">Err, pardon:<br /><br /><div class=3D"prettyprint" style=
=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; background=
-color: rgb(250, 250, 250);"><code class=3D"prettyprint"></code><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">static_assert</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(!</span><span style=3D"color: #000;" class=3D"styled-by-prettify">st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">is_same</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">first</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">),</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">decltype</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">second</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)&gt;(),</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #080;" class=3D"styled-by-prettify">"Error"</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">);</span></div></div><br /><div>And=
y</div></div>

<p></p>
</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 />

------G0Z1AUNEUDP5MOOY9994PB103M1OD5--


.

------=_Part_6107_730155077.1412192894664
Content-Type: text/plain; charset=UTF-8

George,

I'm not sure what your point is. Why doesn't the static_assert() solve
Ville's puzzle? Why is it necessary to refer to parameter type identifiers
explicitly? Also, what do you mean by "identifiers declared with 'auto'
refers to values"?

Kind regards,

Andrea
>
>

--

---
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_6107_730155077.1412192894664
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">George, <br><br>I'm not sure what your point is. Why doesn=
't the static_assert() solve Ville's puzzle? Why is it necessary to refer t=
o parameter type identifiers explicitly? Also, what do you mean by "identif=
iers declared with 'auto' refers to values"?<br><br>Kind regards,<br><br>An=
drea<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">

<p></p>
</blockquote></div></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 />

------=_Part_6107_730155077.1412192894664--

.

------=_Part_5611_2131274091.1412194024063
Content-Type: text/plain; charset=UTF-8

I think Ville's point is that in keeping with:

auto a = 3, b = 4.5;  // error or b is an int...

auto in both positions must "evaluate" to the same type. I think this
definition was a mistake in a variable declaration and also in this case.
In the variable declaration case we're stuck where we are but in this new
pair<auto, auto> case  I don't see why we would have to force both
instances of the word 'auto' to evaluate to the same type. The simple and
understandable rule would be "each time you type the word auto it means
some type". Thus in a multi-variable declaration their base type must be
the same, while in this case (with two type ins of auto) they can be
different.

Looking back at the initial example I need reassuring:

I was assuming the intention was that foo() returns a U* which is to be
captured in a unique_ptr<U>. If so, can the fictitous function really
deduce U from that declaration if u is a U*? If the intention is that foo()
already returns a unique_ptr<U> in the first place I don't see the
advantage over
just writing:

auto p = foo();

in this case p is deduced to be a unique_ptr<U> anyway, doesn't it? In none
of the cases you can easily access the type U from p using decltype, if
that was the ultimate goal.



Den onsdagen den 1:e oktober 2014 kl. 21:48:14 UTC+2 skrev Andy Prowl:
>
> George,
>
> I'm not sure what your point is. Why doesn't the static_assert() solve
> Ville's puzzle? Why is it necessary to refer to parameter type identifiers
> explicitly? Also, what do you mean by "identifiers declared with 'auto'
> refers to values"?
>
> Kind regards,
>
> Andrea
>>
>>

--

---
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_5611_2131274091.1412194024063
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think Ville's point is that in keeping with:<div><br></d=
iv><div>auto a =3D 3, b =3D 4.5; &nbsp;// error or b is an int...</div><div=
><br></div><div>auto in both positions must "evaluate" to the same type. I =
think this definition was a mistake in a variable declaration and also in t=
his case. In the variable declaration case we're stuck where we are but in =
this new</div><div>pair&lt;auto, auto&gt; case &nbsp;I don't see why we wou=
ld have to force both instances of the word 'auto' to evaluate to the same =
type. The simple and understandable rule would be "each time you type the w=
ord auto it means</div><div>some type". Thus in a multi-variable declaratio=
n their base type must be the same, while in this case (with two type ins o=
f auto) they can be different.</div><div><br></div><div>Looking back at the=
 initial example I need reassuring:</div><div><br></div><div>I was assuming=
 the intention was that foo() returns a U* which is to be captured in a uni=
que_ptr&lt;U&gt;. If so, can the fictitous function really deduce U from th=
at declaration if u is a U*? If the intention is that foo() already returns=
 a unique_ptr&lt;U&gt; in the first place I don't see the advantage over</d=
iv><div>just writing:</div><div><br></div><div>auto p =3D foo();</div><div>=
<br></div><div>in this case p is deduced to be a unique_ptr&lt;U&gt; anyway=
, doesn't it? In none of the cases you can easily access the type U from p =
using decltype, if that was the ultimate goal.</div><div><br></div><div><br=
><br>Den onsdagen den 1:e oktober 2014 kl. 21:48:14 UTC+2 skrev Andy Prowl:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">George, <br><=
br>I'm not sure what your point is. Why doesn't the static_assert() solve V=
ille's puzzle? Why is it necessary to refer to parameter type identifiers e=
xplicitly? Also, what do you mean by "identifiers declared with 'auto' refe=
rs to values"?<br><br>Kind regards,<br><br>Andrea<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">

<p></p>
</blockquote></div></blockquote></div></blockquote></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_5611_2131274091.1412194024063--

.

------=_Part_21_1112302476.1412194699032
Content-Type: text/plain; charset=UTF-8

Hi Bengt,

I think you misunderstood Ville's point. His puzzle was: is there a way to
specify that the two "auto"s in "pair<auto, auto>" *must* resolve to
*different* types? My answer to that was the static_assert().

Concerning foo(), it cannot return a raw pointer: the constructor of
unique_ptr<T> taking a T* is explicit, wouldn't work for
copy-initialization. The intention indeed was to have foo() return a
unique_ptr<T>. Whether or not it makes sense to write "unique_ptr<auto> p =
foo()" instead of "auto p = foo()" is perhaps a matter of style or
guidelines, and it depends on how much you want to commit to a type or how
much is it OK for you to deduce anything at tall.

Other, more meaningful examples than the one with unique_ptr may exist
(consider also with generic lambdas or terse function template syntax a la
Concepts Lite). But at a language level, since the parallel between auto
and template type deduction was drawn, I do not see it should only go half
way.

Kind regards,

Andy
>
>

--

---
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_21_1112302476.1412194699032
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Bengt,<br><br>I think you misunderstood Ville's point. =
His puzzle was: is there a way to specify that the two "auto"s in "pair&lt;=
auto, auto&gt;" *must* resolve to *different* types? My answer to that was =
the static_assert().<br><br>Concerning foo(), it cannot return a raw pointe=
r: the constructor of unique_ptr&lt;T&gt; taking a T* is explicit, wouldn't=
 work for copy-initialization. The intention indeed was to have foo() retur=
n a unique_ptr&lt;T&gt;. Whether or not it makes sense to write "unique_ptr=
&lt;auto&gt; p =3D foo()" instead of "auto p =3D foo()" is perhaps a matter=
 of style or guidelines, and it depends on how much you want to commit to a=
 type or how much is it OK for you to deduce anything at tall. <br><br>Othe=
r, more meaningful examples than the one with unique_ptr may exist (conside=
r also with generic lambdas or terse function template syntax a la Concepts=
 Lite). But at a language level, since the parallel between auto and templa=
te type deduction was drawn, I do not see it should only go half way.<br><b=
r>Kind regards,<br><br>Andy<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">

<p></p>
</blockquote></div></blockquote></div></blockquote></div></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 />

------=_Part_21_1112302476.1412194699032--

.

This is a multi-part message in MIME format.
--------------070005080000060005090802
Content-Type: text/plain; charset=UTF-8; format=flowed


On 10/01/2014 10:48 PM, Andy Prowl wrote:
> George,
>
> I'm not sure what your point is. Why doesn't the static_assert() solve
> Ville's puzzle? Why is it necessary to refer to parameter type
> identifiers explicitly? Also, what do you mean by "identifiers
> declared with 'auto' refers to values"?

I never implied that your static_assert example would not work, I am
saying that it may lead to more elaborate syntax for being able to use
the proposed std::pair<auto,auto> (for example), while it could break
once more complex scenarios of use are at hand.

When we write:

auto x = 1;

We use auto to magically specify the type of identifier x (which is our
variable). In the standard, auto is a specifier, while the terms
simple-type-specifier and typename-specifier are used as well. Referring
to 14.6.3 for typename in N3690 (C++14 working draft) for use in templates.

Now, let's see how we solve Ville's problem, using a couple of examples
(std::enable_if_t is C++14):

*template*<*typename*  A,*typename*  B>
std::enable_if_t<!std::is_same<A,B>::value,void>
function(std::pair<A,B>)
{}

*template*<*typename*  T>
void  fun(std::pair<T,T>) {}

*template*<*typename*  A,*typename*  B>
void  fun (std::pair<A,B>)
{}


I think it is obvious that there is a notational advantage here because
the typename specifier is accompanied by identifiers (A,B,T) which allow
us to exploit the function template overloads and partial ordering to
solve this problem. Now, if I consider your solution, I end up having an
interesting problem:

void function(std::pair<auto,auto> x)
{}


It quickly becomes evident that since there is no template parameter
list and no identifiers used for the parameters involved after the auto
specifier, we cannot perform any sfinae until after x has been declared
in the argument list of 'function'. This means that you cannot use
sfinae easily on the return type for example. You will also have to
resort to auto function -> decltype(...) tricks, provided they are
applicable.

So it would be interesting to provide easier type inference through
'auto' within the argument list of 'function', but that cannot happen
smoothly, even if you add an identifier after the auto specifier.

void function(std::pair<auto  A,auto  B> x)
{}


This would also be wrong. If you wanted to sfinae (for example) you
would still be forced to use auto function -> decltype(...) or further
mess with the type signature, leading to increasing verbosity. Now,
sfinae aside, you also cannot use either of (A,B) as return types since
there has been no declaration of them prior to the argument list of
'function'. So you are really not helping out the cause towards shorter
and crystal clear syntax.

One of course can be inspired by C++14 generic lambdas as well as plain
'auto' or decltype(auto) and attempt this as a proposal:

*decltype*(auto) function(std::pair<auto  A,auto  B> x)
{*return*  x.first; }


Here, auto simply starts doing too many things through implication, to
the point of becoming another language within the compiler. And you
still can't use (A) as a return type in the seamless way you would do
with regular templates.

Overall, I think that this use of auto can be quite problematic within a
template parameter list that can have non-type parameters, type
parameters and template-type parameters.

Now, imagine variadics and concepts coming together with this 'auto'.
You seem to be using auto here as a shorthand for bypassing 'typename'
and the declaration of the template parameter list. That is why you are
facing these problems.

I therefore think that such an extension of 'auto' would need
considerable work to become non-blocking/breaking or at least superior
to the template notation we already have, besides "requiring different
types". So Ville's problem is just one of the issues you would have to
handle, but not the most complicated one of them.

Just a few thoughts,

Regards,

George




--

---
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/.

--------------070005080000060005090802
Content-Type: text/html; charset=UTF-8

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 10/01/2014 10:48 PM, Andy Prowl
      wrote:<br>
    </div>
    <blockquote
      cite="mid:6eb88220-865b-4060-828f-773c6f1cd6a7@isocpp.org"
      type="cite">
      <div dir="ltr">George, <br>
        <br>
        I'm not sure what your point is. Why doesn't the static_assert()
        solve Ville's puzzle? Why is it necessary to refer to parameter
        type identifiers explicitly? Also, what do you mean by
        "identifiers declared with 'auto' refers to values"?<br>
      </div>
    </blockquote>
    <br>
    I never implied that your static_assert example would not work, I am
    saying that it may lead to more elaborate syntax for being able to
    use the proposed std::pair&lt;auto,auto&gt; (for example), while it
    could break once more complex scenarios of use are at hand.<br>
    <br>
    When we write:<br>
    <br>
    auto x = 1;<br>
    <br>
    We use auto to magically specify the type of identifier x (which is
    our variable). In the standard, auto is a specifier, while the terms
    simple-type-specifier and typename-specifier are used as well.
    Referring to 14.6.3 for typename in N3690 (C++14 working draft) for
    use in templates.<br>
    <br>
    Now, let's see how we solve Ville's problem, using a couple of
    examples (std::enable_if_t is C++14):<br>
    <br>
    <pre style="color:#1f1c1b;background-color:#ffffff;"><b>template</b>&lt;<b>typename</b> A, <b>typename</b> B&gt;
std::enable_if_t&lt;!std::is_same&lt;A,B&gt;::value, <span style="color:#0057ae;">void</span>&gt;
function(std::pair&lt;A,B&gt;)
{}

<b>template</b>&lt;<b>typename</b> T&gt;
<span style="color:#0057ae;">void</span> fun(std::pair&lt;T,T&gt;) {}

<b>template</b>&lt;<b>typename</b> A, <b>typename</b> B&gt;
<span style="color:#0057ae;">void</span> fun (std::pair&lt;A,B&gt;)
{}
</pre>
    <br>
    I think it is obvious that there is a notational advantage here
    because the typename specifier is accompanied by identifiers (A,B,T)
    which allow us to exploit the function template overloads and
    partial ordering to solve this problem. Now, if I consider your
    solution, I end up having an interesting problem:<br>
    <br>
    <pre style="color:#1f1c1b;background-color:#ffffff;">void function(std::pair&lt;<span style="color:#0057ae;">auto</span>,<span style="color:#0057ae;">auto</span>&gt; x)
{}
</pre>
    <br>
    It quickly becomes evident that since there is no template parameter
    list and no identifiers used for the parameters involved after the
    auto specifier, we cannot perform any sfinae until after x has been
    declared in the argument list of 'function'. This means that you
    cannot use sfinae easily on the return type for example. You will
    also have to resort to auto function -&gt; decltype(...) tricks,
    provided they are applicable.<br>
    <br>
    So it would be interesting to provide easier type inference through
    'auto' within the argument list of 'function', but that cannot
    happen smoothly, even if you add an identifier after the auto
    specifier.<br>
    <br>
    <pre style="color:#1f1c1b;background-color:#ffffff;">void function(std::pair&lt;<span style="color:#0057ae;">auto</span> A,<span style="color:#0057ae;">auto</span> B&gt; x)
{}</pre>
    <br>
    This would also be wrong. If you wanted to sfinae (for example) you
    would still be forced to use auto function -&gt; decltype(...) or
    further mess with the type signature, leading to increasing
    verbosity. Now, sfinae aside, you also cannot use either of (A,B) as
    return types since there has been no declaration of them prior to
    the argument list of 'function'. So you are really not helping out
    the cause towards shorter and crystal clear syntax.<br>
    <br>
    One of course can be inspired by C++14 generic lambdas as well as
    plain 'auto' or decltype(auto) and attempt this as a proposal:<br>
    <br>
    <pre style="color:#1f1c1b;background-color:#ffffff;"><b>decltype</b>(<span style="color:#0057ae;">auto</span>) function(std::pair&lt;<span style="color:#0057ae;">auto</span> A,<span style="color:#0057ae;">auto</span> B&gt; x)
{ <b>return</b> x.first; }</pre>
    <br>
    Here, auto simply starts doing too many things through implication,
    to the point of becoming another language within the compiler. And
    you still can't use (A) as a return type in the seamless way you
    would do with regular templates.<br>
    <br>
    Overall, I think that this use of auto can be quite problematic
    within a template parameter list that can have non-type parameters,
    type parameters and template-type parameters.<br>
    <br>
    Now, imagine variadics and concepts coming together with this
    'auto'. You seem to be using auto here as a shorthand for bypassing
    'typename' and the declaration of the template parameter list. That
    is why you are facing these problems.<br>
    <br>
    I therefore think that such an extension of 'auto' would need
    considerable work to become non-blocking/breaking or at least
    superior to the template notation we already have, besides
    "requiring different types". So Ville's problem is just one of the
    issues you would have to handle, but not the most complicated one of
    them.<br>
    <br>
    Just a few thoughts,<br>
    <br>
    Regards,<br>
    <br>
    George<br>
    <br>
    <br>
    <br>
    <br>
  </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 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 />

--------------070005080000060005090802--

.

------=_Part_5892_2032268406.1412199490513
Content-Type: text/plain; charset=UTF-8

OK, but don't we have the same problem today with generic lambdas? How do
we specify that "a" and "b" in the following lambda should have different
types, or the same types, or related types etc.?

auto l = [] (auto a, auto b) { };

Unless I'm missing something, the notational problem you are mentioning is
present already today, and whether it is necessary to address it or not,
it's an orthogonal issue to the one of generalizing the parallel between
auto and template type deduction.

Am I missing something?

Kind regards,

Andrea

--

---
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_5892_2032268406.1412199490513
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">OK, but don't we have the same problem today with generic =
lambdas? How do we specify that "a" and "b" in the following lambda should =
have different types, or the same types, or related types etc.?<br><br><div=
 class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-=
wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"pre=
ttyprint"><div class=3D"subprettyprint"><font color=3D"#660066"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> l </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">[]</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></font></div=
></code></div><br>Unless I'm missing something, the notational problem you =
are mentioning is present already today, and whether it is necessary to add=
ress it or not, it's an orthogonal issue to the one of generalizing the par=
allel between auto and template type deduction.<br><br>Am I missing somethi=
ng?<br><br>Kind regards,<br><br>Andrea</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_5892_2032268406.1412199490513--

.

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

In fact, I did mention in my previous email that you can be inspired by gen=
eric C++14 lambdas for this; but such constructs by far, are not covering t=
he issues arising when all kinds of parameters are involved,  aka non-type,=
 type, template-type as well as partial ordering matching. Not to mention t=
he combination with variadics.

In essence, such proposed of auto for completely substituting the concept o=
f a template parameter list, is problematic for doing any sort of bounded p=
olymorphism (one of these cases is Ville's problem), while for that purpose=
 concepts could be combined to offer a better solution.

But then again, concepts are tied to template parameter and argument lists.=
 Which means that in this context, that way of handling parametric polymorp=
hism in c++ with =E2=80=99auto=E2=80=99 everywhere needs to be magically sh=
oehorned into concepts (somehow) so that you can avoid seeing 'template'.

Of course, you could make a proposal for turning 'auto'-ness into something=
 that works like Hindley=E2=80=93Milner type inference for C++, getting rid=
 of every kind of type "cue",  but that is neither the direction c++ is goi=
ng towards right now nor would it be a small change otherwise.

For the record, the incompleteness of 'auto' in C++11 led to problems with =
expression templates. Automatic type inference within the rules that we hav=
e can be very, very tricky to expand without breaking code using such rules=
..

Again, just some thoughts; in conclusion, such use of 'auto' can be problem=
atic unless it is very constrained by context to serve a shorthand for type=
 parameters over cases where bounded polymorphism is not actually required.=
 Generic C++14 lambdas were such a case, but they do not have the complexit=
ies of template parameter and argument lists.

Regards,=20

George

On October 2, 2014 12:38:10 AM EEST, Andy Prowl <andy.prowl@gmail.com> wrot=
e:
>OK, but don't we have the same problem today with generic lambdas? How
>do=20
>we specify that "a" and "b" in the following lambda should have
>different=20
>types, or the same types, or related types etc.?
>
>auto l =3D [] (auto a, auto b) { };
>
>Unless I'm missing something, the notational problem you are mentioning
>is=20
>present already today, and whether it is necessary to address it or
>not,=20
>it's an orthogonal issue to the one of generalizing the parallel
>between=20
>auto and template type deduction.
>
>Am I missing something?
>
>Kind regards,
>
>Andrea
>
>--=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/.

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

<html><head></head><body><p dir=3D"ltr">In fact, I did mention in my previo=
us email that you can be inspired by generic C++14 lambdas for this; but su=
ch constructs by far, are not covering the issues arising when all kinds of=
 parameters are involved,&nbsp; aka non-type, type, template-type as well a=
s partial ordering matching. Not to mention the combination with variadics.=
</p>
<p dir=3D"ltr">In essence, such proposed of auto for completely substitutin=
g the concept of a template parameter list, is problematic for doing any so=
rt of <b>bounded polymorphism</b> (one of these cases is Ville's problem), =
while for that purpose concepts could be combined to offer a better solutio=
n.</p>
<p dir=3D"ltr">But then again, concepts are tied to template parameter and =
argument lists. Which means that in this context, that way of handling para=
metric polymorphism in c++ with &#8217;auto&#8217; everywhere needs to be m=
agically shoehorned into concepts (somehow) so that you can avoid seeing 't=
emplate'.</p>
<p dir=3D"ltr">Of course, you could make a proposal for turning 'auto'-ness=
 into something that works like Hindley&#8211;Milner type inference for C++=
, getting rid of every kind of type "cue",&nbsp; but that is neither the di=
rection c++ is going towards right now nor would it be a small change other=
wise.</p>
<p dir=3D"ltr">For the record, the incompleteness of 'auto' in C++11 led to=
 problems with expression templates. Automatic type inference within the ru=
les that we have can be very, very tricky to expand without breaking code u=
sing such rules.</p>
<p dir=3D"ltr">Again, just some thoughts; in conclusion, such use of 'auto'=
 can be problematic unless it is very constrained by context to serve a sho=
rthand for type parameters over cases where bounded polymorphism is not act=
ually required. Generic C++14 lambdas were such a case, but they do not hav=
e the complexities of template parameter and argument lists.</p>
<p dir=3D"ltr">Regards, </p>
<p dir=3D"ltr">George</p>
<br><br><div class=3D"gmail_quote">On October 2, 2014 12:38:10 AM EEST, And=
y Prowl &lt;andy.prowl@gmail.com&gt; wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, =
204); padding-left: 1ex;">
<div dir=3D"ltr">OK, but don't we have the same problem today with generic =
lambdas? How do we specify that "a" and "b" in the following lambda should =
have different types, or the same types, or related types etc.?<br /><br />=
<div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); w=
ord-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D=
"prettyprint"></code><div class=3D"subprettyprint"><font color=3D"#660066">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> l </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">[]</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify">
a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br /></sp=
an></font></div></div><br />Unless I'm missing something, the notational pr=
oblem you are mentioning is present already today, and whether it is necess=
ary to address it or not, it's an orthogonal issue to the one of generalizi=
ng the parallel between auto and template type deduction.<br /><br />Am I m=
issing something?<br /><br />Kind regards,<br /><br
/>Andrea</div>

<p></p>
</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 />

------L783OY9N72BM6Q8AU2UXI7LZWH92IU--


.

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

W dniu =C5=9Broda, 1 pa=C5=BAdziernika 2014 20:46:28 UTC+2 u=C5=BCytkownik =
Ville=20
Voutilainen napisa=C5=82:
>
> On 1 October 2014 21:43, Andy Prowl <andy....@gmail.com <javascript:>>=20
> wrote:=20
> > Currently, the following declaration is not legal:=20
> >=20
> > std::unique_ptr<auto> p =3D foo();=20
> >=20
> > As far as I can tell, this is just one particular instance of the same=
=20
> > problem. The type of "p" above would be the same as the type of the=20
> > parameter "u" below when calling "f(foo())":=20
> >=20
> > template <class U> void f(std::unique_ptr<U> u);=20
> >=20
> > Do you think it makes sense to generalize the rule and allow=20
> initializations=20
> > like the one above?=20
>
>
> Yes, I think it would. Do remember, though, that if we allow, say=20
>
> pair<auto, auto> x =3D foo();=20
>
> it's somewhat likely that someone somewhere will ask "how do I express a=
=20
> pair=20
> where the types must not be the same?"=20
>

I think that the syntax proposed in N3878=20
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3878.pdf>=20
resovles the problem:
 pair<auto{T}, T> x =3D foo();=20

--=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_3693_171780563.1412230063770
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">W dniu =C5=9Broda, 1 pa=C5=BAdziernika 2014 20:46:28 UTC+2=
 u=C5=BCytkownik Ville Voutilainen napisa=C5=82:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">On 1 October 2014 21:43, Andy Prowl &lt;<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"IewE5lO_dg0J" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">andy....@gmail.com</a>&gt; wrote:
<br>&gt; Currently, the following declaration is not legal:
<br>&gt;
<br>&gt; std::unique_ptr&lt;auto&gt; p =3D foo();
<br>&gt;
<br>&gt; As far as I can tell, this is just one particular instance of the =
same
<br>&gt; problem. The type of "p" above would be the same as the type of th=
e
<br>&gt; parameter "u" below when calling "f(foo())":
<br>&gt;
<br>&gt; template &lt;class U&gt; void f(std::unique_ptr&lt;U&gt; u);
<br>&gt;
<br>&gt; Do you think it makes sense to generalize the rule and allow initi=
alizations
<br>&gt; like the one above?
<br>
<br>
<br>Yes, I think it would. Do remember, though, that if we allow, say
<br>
<br>pair&lt;auto, auto&gt; x =3D foo();
<br>
<br>it's somewhat likely that someone somewhere will ask "how do I express =
a pair
<br>where the types must not be the same?"
<br></blockquote><div><br>I think that the syntax proposed in&nbsp;<a href=
=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3878.pdf">N387=
8</a> resovles the problem:<br>&nbsp;pair&lt;auto{T}, T&gt; x =3D foo();
</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_3693_171780563.1412230063770--

.

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



W dniu czwartek, 2 pa=C5=BAdziernika 2014 08:07:43 UTC+2 u=C5=BCytkownik To=
masz=20
napisa=C5=82:
>
> W dniu =C5=9Broda, 1 pa=C5=BAdziernika 2014 20:46:28 UTC+2 u=C5=BCytkowni=
k Ville=20
> Voutilainen napisa=C5=82:
>>
>> On 1 October 2014 21:43, Andy Prowl <andy....@gmail.com> wrote:=20
>> > Currently, the following declaration is not legal:=20
>> >=20
>> > std::unique_ptr<auto> p =3D foo();=20
>> >=20
>> > As far as I can tell, this is just one particular instance of the same=
=20
>> > problem. The type of "p" above would be the same as the type of the=20
>> > parameter "u" below when calling "f(foo())":=20
>> >=20
>> > template <class U> void f(std::unique_ptr<U> u);=20
>> >=20
>> > Do you think it makes sense to generalize the rule and allow=20
>> initializations=20
>> > like the one above?=20
>>
>>
>> Yes, I think it would. Do remember, though, that if we allow, say=20
>>
>> pair<auto, auto> x =3D foo();=20
>>
>> it's somewhat likely that someone somewhere will ask "how do I express a=
=20
>> pair=20
>> where the types must not be the same?"=20
>>
>
> I think that the syntax proposed in N3878=20
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3878.pdf>=20
> resovles the problem:
>  pair<auto{T}, T> x =3D foo();=20
>

I assuming that the every instance of auto placeholder is treated as=20
separate type parameter for equivalent function template, so it will=20
consitient with the way we thread auto in parameters of generic lambda. And=
=20
to have same type we use placholder{T} syntax. This may also be extented to=
=20
Concepts, like pair<Iterator{I}, I> p =3D std::equal_range(...).

--=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_6418_1627996604.1412230404743
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu czwartek, 2 pa=C5=BAdziernika 2014 08:07:43=
 UTC+2 u=C5=BCytkownik Tomasz napisa=C5=82:<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">W dniu =C5=9Broda, 1 pa=C5=BAdziernika 2014 2=
0:46:28 UTC+2 u=C5=BCytkownik Ville Voutilainen napisa=C5=82:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">On 1 October 2014 21:43, Andy Prowl &lt;<a>andy..=
...@gmail.com</a>&gt; wrote:
<br>&gt; Currently, the following declaration is not legal:
<br>&gt;
<br>&gt; std::unique_ptr&lt;auto&gt; p =3D foo();
<br>&gt;
<br>&gt; As far as I can tell, this is just one particular instance of the =
same
<br>&gt; problem. The type of "p" above would be the same as the type of th=
e
<br>&gt; parameter "u" below when calling "f(foo())":
<br>&gt;
<br>&gt; template &lt;class U&gt; void f(std::unique_ptr&lt;U&gt; u);
<br>&gt;
<br>&gt; Do you think it makes sense to generalize the rule and allow initi=
alizations
<br>&gt; like the one above?
<br>
<br>
<br>Yes, I think it would. Do remember, though, that if we allow, say
<br>
<br>pair&lt;auto, auto&gt; x =3D foo();
<br>
<br>it's somewhat likely that someone somewhere will ask "how do I express =
a pair
<br>where the types must not be the same?"
<br></blockquote><div><br>I think that the syntax proposed in&nbsp;<a href=
=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3878.pdf" targ=
et=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75htt=
p%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn3=
878.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEFXeAYYbsB5jkiaszRb_QpmktSgw';re=
turn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2=
F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn3878.pd=
f\46sa\75D\46sntz\0751\46usg\75AFQjCNEFXeAYYbsB5jkiaszRb_QpmktSgw';return t=
rue;">N3878</a> resovles the problem:<br>&nbsp;pair&lt;auto{T}, T&gt; x =3D=
 foo();
</div></div></blockquote><div><br>I assuming that the every instance of aut=
o placeholder is treated as separate type parameter for equivalent function=
 template, so it will consitient with the way we thread auto in parameters =
of generic lambda. And to have same type we use placholder{T} syntax. This =
may also be extented to Concepts, like pair&lt;Iterator{I}, I&gt; p =3D std=
::equal_range(...).<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_6418_1627996604.1412230404743--

.

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

In your formulation, the type is in the end the same in both the first and =
the second type in std::pair, T, therefore it does not give you a guarantee=
 that these two are different unless you use additional syntax for constrai=
ning the second.

In your example there is no such constraint or implication of it; and even =
if placed there, it still does not have a real notational advantage over re=
gular templates. Not an easy path when you already have partial ordering an=
d overloads doing the job for you in this particular case. What if more tha=
n two are involved?

Also proves that additional syntax is required to disambiguate for uses of =
auto within parameter lists for being a typename substitute or even a templ=
ate-type parameter one.

Regards,

George

On October 2, 2014 9:07:43 AM EEST, Tomasz <tomaszkam@gmail.com> wrote:
>W dniu =C5=9Broda, 1 pa=C5=BAdziernika 2014 20:46:28 UTC+2 u=C5=BCytkownik=
 Ville=20
>Voutilainen napisa=C5=82:
>>
>> On 1 October 2014 21:43, Andy Prowl <andy....@gmail.com
><javascript:>>=20
>> wrote:=20
>> > Currently, the following declaration is not legal:=20
>> >=20
>> > std::unique_ptr<auto> p =3D foo();=20
>> >=20
>> > As far as I can tell, this is just one particular instance of the
>same=20
>> > problem. The type of "p" above would be the same as the type of the
>
>> > parameter "u" below when calling "f(foo())":=20
>> >=20
>> > template <class U> void f(std::unique_ptr<U> u);=20
>> >=20
>> > Do you think it makes sense to generalize the rule and allow=20
>> initializations=20
>> > like the one above?=20
>>
>>
>> Yes, I think it would. Do remember, though, that if we allow, say=20
>>
>> pair<auto, auto> x =3D foo();=20
>>
>> it's somewhat likely that someone somewhere will ask "how do I
>express a=20
>> pair=20
>> where the types must not be the same?"=20
>>
>
>I think that the syntax proposed in N3878=20
><http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3878.pdf>=20
>resovles the problem:
> pair<auto{T}, T> x =3D foo();=20
>
>--=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/.

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

<html><head></head><body><p dir=3D"ltr">In your formulation, the type is in=
 the end the same in both the first and the second type in std::pair, T, th=
erefore it does not give you a guarantee that these two are different unles=
s you use additional syntax for constraining the second.</p>
<p dir=3D"ltr">In your example there is no such constraint or implication o=
f it; and even if placed there, it still does not have a real notational ad=
vantage over regular templates. Not an easy path when you already have part=
ial ordering and overloads doing the job for you in this particular case. W=
hat if more than two are involved?</p>
<p dir=3D"ltr">Also proves that additional syntax is required to disambigua=
te for uses of auto within parameter lists for being a typename substitute =
or even a template-type parameter one.</p>
<p dir=3D"ltr">Regards,</p>
<p dir=3D"ltr">George</p>
<br><br><div class=3D"gmail_quote">On October 2, 2014 9:07:43 AM EEST, Toma=
sz &lt;tomaszkam@gmail.com&gt; wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); =
padding-left: 1ex;">
<div dir=3D"ltr">W dniu =C5=9Broda, 1 pa=C5=BAdziernika 2014 20:46:28 UTC+2=
 u=C5=BCytkownik Ville Voutilainen napisa=C5=82:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">On 1 October 2014 21:43, Andy Prowl &lt;<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"IewE5lO_dg0J" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">andy....@gmail.com</a>&gt; wrote:
<br />&gt; Currently, the following declaration is not legal:
<br />&gt;
<br />&gt; std::unique_ptr&lt;auto&gt; p =3D foo();
<br />&gt;
<br />&gt; As far as I can tell, this is just one particular instance of th=
e same
<br />&gt; problem. The type of "p" above would be the same as the type of =
the
<br />&gt; parameter "u" below when calling "f(foo())":
<br />&gt;
<br />&gt; template &lt;class U&gt; void f(std::unique_ptr&lt;U&gt; u);
<br />&gt;
<br />&gt; Do you think it makes sense to generalize the rule and allow ini=
tializations
<br />&gt; like the one above?
<br />
<br />
<br />Yes, I think it would. Do remember, though, that if we allow, say
<br />
<br />pair&lt;auto, auto&gt; x =3D foo();
<br />
<br />it's somewhat likely that someone somewhere will ask "how do I expres=
s a pair
<br />where the types must not be the same?"
<br /></blockquote><div><br />I think that the syntax proposed in&nbsp;<a h=
ref=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3878.pdf">N=
3878</a> resovles the problem:<br />&nbsp;pair&lt;auto{T}, T&gt; x =3D foo(=
);
</div></div>

<p></p>
</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 />

------NTBU7Y2V16P2FLF5ZKA06RSC6TC2GP--


.

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

Under this assumption, as stated in previous emails, you would still have n=
o way to explicitly specify (or sfinae) an instantiated class template type=
 related to T given that no T identifier exists yet. See auto -> decltype s=
yntax; decltype(auto) is also unconstrained as to T. So it is a very limiti=
ng shorthand respect to the canonical way of doing things.



On October 2, 2014 9:13:24 AM EEST, Tomasz <tomaszkam@gmail.com> wrote:
>
>
>W dniu czwartek, 2 pa=C5=BAdziernika 2014 08:07:43 UTC+2 u=C5=BCytkownik T=
omasz=20
>napisa=C5=82:
>>
>> W dniu =C5=9Broda, 1 pa=C5=BAdziernika 2014 20:46:28 UTC+2 u=C5=BCytkown=
ik Ville=20
>> Voutilainen napisa=C5=82:
>>>
>>> On 1 October 2014 21:43, Andy Prowl <andy....@gmail.com> wrote:=20
>>> > Currently, the following declaration is not legal:=20
>>> >=20
>>> > std::unique_ptr<auto> p =3D foo();=20
>>> >=20
>>> > As far as I can tell, this is just one particular instance of the
>same=20
>>> > problem. The type of "p" above would be the same as the type of
>the=20
>>> > parameter "u" below when calling "f(foo())":=20
>>> >=20
>>> > template <class U> void f(std::unique_ptr<U> u);=20
>>> >=20
>>> > Do you think it makes sense to generalize the rule and allow=20
>>> initializations=20
>>> > like the one above?=20
>>>
>>>
>>> Yes, I think it would. Do remember, though, that if we allow, say=20
>>>
>>> pair<auto, auto> x =3D foo();=20
>>>
>>> it's somewhat likely that someone somewhere will ask "how do I
>express a=20
>>> pair=20
>>> where the types must not be the same?"=20
>>>
>>
>> I think that the syntax proposed in N3878=20
>> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3878.pdf>=20
>> resovles the problem:
>>  pair<auto{T}, T> x =3D foo();=20
>>
>
>I assuming that the every instance of auto placeholder is treated as=20
>separate type parameter for equivalent function template, so it will=20
>consitient with the way we thread auto in parameters of generic lambda.
>And=20
>to have same type we use placholder{T} syntax. This may also be
>extented to=20
>Concepts, like pair<Iterator{I}, I> p =3D std::equal_range(...).
>
>--=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/.

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

<html><head></head><body><p dir=3D"ltr">Under this assumption, as stated in=
 previous emails, you would still have no way to explicitly specify (or sfi=
nae) an instantiated class template type related to T given that no T ident=
ifier exists yet. See auto -&gt; decltype syntax; decltype(auto) is also un=
constrained as to T. So it is a very limiting shorthand respect to the cano=
nical way of doing things.</p>
<br><br><div class=3D"gmail_quote">On October 2, 2014 9:13:24 AM EEST, Toma=
sz &lt;tomaszkam@gmail.com&gt; wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); =
padding-left: 1ex;">
<div dir=3D"ltr"><br /><br />W dniu czwartek, 2 pa=C5=BAdziernika 2014 08:0=
7:43 UTC+2 u=C5=BCytkownik Tomasz napisa=C5=82:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr">W dniu =C5=9Broda, 1 pa=C5=BAdziernika 20=
14 20:46:28 UTC+2 u=C5=BCytkownik Ville Voutilainen napisa=C5=82:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex">On 1 October 2014 21:43, Andy Prowl &lt;<a>an=
dy....@gmail.com</a>&gt; wrote:
<br />&gt; Currently, the following declaration is not legal:
<br />&gt;
<br />&gt; std::unique_ptr&lt;auto&gt; p =3D foo();
<br />&gt;
<br />&gt; As far as I can tell, this is just one particular instance of th=
e same
<br />&gt; problem. The type of "p" above would be the same as the type of =
the
<br />&gt; parameter "u" below when calling "f(foo())":
<br />&gt;
<br />&gt; template &lt;class U&gt; void f(std::unique_ptr&lt;U&gt; u);
<br />&gt;
<br />&gt; Do you think it makes sense to generalize the rule and allow ini=
tializations
<br />&gt; like the one above?
<br />
<br />
<br />Yes, I think it would. Do remember, though, that if we allow, say
<br />
<br />pair&lt;auto, auto&gt; x =3D foo();
<br />
<br />it's somewhat likely that someone somewhere will ask "how do I expres=
s a pair
<br />where the types must not be the same?"
<br /></blockquote><div><br />I think that the syntax proposed in&nbsp;<a h=
ref=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3878.pdf" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75=
http%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2=
Fn3878.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEFXeAYYbsB5jkiaszRb_QpmktSgw'=
;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3=
A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn3878=
..pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEFXeAYYbsB5jkiaszRb_QpmktSgw';retur=
n true;">N3878</a> resovles the problem:<br />&nbsp;pair&lt;auto{T}, T&gt; =
x =3D foo();
</div></div></blockquote><div><br />I assuming that the every instance of a=
uto placeholder is treated as separate type parameter for equivalent functi=
on template, so it will consitient with the way we thread auto in parameter=
s of generic lambda. And to have same type we use placholder{T} syntax. Thi=
s may also be extented to Concepts, like pair&lt;Iterator{I}, I&gt; p =3D s=
td::equal_range(...).<br /></div></div>

<p></p>
</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 />

------AQDOAMZKKZSP0RESYGUDRP7W8SM8Z4--


.

On 1 October 2014 22:11, Andy Prowl <andy.prowl@gmail.com> wrote:
> Actually, wouldn't it be enough to add a static_assert after the
> declaration?
>
> pair<auto, auto> x = foo();
> static_assert(decltype(x.first) != decltype(x.second), "Error");

Yes.

Also note that what you suggest is already in Concepts, it supports things
like
Pair<auto, auto> p = make_pair(0, 'a'); // Ok

What it doesn't yet support is using Concepts in variable declarations:
"Unlike auto, a constrained-type-specifier cannot be used in the type of
a variable declaration or the return type of a function.", but I'm sure that
extension will be considered in due course.

--

---
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/.

.

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

It is not just variable declarations though that suffer.

Of course, we already analyzed this solution, but do show how we can use std::pair<auto,auto> in an argument list for specifying the two types must be different:

void fun(std::pair<auto, auto>) {}

Without resorting to multiple sfinae hacks like Andy is proposing; newer constructs should not lead to more complex code over the canonical solution with templates and partial ordering.

Also, return type sfinae manipulation is impaired to having to use auto -> decltype(...) constructs. In essence, verbosity.

As you said, it will be done in due course I guess. Perhaps Andy should consider this case though.

On October 2, 2014 10:07:21 AM EEST, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>On 1 October 2014 22:11, Andy Prowl <andy.prowl@gmail.com> wrote:
>> Actually, wouldn't it be enough to add a static_assert after the
>> declaration?
>>
>> pair<auto, auto> x = foo();
>> static_assert(decltype(x.first) != decltype(x.second), "Error");
>
>Yes.
>
>Also note that what you suggest is already in Concepts, it supports
>things
>like
>Pair<auto, auto> p = make_pair(0, 'a'); // Ok
>
>What it doesn't yet support is using Concepts in variable declarations:
>"Unlike auto, a constrained-type-specifier cannot be used in the type
>of
>a variable declaration or the return type of a function.", but I'm sure
>that
>extension will be considered in due course.
>
>--
>
>---
>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/.

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

<html><head></head><body><p dir=3D"ltr">It is not just variable declaration=
s though that suffer.</p>
<p dir=3D"ltr">Of course, we already analyzed this solution, but do show ho=
w we can use std::pair&lt;auto,auto&gt; in an argument list for specifying =
the two types must be different:</p>
<p dir=3D"ltr">void fun(std::pair&lt;auto, auto&gt;) {}</p>
<p dir=3D"ltr">Without resorting to multiple sfinae hacks like Andy is prop=
osing; newer constructs should not lead to more complex code over the canon=
ical solution with templates and partial ordering.</p>
<p dir=3D"ltr">Also, return type sfinae manipulation is impaired to having =
to use auto -&gt; decltype(...) constructs. In essence, verbosity.</p>
<p dir=3D"ltr">As you said, it will be done in due course I guess. Perhaps =
Andy should consider this case though.</p>
<br><br><div class=3D"gmail_quote">On October 2, 2014 10:07:21 AM EEST, Vil=
le Voutilainen &lt;ville.voutilainen@gmail.com&gt; wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid=
 rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On 1 October 2014 22:11, Andy Prowl &lt;andy.prowl@gm=
ail.com&gt; wrote:<br /><blockquote class=3D"gmail_quote" style=3D"margin: =
0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Act=
ually, wouldn't it be enough to add a static_assert after the<br /> declara=
tion?<br /><br /> pair&lt;auto, auto&gt; x =3D foo();<br /> static_assert(d=
ecltype(x.first) !=3D decltype(x.second), "Error");<br /></blockquote><br /=
>Yes.<br /><br />Also note that what you suggest is already in Concepts, it=
 supports things<br />like<br />Pair&lt;auto, auto&gt; p =3D make_pair(0, '=
a'); // Ok<br /><br />What it doesn't yet support is using Concepts in vari=
able declarations:<br />"Unlike auto, a constrained-type-specifier cannot b=
e used in the type of<br />a variable declaration or the return type of a f=
unction.", but I'm sure that<br />extension will be considered in due cours=
e.<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 />

------P6CPENL8V1H0FVXOAB0NYDM0HU3BCA--


.

On 2 October 2014 10:30, George Makrydakis <irrequietus@gmail.com> wrote:
> It is not just variable declarations though that suffer.
>
> Of course, we already analyzed this solution, but do show how we can use
> std::pair<auto,auto> in an argument list for specifying the two types must
> be different:
>
> void fun(std::pair<auto, auto>) {}

I don't see the point. If you care about the types and want to constrain them
to be different, and a constrained template does that easier than auto, use
a constrained template.

--

---
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/.

.

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

In essence then, we are in agreement; you do not gain any notational advantage for when types are different with the proposed 'auto' syntax extension. I am saying that the canonical way already covers all corners. Nothing more.

On October 2, 2014 10:49:17 AM EEST, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>On 2 October 2014 10:30, George Makrydakis <irrequietus@gmail.com>
>wrote:
>> It is not just variable declarations though that suffer.
>>
>> Of course, we already analyzed this solution, but do show how we can
>use
>> std::pair<auto,auto> in an argument list for specifying the two types
>must
>> be different:
>>
>> void fun(std::pair<auto, auto>) {}
>
>I don't see the point. If you care about the types and want to
>constrain them
>to be different, and a constrained template does that easier than auto,
>use
>a constrained template.
>
>--
>
>---
>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/.

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

<html><head></head><body><p dir=3D"ltr">In essence then, we are in agreemen=
t; you do not gain any notational advantage for when types are different wi=
th the proposed 'auto' syntax extension. I am saying that the canonical way=
 already covers all corners. Nothing more.</p>
<br><br><div class=3D"gmail_quote">On October 2, 2014 10:49:17 AM EEST, Vil=
le Voutilainen &lt;ville.voutilainen@gmail.com&gt; wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid=
 rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On 2 October 2014 10:30, George Makrydakis &lt;irrequ=
ietus@gmail.com&gt; wrote:<br /><blockquote class=3D"gmail_quote" style=3D"=
margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1e=
x;"> It is not just variable declarations though that suffer.<br /><br /> O=
f course, we already analyzed this solution, but do show how we can use<br =
/> std::pair&lt;auto,auto&gt; in an argument list for specifying the two ty=
pes must<br /> be different:<br /><br /> void fun(std::pair&lt;auto, auto&g=
t;) {}<br /></blockquote><br />I don't see the point. If you care about the=
 types and want to constrain them<br />to be different, and a constrained t=
emplate does that easier than auto, use<br />a constrained template.<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 />

------JV2K38X00MT6CWWN371KMNEL74PYEM--


.

------=_Part_114_712324002.1412239438604
Content-Type: text/plain; charset=UTF-8

My proposal is that every use of placholder (today we have only auto, but
concept name would be a possible extension) would introduce separate
typename, so:
std::pair<auto, auto> p = f();

Would use equivalent deduction as:
template<typename T1, typename T2>
void foo(std::pair<T1, T2>);

And two different types can be deduced. To achieve the pair of the same
types I would use syntax proposed in
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3878.pdf
<http://n3878>, that allow us to introduce indentyfier for a type deduced
from placeholder. So if we want to have pair of same types we would write:
std::pair<auto{T}, T> p = f();
Which will use deduction as:
template<typename T>
void foo(std::pair<T,T>);

We will benefit from being able to refer to type T without use of
std::decay_t<decltype(p)>::first_type and have same treatment of multiple
placeholders in every context.

This syntaxt can be extended to use concept names as placeholders:
std::pair<Iterator, Iterator> f = ...;
Will allow pair of two interator with unrelated types that fullfills
iterator concept. To have pair of iterator with same type only, we could
write
std::pair<Iterator{I}, I> f = ...;

--

---
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_114_712324002.1412239438604
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">My proposal is that every use of placholder (today we have=
 only auto, but concept name would be a possible extension) would introduce=
 separate typename, so:<br>std::pair&lt;auto, auto&gt; p =3D f();<br><br>Wo=
uld use equivalent deduction as:<br>template&lt;typename T1, typename T2&gt=
;<br>void foo(std::pair&lt;T1, T2&gt;);<br><br>And two different types can =
be deduced. To achieve the pair of the same types I would use syntax propos=
ed in <a href=3D"http://n3878">http://www.open-std.org/JTC1/SC22/WG21/docs/=
papers/2014/n3878.pdf</a>, that allow us to introduce indentyfier for a typ=
e deduced from placeholder. So if we want to have pair of same types we wou=
ld write:<br>std::pair&lt;auto{T}, T&gt; p =3D f();<br>Which will use deduc=
tion as:<br>template&lt;typename T&gt;<br>void foo(std::pair&lt;T,T&gt;);<b=
r><br>We will benefit from being able to refer to type T without use of std=
::decay_t&lt;decltype(p)&gt;::first_type and have same treatment of multipl=
e placeholders in every context.<br><br>This syntaxt can be extended to use=
 concept names as placeholders:<br>std::pair&lt;Iterator, Iterator&gt; f =
=3D ...;<br>Will allow pair of two interator with unrelated types that full=
fills iterator concept. To have pair of iterator with same type only, we co=
uld write<br>std::pair&lt;Iterator{I}, I&gt; f =3D ...;<br><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 />

------=_Part_114_712324002.1412239438604--

.

On 2 October 2014 10:59, George Makrydakis <irrequietus@gmail.com> wrote:
> In essence then, we are in agreement; you do not gain any notational
> advantage for when types are different with the proposed 'auto' syntax
> extension. I am saying that the canonical way already covers all corners.
> Nothing more.


It's not about whether the types are different, it's about whether I
care that the
types are different. If I don't care, or the differences are between
whether something
is or is not a reference or a pointer, auto gives me notational convenience over
the "canonical way".

At any rate, what the original message asks for is already part of the
Concepts TS
proposal.

--

---
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/.

.

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

Never implied that it wasn't in. But any variation requiring bounded polymo=
rphism (one case is caring about different types) fails to do so without re=
sorting to SFINAE once that use of auto kicks in. And even then, trivial re=
turn type constraints become impossible without complex SFINAE since the id=
entifiers ate declared in the argument list.

It is interesting to note that Sutton said that should any kind of template=
 meta-programming be necessary for doing what concepts are doing, it would =
make concepts a failed experiment. I would not be so harsh, but in that use=
 of 'auto' you just end up using tricks like Andy.

In essence, you cannot avoid using a template parameter list through such a=
uto use unless all is unboundedly polymorphic, and concepts with auto are d=
efinitely not Hindley-Milner.=20

On October 2, 2014 12:15:53 PM EEST, Ville Voutilainen <ville.voutilainen@g=
mail.com> wrote:
>On 2 October 2014 10:59, George Makrydakis <irrequietus@gmail.com>
>wrote:
>> In essence then, we are in agreement; you do not gain any notational
>> advantage for when types are different with the proposed 'auto'
>syntax
>> extension. I am saying that the canonical way already covers all
>corners.
>> Nothing more.
>
>
>It's not about whether the types are different, it's about whether I
>care that the
>types are different. If I don't care, or the differences are between
>whether something
>is or is not a reference or a pointer, auto gives me notational
>convenience over
>the "canonical way".
>
>At any rate, what the original message asks for is already part of the
>Concepts TS
>proposal.
>
>--=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/.

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

<html><head></head><body><p dir=3D"ltr">Never implied that it wasn't in. Bu=
t any variation requiring bounded polymorphism (one case is caring about di=
fferent types) fails to do so without resorting to SFINAE once that use of =
auto kicks in. And even then, trivial return type constraints become imposs=
ible without complex SFINAE since the identifiers ate declared in the argum=
ent list.</p>
<p dir=3D"ltr">It is interesting to note that Sutton said that should any k=
ind of template meta-programming be necessary for doing what concepts are d=
oing, it would make concepts a failed experiment. I would not be so harsh, =
but in that use of 'auto' you just end up using tricks like Andy.</p>
<p dir=3D"ltr">In essence, you cannot avoid using a template parameter list=
 through such auto use unless all is unboundedly polymorphic, and concepts =
with auto are definitely not Hindley-Milner. </p>
<br><br><div class=3D"gmail_quote">On October 2, 2014 12:15:53 PM EEST, Vil=
le Voutilainen &lt;ville.voutilainen@gmail.com&gt; wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid=
 rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On 2 October 2014 10:59, George Makrydakis &lt;irrequ=
ietus@gmail.com&gt; wrote:<br /><blockquote class=3D"gmail_quote" style=3D"=
margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1e=
x;"> In essence then, we are in agreement; you do not gain any notational<b=
r /> advantage for when types are different with the proposed 'auto' syntax=
<br /> extension. I am saying that the canonical way already covers all cor=
ners.<br /> Nothing more.<br /></blockquote><br /><br />It's not about whet=
her the types are different, it's about whether I<br />care that the<br />t=
ypes are different. If I don't care, or the differences are between<br />wh=
ether something<br />is or is not a reference or a pointer, auto gives me n=
otational convenience over<br />the "canonical way".<br /><br />At any rate=
, what the original message asks for is already part of the<br />Concepts T=
S<br />proposal.<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 />

------KVMUMX8QF8XDSRHSURGJ5GYVZK1DR3--


.

On 2 October 2014 12:37, George Makrydakis <irrequietus@gmail.com> wrote:
> Never implied that it wasn't in. But any variation requiring bounded
> polymorphism (one case is caring about different types) fails to do so
> without resorting to SFINAE once that use of auto kicks in. And even then,

Well, that's not what the auto syntax is for, so you get what you ask for.
As I said, if you need a constrained template, write a constrained template,
instead of constraining auto (which you can still do if you insist).

> In essence, you cannot avoid using a template parameter list through such
> auto use unless all is unboundedly polymorphic, and concepts with auto are
> definitely not Hindley-Milner.

I don't think they are intended to be. Feel free to discuss that with
the concepts
designers. This presentation might be interesting:
https://www.youtube.com/watch?v=vtUQY2dw0mI&list=PL_AKIMJc4roXG7rOmqsb_wDG1btCzhS8F&index=2

I think we're veering off from the thread, as well.

--

---
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/.

.

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

I agree that this is not what concepts are designed for, I am only saying that people like Andy are demonstrating a trend in expanding the semantics of type inference that is problematic over already existing practice.

As for the concepts group, whose public work I am aware of, I do not believe that they would consider all outsider opinions on this matter, even if they are right. Anything not taking place in public is not worth it.

On October 2, 2014 12:42:39 PM EEST, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>On 2 October 2014 12:37, George Makrydakis <irrequietus@gmail.com>
>wrote:
>> Never implied that it wasn't in. But any variation requiring bounded
>> polymorphism (one case is caring about different types) fails to do
>so
>> without resorting to SFINAE once that use of auto kicks in. And even
>then,
>
>Well, that's not what the auto syntax is for, so you get what you ask
>for.
>As I said, if you need a constrained template, write a constrained
>template,
>instead of constraining auto (which you can still do if you insist).
>
>> In essence, you cannot avoid using a template parameter list through
>such
>> auto use unless all is unboundedly polymorphic, and concepts with
>auto are
>> definitely not Hindley-Milner.
>
>I don't think they are intended to be. Feel free to discuss that with
>the concepts
>designers. This presentation might be interesting:
>https://www.youtube.com/watch?v=vtUQY2dw0mI&list=PL_AKIMJc4roXG7rOmqsb_wDG1btCzhS8F&index=2
>
>I think we're veering off from the thread, as well.
>
>--
>
>---
>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/.

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

<html><head></head><body><p dir=3D"ltr">I agree that this is not what conce=
pts are designed for, I am only saying that people like Andy are demonstrat=
ing a trend in expanding the semantics of type inference that is problemati=
c over already existing practice.</p>
<p dir=3D"ltr">As for the concepts group, whose public work I am aware of, =
I do not believe that they would consider all outsider opinions on this mat=
ter, even if they are right. Anything not taking place in public is not wor=
th it.</p>
<br><br><div class=3D"gmail_quote">On October 2, 2014 12:42:39 PM EEST, Vil=
le Voutilainen &lt;ville.voutilainen@gmail.com&gt; wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid=
 rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On 2 October 2014 12:37, George Makrydakis &lt;irrequ=
ietus@gmail.com&gt; wrote:<br /><blockquote class=3D"gmail_quote" style=3D"=
margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1e=
x;"> Never implied that it wasn't in. But any variation requiring bounded<b=
r /> polymorphism (one case is caring about different types) fails to do so=
<br /> without resorting to SFINAE once that use of auto kicks in. And even=
 then,<br /></blockquote><br />Well, that's not what the auto syntax is for=
, so you get what you ask for.<br />As I said, if you need a constrained te=
mplate, write a constrained template,<br />instead of constraining auto (wh=
ich you can still do if you insist).<br /><br /><blockquote class=3D"gmail_=
quote" style=3D"margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; =
padding-left: 1ex;"> In essence, you cannot avoid using a template paramete=
r list through such<br /> auto use unless all is unboundedly polymorphic, a=
nd concepts with auto are<br />
definitely not Hindley-Milner.<br /></blockquote><br />I don't think they a=
re intended to be. Feel free to discuss that with<br />the concepts<br />de=
signers. This presentation might be interesting:<br /><a href=3D"https://ww=
w.youtube.com/watch?v=3DvtUQY2dw0mI&amp;list=3DPL_AKIMJc4roXG7rOmqsb_wDG1bt=
CzhS8F&amp;index=3D2">https://www.youtube.com/watch?v=3DvtUQY2dw0mI&amp;lis=
t=3DPL_AKIMJc4roXG7rOmqsb_wDG1btCzhS8F&amp;index=3D2</a><br /><br />I think=
 we're veering off from the thread, as well.<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 />

------Y2DS0QHO4DBBLQGMQN5VY7GS490I1Y--


.

------=_Part_179_688408666.1412244665107
Content-Type: text/plain; charset=UTF-8


>
> At any rate, what the original message asks for is already part of
> the Concepts TS proposal.
>

That would be good news, but are you sure this is the case? Looking at
N3929, it seems to me that "auto" is only supported as a simple type
specifier. So for example this would be supported:

void foo(auto x) { }

But not this (as far as I can see):

void foo(std::vector<auto> x);

Same thing for variable declarations. Now I hope you will prove me wrong,
so we can close this thread :)

Kind regards,

Andy

--

---
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_179_688408666.1412244665107
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">At any rate, =
what the original message asks for is already part of the&nbsp;Concepts TS
proposal.
<br></blockquote><div><br>That would be good news, but are you sure this is=
 the case? Looking at N3929, it seems to me that "auto" is only supported a=
s a simple type specifier. So for example this would be supported:<br><br><=
div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); wo=
rd-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"=
prettyprint"><div class=3D"subprettyprint"><font color=3D"#660066"><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></font></div></co=
de></div><br>But not this (as far as I can see):<br><br><div class=3D"prett=
yprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-wor=
d; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div =
class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span style=3D"=
color: #080;" class=3D"styled-by-prettify">&lt;auto&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">);</span></div></code></div><br>Same=
 thing for variable declarations. Now I hope you will prove me wrong, so we=
 can close this thread :)<br><br>Kind regards,</div><div><br></div><div>And=
y</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_179_688408666.1412244665107--

.

On 2 October 2014 13:11, Andy Prowl <andy.prowl@gmail.com> wrote:
>> At any rate, what the original message asks for is already part of the
>> Concepts TS proposal.
> That would be good news, but are you sure this is the case? Looking at

Based on a very new working draft that is not yet published, yes, I am sure.
I took the example I pasted from that draft.

> Same thing for variable declarations. Now I hope you will prove me wrong, so
> we can close this thread :)

I think we should close this thread. :)

--

---
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_6482_262326222.1412245068560
Content-Type: text/plain; charset=UTF-8

George,

I'm not sure about what trend "people like me" are demonstrating, but
honestly I have troubles understanding most of the concerns you are
expressing. In particular, it seems to me that they are pretty much
orthogonal to my proposal.

For example, already today there are situations where using trailing return
type syntax is necessary, depending on what we want to do. And even with
regular template syntax, you won't be able to avoid SFINAE for e.g.
expressing the fact that two template type arguments must be different.

Regarding your concerns on the original example of std::pair<auto, auto>,
my proposal doesn't really change anything: if you wanted to express the
constraint that the types must be different *today*, you would still have
to resort to static assertions and decltype, so I believe what I'm after
doesn't make the situation worse.

Kind regards,

Andrea

--

---
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_6482_262326222.1412245068560
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">George, <br><br>I'm not sure about what trend "people like=
 me" are demonstrating, but honestly I have troubles understanding most of =
the concerns you are expressing. In particular, it seems to me that they ar=
e pretty much orthogonal to my proposal.<br><br>For example, already today =
there are situations where using trailing return type syntax is necessary, =
depending on what we want to do. And even with regular template syntax, you=
 won't be able to avoid SFINAE for e.g. expressing the fact that two templa=
te type arguments must be different.<br><br>Regarding your concerns on the =
original example of std::pair&lt;auto, auto&gt;, my proposal doesn't really=
 change anything: if you wanted to express the constraint that the types mu=
st be different *today*, you would still have to resort to static assertion=
s and decltype, so I believe what I'm after doesn't make the situation wors=
e.&nbsp;<br><br>Kind regards,<br><br>Andrea</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_6482_262326222.1412245068560--

.

------=_Part_196_1251814160.1412245137637
Content-Type: text/plain; charset=UTF-8

On Thursday, October 2, 2014 12:13:41 PM UTC+2, Ville Voutilainen wrote:
>
> On 2 October 2014 13:11, Andy Prowl <andy....@gmail.com <javascript:>>
> wrote:
> >> At any rate, what the original message asks for is already part of the
> >> Concepts TS proposal.
> > That would be good news, but are you sure this is the case? Looking at
>
> Based on a very new working draft that is not yet published, yes, I am
> sure.
> I took the example I pasted from that draft.
>

Awesome, thanks for sharing that.


> > Same thing for variable declarations. Now I hope you will prove me
> wrong, so
> > we can close this thread :)
>
> I think we should close this thread. :)
>

Agreed.

Kind regards,

Andy

--

---
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_196_1251814160.1412245137637
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, October 2, 2014 12:13:41 PM UTC+2, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2 October 201=
4 13:11, Andy Prowl &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"FkZf3Wv7620J" onmousedown=3D"this.href=3D'javascript:';retu=
rn true;" onclick=3D"this.href=3D'javascript:';return true;">andy....@gmail=
..com</a>&gt; wrote:
<br>&gt;&gt; At any rate, what the original message asks for is already par=
t of the
<br>&gt;&gt; Concepts TS proposal.
<br>&gt; That would be good news, but are you sure this is the case? Lookin=
g at
<br>
<br>Based on a very new working draft that is not yet published, yes, I am =
sure.
<br>I took the example I pasted from that draft.
<br></blockquote><div><br>Awesome, thanks for sharing that.<br>&nbsp;</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">&gt; Same thing for variable d=
eclarations. Now I hope you will prove me wrong, so
<br>&gt; we can close this thread :)
<br>
<br>I think we should close this thread. :)
<br></blockquote><div><br>Agreed.&nbsp;<br><br>Kind regards,<br><br>Andy</d=
iv></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_196_1251814160.1412245137637--

.

This is a multi-part message in MIME format.
--------------030907010904070209020204
Content-Type: text/plain; charset=UTF-8; format=flowed

I consider the thread _closed_, but given that Andy tries to make a
point, I will just show the flaws in that reasoning for posterity.

On 10/02/2014 01:17 PM, Andy Prowl wrote:
> George,
>
> I'm not sure about what trend "people like me" are demonstrating, but
> honestly I have troubles understanding most of the concerns you are
> expressing. In particular, it seems to me that they are pretty much
> orthogonal to my proposal.

Andy,

The double quoted extract in context is implicitly refering to people
who enjoy automatic type inference and is not intended as a discrediting
subterfuge, which is quite usual by some members of this list. I
consider myself part of the people who enjoy automatic type inference,
to some limited extent.

>
> For example, already today there are situations where using trailing
> return type syntax is necessary, depending on what we want to do. And
> even with regular template syntax, you won't be able to avoid SFINAE
> for e.g. expressing the fact that two template type arguments must be
> different.

/*Incorrect.*/ The following snippet, works even with C++98/03 and I am
pretty much avoiding everything fancy, I just follow simple rules the
language has since time immemorial with regular function template
overload syntax and ordering tricks:

#include<cstdio>
#include<utility>

*template*<*typename*  A,*typename*  B>
void  function(std::pair<A,B>) { printf("different\n"); }

*template*<*typename*  A>
void  function(std::pair<A,A>) { printf("same\n"); }

int  main() {
     function(std::pair<int,long>());
     function(std::pair<int,int>());
     *return*  0;
}


So, I can express the notion of two different types substituting two
different type parameter identifiers in the argument list because the
declarative template parameter list /is disjoint from it/. Now if I want
to write less using C++14 and limit to just one function (you seem to
have missed the previous email on this, so I have to repeat it) then
yes, I do have to use SFINAE through a <type_traits> library feature:

*template*<*typename*  A,*typename*  B>
std::enable_if_t<!std::is_same<A,B>::value,void>
function(std::pair<A,B>) { printf("different\n"); }


Of course, you are aware that std::enable_if and std::enable_if_t are
nothing but embelishments of techniques that are valid in C++98/03 and
have simply been granted library implementation status in C++11. The
introduction of template aliases is extremely important in shortening
the code we require for such constructs, but I digress. Let's try this
with C++11's static_assert and avoid such SFINAE use:

*template*<*typename*  A,*typename*  B>
void  function(std::pair<A,B>) {
     *static_assert*(!std::is_same<A,B>::value,"they cannot be the same!");
     printf("different\n");
}


That is more like you do in the std::pair<auto,auto> static warning. You
of course cannot do "trailing type sfinae" with std::pair<auto,auto>,
you still need to use auto -> decltype(...) and the amount of trickery
you'd have to put into that second decltype() in order to do anything
meaningful is what is leading to increased boilerplate. You do not deny
that of course, as per your examples. Take note that in your examples,
you did not use N3878 (still a work in progress by the C++ sages I
presume), neither did Tomasz who mentioned the paper, but let's take a
go at it with 'auto{X}' there (page 4 of 6, inspired by 2.3):

void  function(std::pair<auto{A},auto{B}>) {
     *static_assert*(!std::is_same<A,B>::value,"they cannot be the same!");
     printf("different\n");
}


This validates what I said in a previous email on this thread, that
without additional identifiers, std::pair<auto,auto> is rather pointless
for bounded polymorphism. In order to disambiguate with the use of auto
elsewhere, the authors are forced to use curly braces as additional syntax.

Essentially, that is what all of you are trying to say if we take N3878
in consideration. Not a problem, but... still no trailing sfinae and no
easy way to do some real work within that argument list without
complicating it to "template-header" level. Worse, it can mess the type
signature. The merit of a separate template parameter and argument list
is that we have a separation of concerns between what is our
/declarative //intent/ and what we would like to do based on/varying
input of parameter ty/pes.

I am still saying that such tendency to promote auto's use is not going
to override the actual merit of having a declarating template parameter
list (some people call this template header, I won't). It also does not
cover / address issues with non-type and template-type parameters
coherently /yet/. It is an unsolved problem until the C++ committee
sages think of a way they can do it themselves, despite a solution
_/can/_ already be provided. Pretty much like why it took decades to get
to 'concepts' in the form of predicates. All in due course as Ville
says. Only that it is not the 80s anymore.

>
> Regarding your concerns on the original example of std::pair<auto,
> auto>, my proposal doesn't really change anything: if you wanted to
> express the constraint that the types must be different *today*, you
> would still have to resort to static assertions and decltype, so I
> believe what I'm after doesn't make the situation worse.

I know that your proposal does not change anything - because per Ville's
reference /it does not add anything/. Also the examples I have laid out
show quite eloquently that _/*you could express that types must be
different yesterday*/_. Ville rhetorically asked, in the context of your
OP of how he would express the notion of two different types in that
construct. Despite some people may take this personally, it is
technically obvious that with 'auto' used that way we only have a
pointless shorthand favoring latent typing (again...); canonical
template notation is still superior in covering all cases, even when no
SFINAE tricks are involved.

That /does not mean we should not aim for better/ over the /'hated'
/template keyword, but we should not also hail something as an
_/*important*/_ improvement when it is evidently clear that it is not.
Not your case, but I think most of the arguments in the list are kind of
staged and rehearsed for supporting X over Y over non-really-technical
reasons, demanding passive compliance.

Yes, we can now close this thread.

Regards,

George

--

---
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/.

--------------030907010904070209020204
Content-Type: text/html; charset=UTF-8

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I consider the thread <u>closed</u>, but given that Andy tries to
    make a point, I will just show the flaws in that reasoning for
    posterity.<br>
    <br>
    <div class="moz-cite-prefix">On 10/02/2014 01:17 PM, Andy Prowl
      wrote:<br>
    </div>
    <blockquote
      cite="mid:af1beec6-baea-4ea9-bb5f-97e86cf1e680@isocpp.org"
      type="cite">
      <div dir="ltr">George, <br>
        <br>
        I'm not sure about what trend "people like me" are
        demonstrating, but honestly I have troubles understanding most
        of the concerns you are expressing. In particular, it seems to
        me that they are pretty much orthogonal to my proposal.<br>
      </div>
    </blockquote>
    <br>
    Andy,<br>
    <br>
    The double quoted extract in context is implicitly refering to
    people who enjoy automatic type inference and is not intended as a
    discrediting subterfuge, which is quite usual by some members of
    this list. I consider myself part of the people who enjoy automatic
    type inference, to some limited extent.<br>
    <br>
    <blockquote
      cite="mid:af1beec6-baea-4ea9-bb5f-97e86cf1e680@isocpp.org"
      type="cite">
      <div dir="ltr"><br>
        For example, already today there are situations where using
        trailing return type syntax is necessary, depending on what we
        want to do. And even with regular template syntax, you won't be
        able to avoid SFINAE for e.g. expressing the fact that two
        template type arguments must be different.<br>
      </div>
    </blockquote>
    <br>
    <i><b>Incorrect.</b></i> The following snippet, works even with
    C++98/03 and I am pretty much avoiding everything fancy, I just
    follow simple rules the language has since time immemorial with
    regular function template overload syntax and ordering tricks:<br>
    <pre style="color:#1f1c1b;background-color:#ffffff;"><span style="color:#004d84;">#include </span><span style="color:#006e28;">&lt;cstdio&gt;</span>
<span style="color:#004d84;">#include </span><span style="color:#006e28;">&lt;utility&gt;</span>

<b>template</b>&lt;<b>typename</b> A, <b>typename</b> B&gt;
<span style="color:#0057ae;">void</span> function(std::pair&lt;A,B&gt;) { printf(<span style="color:#bf0303;">"different</span><span style="color:#924c9d;">\n</span><span style="color:#bf0303;">"</span>); }

<b>template</b>&lt;<b>typename</b> A&gt;
<span style="color:#0057ae;">void</span> function(std::pair&lt;A,A&gt;) { printf(<span style="color:#bf0303;">"same</span><span style="color:#924c9d;">\n</span><span style="color:#bf0303;">"</span>); }

<span style="color:#0057ae;">int</span> main() {
    function(std::pair&lt;<span style="color:#0057ae;">int</span>,<span style="color:#0057ae;">long</span>&gt;());
    function(std::pair&lt;<span style="color:#0057ae;">int</span>,<span style="color:#0057ae;">int</span>&gt;());
    <b>return</b> <span style="color:#b08000;">0</span>;
}</pre>
    <br>
    So, I can express the notion of two different types substituting two
    different type parameter identifiers in the argument list because
    the declarative template parameter list <i>is disjoint from it</i>.
    Now if I want to write less using C++14 and limit to just one
    function (you seem to have missed the previous email on this, so I
    have to repeat it) then yes, I do have to use SFINAE through a
    &lt;type_traits&gt; library feature:<br>
    <br>
    <pre style="color:#1f1c1b;background-color:#ffffff;"><b>template</b>&lt;<b>typename</b> A, <b>typename</b> B&gt;
std::enable_if_t&lt;!std::is_same&lt;A,B&gt;::value,<span style="color:#0057ae;">void</span>&gt;
function(std::pair&lt;A,B&gt;) { printf(<span style="color:#bf0303;">"different</span><span style="color:#924c9d;">\n</span><span style="color:#bf0303;">"</span>); }</pre>
    <br>
    Of course, you are aware that std::enable_if and std::enable_if_t
    are nothing but embelishments of techniques that are valid in
    C++98/03 and have simply been granted library implementation status
    in C++11. The introduction of template aliases is extremely
    important in shortening the code we require for such constructs, but
    I digress. Let's try this with C++11's static_assert and avoid such
    SFINAE use:<br>
    <br>
    <pre style="color:#1f1c1b;background-color:#ffffff;"><b>template</b>&lt;<b>typename</b> A, <b>typename</b> B&gt;
<span style="color:#0057ae;">void</span> function(std::pair&lt;A,B&gt;) {
    <b>static_assert</b>(!std::is_same&lt;A,B&gt;::value, <span style="color:#bf0303;">"they cannot be the same!"</span>);
    printf(<span style="color:#bf0303;">"different</span><span style="color:#924c9d;">\n</span><span style="color:#bf0303;">"</span>);
}</pre>
    <br>
    That is more like you do in the std::pair&lt;auto,auto&gt; static
    warning. You of course cannot do "trailing type sfinae" with
    std::pair&lt;auto,auto&gt;, you still need to use auto -&gt;
    decltype(...) and the amount of trickery you'd have to put into that
    second decltype() in order to do anything meaningful is what is
    leading to increased boilerplate. You do not deny that of course, as
    per your examples. Take note that in your examples, you did not use
    N3878 (still a work in progress by the C++ sages I presume), neither
    did Tomasz who mentioned the paper, but let's take a go at it with
    'auto{X}' there (page 4 of 6, inspired by 2.3):<br>
    <br>
    <pre style="color:#1f1c1b;background-color:#ffffff;"><span style="color:#0057ae;">void</span> function(std::pair&lt;<span style="color:#0057ae;">auto</span>{A}, <span style="color:#0057ae;">auto</span>{B}&gt;) {
    <b>static_assert</b>(!std::is_same&lt;A,B&gt;::value, <span style="color:#bf0303;">"they cannot be the same!"</span>);
    printf(<span style="color:#bf0303;">"different</span><span style="color:#924c9d;">\n</span><span style="color:#bf0303;">"</span>);
}</pre>
    <br>
    This validates what I said in a previous email on this thread, that
    without additional identifiers, std::pair&lt;auto,auto&gt; is rather
    pointless for bounded polymorphism. In order to disambiguate with
    the use of auto elsewhere, the authors are forced to use curly
    braces as additional syntax.<br>
    <br>
    Essentially, that is what all of you are trying to say if we take
    N3878 in consideration. Not a problem, but... still no trailing
    sfinae and no easy way to do some real work within that argument
    list without complicating it to "template-header" level. Worse, it
    can mess the type signature. The merit of a separate template
    parameter and argument list is that we have a separation of concerns
    between what is our <i>declarative </i><i>intent</i> and what we
    would like to do based on<i> varying input of parameter ty</i>pes.<br>
    <br>
    I am still saying that such tendency to promote auto's use is not
    going to override the actual merit of having a declarating template
    parameter list (some people call this template header, I won't). It
    also does not cover / address issues with non-type and template-type
    parameters coherently <i>yet</i>. It is an unsolved problem until
    the C++ committee sages think of a way they can do it themselves,
    despite a solution <u><i>can</i></u> already be provided. Pretty
    much like why it took decades to get to 'concepts' in the form of
    predicates. All in due course as Ville says. Only that it is not the
    80s anymore.<br>
    <br>
    <blockquote
      cite="mid:af1beec6-baea-4ea9-bb5f-97e86cf1e680@isocpp.org"
      type="cite">
      <div dir="ltr"><br>
        Regarding your concerns on the original example of
        std::pair&lt;auto, auto&gt;, my proposal doesn't really change
        anything: if you wanted to express the constraint that the types
        must be different *today*, you would still have to resort to
        static assertions and decltype, so I believe what I'm after
        doesn't make the situation worse. <br>
      </div>
    </blockquote>
    <br>
    I know that your proposal does not change anything - because per
    Ville's reference <i>it does not add anything</i>. Also the
    examples I have laid out show quite eloquently that <u><i><b>you
          could express that types must be different yesterday</b></i></u>.
    Ville rhetorically asked, in the context of your OP of how he would
    express the notion of two different types in that construct. Despite
    some people may take this personally, it is technically obvious that
    with 'auto' used that way we only have a pointless shorthand
    favoring latent typing (again...); canonical template notation is
    still superior in covering all cases, even when no SFINAE tricks are
    involved.<br>
    <br>
    That <i>does not mean we should not aim for better</i> over the <i>'hated'
    </i>template keyword, but we should not also hail something as an <u><i><b>important</b></i></u>
    improvement when it is evidently clear that it is not. Not your
    case, but I think most of the arguments in the list are kind of
    staged and rehearsed for supporting X over Y over
    non-really-technical reasons, demanding passive compliance.<br>
    <br>
    Yes, we can now close this thread.<br>
    <br>
    Regards,<br>
    <br>
    George<br>
    <br>
  </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 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 />

--------------030907010904070209020204--

.

------=_Part_4748_349591719.1412259983720
Content-Type: text/plain; charset=UTF-8

Ville, if this is accepted (as a part of Concepts or separately), will it
facilitate the full prohibition of the auto deduction from initializer
lists?

With `std::initializer_list<auto> a = {1, 2, 3, 4, 5};` there would be one
less reason to keep copy initialization `auto a = {1, 2, 3, 4, 5};`
deducing initializer list.

On Thursday, October 2, 2014 11:07:23 AM UTC+4, Ville Voutilainen wrote:
>
> On 1 October 2014 22:11, Andy Prowl <andy....@gmail.com <javascript:>>
> wrote:
> > Actually, wouldn't it be enough to add a static_assert after the
> > declaration?
> >
> > pair<auto, auto> x = foo();
> > static_assert(decltype(x.first) != decltype(x.second), "Error");
>
> Yes.
>
> Also note that what you suggest is already in Concepts, it supports things
> like
> Pair<auto, auto> p = make_pair(0, 'a'); // Ok
>
> What it doesn't yet support is using Concepts in variable declarations:
> "Unlike auto, a constrained-type-specifier cannot be used in the type of
> a variable declaration or the return type of a function.", but I'm sure
> that
> extension will be considered in due course.
>

--

---
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_4748_349591719.1412259983720
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Ville, if this is accepted (as a part of Concepts or separ=
ately), will it facilitate the full prohibition of the auto deduction from =
initializer lists?<br><br>With `std::initializer_list&lt;auto&gt; a =3D {1,=
 2, 3, 4, 5};` there would be one less reason to keep copy initialization `=
auto a =3D {1, 2, 3, 4, 5};` deducing initializer list.<br><br>On Thursday,=
 October 2, 2014 11:07:23 AM UTC+4, Ville Voutilainen wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">On 1 October 2014 22:11, Andy Prowl &lt;<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"tyZUR5ettucJ"=
 onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">andy....@gmail.com</a>&gt; wrote:
<br>&gt; Actually, wouldn't it be enough to add a static_assert after the
<br>&gt; declaration?
<br>&gt;
<br>&gt; pair&lt;auto, auto&gt; x =3D foo();
<br>&gt; static_assert(decltype(x.<wbr>first) !=3D decltype(x.second), "Err=
or");
<br>
<br>Yes.
<br>
<br>Also note that what you suggest is already in Concepts, it supports thi=
ngs
<br>like
<br>Pair&lt;auto, auto&gt; p =3D make_pair(0, 'a'); // Ok
<br>
<br>What it doesn't yet support is using Concepts in variable declarations:
<br>"Unlike auto, a constrained-type-specifier cannot be used in the type o=
f
<br>a variable declaration or the return type of a function.", but I'm sure=
 that
<br>extension will be considered in due course.
<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 />

------=_Part_4748_349591719.1412259983720--

.

On 2 October 2014 17:26, =D0=92=D0=B0=D0=B4=D0=B8=D0=BC <vadim.petrochenkov=
@gmail.com> wrote:
> Ville, if this is accepted (as a part of Concepts or separately), will it
> facilitate the full prohibition of the auto deduction from initializer
> lists?
>
> With `std::initializer_list<auto> a =3D {1, 2, 3, 4, 5};` there would be =
one
> less reason to keep copy initialization `auto a =3D {1, 2, 3, 4, 5};` ded=
ucing
> initializer list.


I don't expect it will have that effect, since a majority of EWG voted
for keeping
the initializer_list deduction for auto =3D {...};
See
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3912.html

--=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_5053_504298260.1412268360337
Content-Type: text/plain; charset=UTF-8

On Thursday, October 2, 2014 3:54:25 PM UTC+2, George Makrydakis wrote:
>
>  I consider the thread *closed*, but given that Andy tries to make a
> point, I will just show the flaws in that reasoning for posterity.
>
> On 10/02/2014 01:17 PM, Andy Prowl wrote:
>
> George,
>
> I'm not sure about what trend "people like me" are demonstrating, but
> honestly I have troubles understanding most of the concerns you are
> expressing. In particular, it seems to me that they are pretty much
> orthogonal to my proposal.
>
>
> Andy,
>
> The double quoted extract in context is implicitly refering to people who
> enjoy automatic type inference and is not intended as a discrediting
> subterfuge, which is quite usual by some members of this list. I consider
> myself part of the people who enjoy automatic type inference, to some
> limited extent.
>
>
> For example, already today there are situations where using trailing
> return type syntax is necessary, depending on what we want to do. And even
> with regular template syntax, you won't be able to avoid SFINAE for e.g.
> expressing the fact that two template type arguments must be different.
>
>
> *Incorrect.* The following snippet, works even with C++98/03 and I am
> pretty much avoiding everything fancy, I just follow simple rules the
> language has since time immemorial with regular function template overload
> syntax and ordering tricks:
>
> #include <cstdio>#include <utility>
> *template*<*typename* A, *typename* B>void function(std::pair<A,B>) { printf("different\n"); }
> *template*<*typename* A>void function(std::pair<A,A>) { printf("same\n"); }
> int main() {
>     function(std::pair<int,long>());
>     function(std::pair<int,int>());
>     *return* 0;
> }
>
>

OK, but why wouldn't the same technique work with auto?

void function(std::pair<auto, auto>) { printf("different\n"); }
*template*<*typename* A>void function(std::pair<A, A>) { printf("same\n"); }



Regarding your concerns on the original example of std::pair<auto, auto>,
> my proposal doesn't really change anything: if you wanted to express the
> constraint that the types must be different *today*, you would still have
> to resort to static assertions and decltype, so I believe what I'm after
> doesn't make the situation worse.
>
>
> I know that your proposal does not change anything - because per Ville's
> reference *it does not add anything*. Also the examples I have laid out
> show quite eloquently that *you could express that types must be
> different yesterday*. Ville rhetorically asked, in the context of your OP
> of how he would express the notion of two different types in that
> construct. Despite some people may take this personally, it is technically
> obvious that with 'auto' used that way we only have a pointless shorthand
> favoring latent typing (again...); canonical template notation is still
> superior in covering all cases, even when no SFINAE tricks are involved.
>



I don't understand why you say it doesn't add anything. It allows you
writing "auto" where it was not previously allowed, without making the
situation worse. If it didn't add anything, the Concepts TS would probably
not bother allowing it. On a language level, it simply completes a parallel
between auto type deduction and template type deduction which only went
half-way before.


Yes, we can now close this thread.
>


Cool, we all agree :)

Thank you for your comments anyway,

Andy


--

---
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_5053_504298260.1412268360337
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, October 2, 2014 3:54:25 PM UTC+2, George Makr=
ydakis wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    I consider the thread <u>closed</u>, but given that Andy tries to
    make a point, I will just show the flaws in that reasoning for
    posterity.<br>
    <br>
    <div>On 10/02/2014 01:17 PM, Andy Prowl
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">George, <br>
        <br>
        I'm not sure about what trend "people like me" are
        demonstrating, but honestly I have troubles understanding most
        of the concerns you are expressing. In particular, it seems to
        me that they are pretty much orthogonal to my proposal.<br>
      </div>
    </blockquote>
    <br>
    Andy,<br>
    <br>
    The double quoted extract in context is implicitly refering to
    people who enjoy automatic type inference and is not intended as a
    discrediting subterfuge, which is quite usual by some members of
    this list. I consider myself part of the people who enjoy automatic
    type inference, to some limited extent.<br>
    <br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr"><br>
        For example, already today there are situations where using
        trailing return type syntax is necessary, depending on what we
        want to do. And even with regular template syntax, you won't be
        able to avoid SFINAE for e.g. expressing the fact that two
        template type arguments must be different.<br>
      </div>
    </blockquote>
    <br>
    <i><b>Incorrect.</b></i> The following snippet, works even with
    C++98/03 and I am pretty much avoiding everything fancy, I just
    follow simple rules the language has since time immemorial with
    regular function template overload syntax and ordering tricks:<br>
    <pre style=3D"color:#1f1c1b;background-color:#ffffff"><span style=3D"co=
lor:#004d84">#include </span><span style=3D"color:#006e28">&lt;cstdio&gt;</=
span>
<span style=3D"color:#004d84">#include </span><span style=3D"color:#006e28"=
>&lt;utility&gt;</span>

<b>template</b>&lt;<b>typename</b> A, <b>typename</b> B&gt;
<span style=3D"color:#0057ae">void</span> function(std::pair&lt;A,B&gt;) { =
printf(<span style=3D"color:#bf0303">"different</span><span style=3D"color:=
#924c9d">\n</span><span style=3D"color:#bf0303">"</span>); }

<b>template</b>&lt;<b>typename</b> A&gt;
<span style=3D"color:#0057ae">void</span> function(std::pair&lt;A,A&gt;) { =
printf(<span style=3D"color:#bf0303">"same</span><span style=3D"color:#924c=
9d">\n</span><span style=3D"color:#bf0303">"</span>); }

<span style=3D"color:#0057ae">int</span> main() {
    function(std::pair&lt;<span style=3D"color:#0057ae">int</span>,<span st=
yle=3D"color:#0057ae">long</span>&gt;()<wbr>);
    function(std::pair&lt;<span style=3D"color:#0057ae">int</span>,<span st=
yle=3D"color:#0057ae">int</span>&gt;())<wbr>;
    <b>return</b> <span style=3D"color:#b08000">0</span>;
}</pre></div></blockquote><div><br></div><div><br></div><div>OK, but why wo=
uldn't the same technique work with auto?</div><div><br><pre style=3D"font-=
size: 13.3333330154419px; color: rgb(31, 28, 27);"><span style=3D"color: rg=
b(0, 87, 174);">void</span> function(std::pair&lt;auto, auto&gt;) { printf(=
<span style=3D"color: rgb(191, 3, 3);">"different</span><span style=3D"colo=
r: rgb(146, 76, 157);">\n</span><span style=3D"color: rgb(191, 3, 3);">"</s=
pan>); }

<b>template</b>&lt;<b>typename</b> A&gt;
<span style=3D"color: rgb(0, 87, 174);">void</span> function(std::pair&lt;A=
, A&gt;) { printf(<span style=3D"color: rgb(191, 3, 3);">"same</span><span =
style=3D"color: rgb(146, 76, 157);">\n</span><span style=3D"color: rgb(191,=
 3, 3);">"</span>); }</pre></div><div><br></div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">=
<blockquote type=3D"cite"><div dir=3D"ltr">
        Regarding your concerns on the original example of
        std::pair&lt;auto, auto&gt;, my proposal doesn't really change
        anything: if you wanted to express the constraint that the types
        must be different *today*, you would still have to resort to
        static assertions and decltype, so I believe what I'm after
        doesn't make the situation worse. <br>
      </div>
    </blockquote>
    <br>
    I know that your proposal does not change anything - because per
    Ville's reference <i>it does not add anything</i>. Also the
    examples I have laid out show quite eloquently that <u><i><b>you
          could express that types must be different yesterday</b></i></u>.
    Ville rhetorically asked, in the context of your OP of how he would
    express the notion of two different types in that construct. Despite
    some people may take this personally, it is technically obvious that
    with 'auto' used that way we only have a pointless shorthand
    favoring latent typing (again...); canonical template notation is
    still superior in covering all cases, even when no SFINAE tricks are
    involved.<br></div></blockquote><div><br><br><br>I don't understand why=
 you say it doesn't add anything. It allows you writing "auto" where it was=
 not previously allowed, without making the situation worse. If it didn't a=
dd anything, the Concepts TS would probably not bother allowing it. On a la=
nguage level, it simply completes a parallel between auto type deduction an=
d template type deduction which only went half-way before.<br><br><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=
=3D"#000000">
    Yes, we can now close this thread.<br></div></blockquote><div><br><br>C=
ool, we all agree :)<br><br>Thank you for your comments anyway,<br><br>Andy=
<br>&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_5053_504298260.1412268360337--

.

This is a multi-part message in MIME format.
--------------040509070806000907020202
Content-Type: text/plain; charset=UTF-8; format=flowed


On 10/02/2014 07:46 PM, Andy Prowl wrote:
>
> OK, but why wouldn't the same technique work with auto?
>
> void  function(std::pair<auto, auto>) { printf("different\n"); }
>
> *template*<*typename*  A>
> void  function(std::pair<A, A>) { printf("same\n"); }
>

You'd have to introduce another, pretty weird rule for partially
ordering the two syntaxes as well and you are resorting to using that
'hideous' template keyword everybody is scared of (kidding)! Ordering
needs to be covered. Also, consider variadics please. I think that what
they have as syntax in N3878 can be used for this, it is seamless
despite its shortcommings in other areas (note, they don't have such an
example, yet, only the auto{} syntax), as I said in a previous email:

void  function(std::pair<auto{A},auto{B}>) {
     *static_assert*(!std::is_same<A,B>::value,"they cannot be the same!");
     printf("different\n");
}


https://groups.google.com/a/isocpp.org/d/msg/std-proposals/klC8PjzRNzI/yRhO-qeikZwJ

>
> I don't understand why you say it doesn't add anything. It allows you
> writing "auto" where it was not previously allowed, without making the
> situation worse. If it didn't add anything, the Concepts TS would
> probably not bother allowing it. On a language level, it simply
> completes a parallel between auto type deduction and template type
> deduction which only went half-way before.
>

In a seriously friendly manner, I am just pointing out some details if
you want to give notation that is superior to template parameter lists,
because as it is, it is not a 1:1 correspondence for every scenario.
Take it only as that. Also, do consider what Ville wrote about
'concepts' authors working on extending auto, you wouldn't like to waste
your time for something they are doing secretly since they have more
leverage, regardless of any actual worth of any argument they put
through... Which is where "adds anything" really goes ;)

>
>     Yes, we can now close this thread.
>
>
>
> Cool, we all agree :)
>
> Thank you for your comments anyway,
>
> Andy
>
Thank you for yours as well, it is a given! Good luck for your virtual
concepts proposal as well.

Good luck,

George

--

---
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/.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    <div class=3D"moz-cite-prefix">On 10/02/2014 07:46 PM, Andy Prowl
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:124f1f9c-bf02-43fc-8cbc-1c5e7e3e2d42@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <div>OK, but why wouldn't the same technique work with auto?</div>
        <div><br>
          <pre style=3D"font-size: 13.3333330154419px; color: rgb(31, 28, 2=
7);"><span style=3D"color: rgb(0, 87, 174);">void</span> function(std::pair=
&lt;auto, auto&gt;) { printf(<span style=3D"color: rgb(191, 3, 3);">"differ=
ent</span><span style=3D"color: rgb(146, 76, 157);">\n</span><span style=3D=
"color: rgb(191, 3, 3);">"</span>); }

<b>template</b>&lt;<b>typename</b> A&gt;
<span style=3D"color: rgb(0, 87, 174);">void</span> function(std::pair&lt;A=
, A&gt;) { printf(<span style=3D"color: rgb(191, 3, 3);">"same</span><span =
style=3D"color: rgb(146, 76, 157);">\n</span><span style=3D"color: rgb(191,=
 3, 3);">"</span>); }</pre>
        </div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    You'd have to introduce another, pretty weird rule for partially
    ordering the two syntaxes as well and you are resorting to using
    that 'hideous' template keyword everybody is scared of (kidding)!
    Ordering needs to be covered. Also, consider variadics please. I
    think that what they have as syntax in N3878 can be used for this,
    it is seamless despite its shortcommings in other areas (note, they
    don't have such an example, yet, only the auto{} syntax), as I said
    in a previous email:<br>
    <pre style=3D"color:#1f1c1b;background-color:#ffffff"><span style=3D"co=
lor:#0057ae">void</span> function(std::pair&lt;<span style=3D"color:#0057ae=
">auto</span>{A}, <span style=3D"color:#0057ae">auto</span>{B}&gt;) {
    <b>static_assert</b>(!std::is_same&lt;A,<wbr>B&gt;::value, <span style=
=3D"color:#bf0303">"they cannot be the same!"</span>);
    printf(<span style=3D"color:#bf0303">"different</span><span style=3D"co=
lor:#924c9d">\n</span><span style=3D"color:#bf0303">"</span>);
}</pre>
    <br>
    <a
href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/klC8PjzR=
NzI/yRhO-qeikZwJ">https://groups.google.com/a/isocpp.org/d/msg/std-proposal=
s/klC8PjzRNzI/yRhO-qeikZwJ</a><br>
    <br>
    <blockquote
      cite=3D"mid:124f1f9c-bf02-43fc-8cbc-1c5e7e3e2d42@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          I don't understand why you say it doesn't add anything. It
          allows you writing "auto" where it was not previously allowed,
          without making the situation worse. If it didn't add anything,
          the Concepts TS would probably not bother allowing it. On a
          language level, it simply completes a parallel between auto
          type deduction and template type deduction which only went
          half-way before.<br>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    In a seriously friendly manner, I am just pointing out some details
    if you want to give notation that is superior to template parameter
    lists, because as it is, it is not a 1:1 correspondence for every
    scenario. Take it only as that. Also, do consider what Ville wrote
    about 'concepts' authors working on extending auto, you wouldn't
    like to waste your time for something they are doing secretly since
    they have more leverage, regardless of any actual worth of any
    argument they put through... Which is where "adds anything" really
    goes ;)<br>
    <br>
    <blockquote
      cite=3D"mid:124f1f9c-bf02-43fc-8cbc-1c5e7e3e2d42@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000"> Yes, we can now close
            this thread.<br>
          </div>
        </blockquote>
        <div><br>
          <br>
          Cool, we all agree :)<br>
          <br>
          Thank you for your comments anyway,<br>
          <br>
          Andy<br>
          =C2=A0</div>
      </div>
      <br>
    </blockquote>
    Thank you for yours as well, it is a given! Good luck for your
    virtual concepts proposal as well.<br>
    <br>
    Good luck,<br>
    <br>
    George<br>
    <br>
  </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 />

--------------040509070806000907020202--

.

On 2 October 2014 20:38, George Makrydakis <irrequietus@gmail.com> wrote:
> OK, but why wouldn't the same technique work with auto?
>
> void function(std::pair<auto, auto>) { printf("different\n"); }
>
> template<typename A>
> void function(std::pair<A, A>) { printf("same\n"); }
>
>
>
> You'd have to introduce another, pretty weird rule for partially ordering

You don't have to introduce anything. The concepts proposal's working version
already includes a specification how such an abbreviated function translates
to a function template, and the partial ordering suggested by Andy
already works.

> as it is, it is not a 1:1 correspondence for every scenario. Take it only as
> that. Also, do consider what Ville wrote about 'concepts' authors working on
> extending auto, you wouldn't like to waste your time for something they are
> doing secretly since they have more leverage, regardless of any actual worth

"Secretly"? Does
https://github.com/cplusplus/concepts-ts/
perhaps not work for you?

--

---
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/.

.

This is a multi-part message in MIME format.
--------------050200080901040305070906
Content-Type: text/plain; charset=UTF-8; format=flowed


On 10/02/2014 09:04 PM, Ville Voutilainen wrote:
> On 2 October 2014 20:38, George Makrydakis <irrequietus@gmail.com> wrote:
>> OK, but why wouldn't the same technique work with auto?
>>
>> void function(std::pair<auto, auto>) { printf("different\n"); }
>>
>> template<typename A>
>> void function(std::pair<A, A>) { printf("same\n"); }
>>
>>
>>
>> You'd have to introduce another, pretty weird rule for partially ordering
> You don't have to introduce anything. The concepts proposal's working version
> already includes a specification how such an abbreviated function translates
> to a function template, and the partial ordering suggested by Andy
> already works.

The fact that they introduced it means that they took care of it. Also
notice the example I made with their own syntax. Does your compiler also
not requiring any changes for implementing that when ordering has to be
taken care of? Seriously? Heh. As you wish. Let's see how it will work
with template-type parameters and variadics; and reaching 1:1
correspondence with all that templates do.

>> as it is, it is not a 1:1 correspondence for every scenario. Take it only as
>> that. Also, do consider what Ville wrote about 'concepts' authors working on
>> extending auto, you wouldn't like to waste your time for something they are
>> doing secretly since they have more leverage, regardless of any actual worth
> "Secretly"? Does
> https://github.com/cplusplus/concepts-ts/
> perhaps not work for you?

For informing you of your "not published yet" policy for things you guys
limit access, this comes from your message Ville:

https://groups.google.com/a/isocpp.org/d/msg/std-proposals/klC8PjzRNzI/FkZf3Wv7620J

On 10/02/2014 01:13 PM, Ville Voutilainen wrote:

> Based on a very new working draft that is not yet published, yes, I am
> sure.
> I took the example I pasted from that draft

Seriously, you cannot say that you put your private EWG mailing list
archives there in github. And, I like you too Ville, but your EWG is a
major stinker in some respects in the way it behaves. _*/Perhaps/*_ they
are good in others, but before calling out that thing "public" I suggest
you get a good look on your private mailing lists and how you guys
organize meetings. Let's not derail into offtopicness again.

What part of "Secretly" you did not get? Anyway, enjoy the upcoming
meeting. It is a nice stage.

George

--

---
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/.

--------------050200080901040305070906
Content-Type: text/html; charset=UTF-8

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 10/02/2014 09:04 PM, Ville
      Voutilainen wrote:<br>
    </div>
    <blockquote
cite="mid:CAFk2RUb1Xf9uX2yTSuTmth+9Wt37tGEWH3jF=eGeztVYBuwkkA@mail.gmail.com"
      type="cite">
      <pre wrap="">On 2 October 2014 20:38, George Makrydakis <a class="moz-txt-link-rfc2396E" href="mailto:irrequietus@gmail.com">&lt;irrequietus@gmail.com&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">OK, but why wouldn't the same technique work with auto?

void function(std::pair&lt;auto, auto&gt;) { printf("different\n"); }

template&lt;typename A&gt;
void function(std::pair&lt;A, A&gt;) { printf("same\n"); }



You'd have to introduce another, pretty weird rule for partially ordering
</pre>
      </blockquote>
      <pre wrap="">
You don't have to introduce anything. The concepts proposal's working version
already includes a specification how such an abbreviated function translates
to a function template, and the partial ordering suggested by Andy
already works.</pre>
    </blockquote>
    <br>
    The fact that they introduced it means that they took care of it.
    Also notice the example I made with their own syntax. Does your
    compiler also not requiring any changes for implementing that when
    ordering has to be taken care of? Seriously? Heh. As you wish. Let's
    see how it will work with template-type parameters and variadics;
    and reaching 1:1 correspondence with all that templates do.<br>
    <br>
    <blockquote
cite="mid:CAFk2RUb1Xf9uX2yTSuTmth+9Wt37tGEWH3jF=eGeztVYBuwkkA@mail.gmail.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">as it is, it is not a 1:1 correspondence for every scenario. Take it only as
that. Also, do consider what Ville wrote about 'concepts' authors working on
extending auto, you wouldn't like to waste your time for something they are
doing secretly since they have more leverage, regardless of any actual worth
</pre>
      </blockquote>
      <pre wrap="">
"Secretly"? Does
<a class="moz-txt-link-freetext" href="https://github.com/cplusplus/concepts-ts/">https://github.com/cplusplus/concepts-ts/</a>
perhaps not work for you?
</pre>
    </blockquote>
    <br>
    For informing you of your "not published yet" policy for things you
    guys limit access, this comes from your message Ville:<br>
    <br>
    <a
href="https://groups.google.com/a/isocpp.org/d/msg/std-proposals/klC8PjzRNzI/FkZf3Wv7620J">https://groups.google.com/a/isocpp.org/d/msg/std-proposals/klC8PjzRNzI/FkZf3Wv7620J</a><br>
    <br>
    On 10/02/2014 01:13 PM, Ville Voutilainen wrote:<br>
    <br>
    <blockquote type="cite">Based on a very new working draft that is
      not yet published, yes, I am sure.
      <br>
      I took the example I pasted from that draft</blockquote>
    <br>
    Seriously, you cannot say that you put your private EWG mailing list
    archives there in github. And, I like you too Ville, but your EWG is
    a major stinker in some respects in the way it behaves. <u><b><i>Perhaps</i></b></u>
    they are good in others, but before calling out that thing "public"
    I suggest you get a good look on your private mailing lists and how
    you guys organize meetings. Let's not derail into offtopicness
    again.<br>
    <br>
    What part of "Secretly" you did not get? Anyway, enjoy the upcoming
    meeting. It is a nice stage.<br>
    <br>
    George<br>
    <br>
  </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 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 />

--------------050200080901040305070906--

.

On 2 October 2014 21:43, George Makrydakis <irrequietus@gmail.com> wrote:
> "Secretly"? Does
> https://github.com/cplusplus/concepts-ts/
> perhaps not work for you?
>
>
> For informing you of your "not published yet" policy for things you guys
> limit access, this comes from your message Ville:
>
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/klC8PjzRNzI/FkZf3Wv7620J
>
> On 10/02/2014 01:13 PM, Ville Voutilainen wrote:
>
> Based on a very new working draft that is not yet published, yes, I am sure.
> I took the example I pasted from that draft

It so happens that that draft is apparently public, since the version
in that repository contains the very
example I quoted. So you can look at how the new auto semantics work
just fine, if you happen to look
at the non-secret work that is happening in that repository.

Regarding the internal mailing lists, yes, there are communication
facilities of the committee
that are not public, and these forums have provided ample reason to
keep things that way.

You seem to be the last person to lecture about "derailing into
off-topicness", as far as I can see.

--

---
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/.

.

This is a multi-part message in MIME format.
--------------020804050208010106000807
Content-Type: text/plain; charset=UTF-8; format=flowed


On 10/02/2014 09:58 PM, Ville Voutilainen wrote:
> On 2 October 2014 21:43, George Makrydakis <irrequietus@gmail.com> wrote:
>> "Secretly"? Does
>> https://github.com/cplusplus/concepts-ts/
>> perhaps not work for you?
>>
>>
>> For informing you of your "not published yet" policy for things you guys
>> limit access, this comes from your message Ville:
>>
>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/klC8PjzRNzI/FkZf3Wv7620J
>>
>> On 10/02/2014 01:13 PM, Ville Voutilainen wrote:
>>
>> Based on a very new working draft that is not yet published, yes, I am sure.
>> I took the example I pasted from that draft
> It so happens that that draft is apparently public, since the version
> in that repository contains the very
> example I quoted. So you can look at how the new auto semantics work
> just fine, if you happen to look
> at the non-secret work that is happening in that repository.

Exactly where I want you. You seem to be assuming that there is *no*
"secret" work happening *_/as the default/_*, which is quite the
opposite. That is the end-pit of concepts. Not the fountain. This is not
the thread for starting a real hellfire of certain quite galant and
generous EWG practices of which I do have first hand experience. You
also are aware of how things are "delegated" aren't you. So let's leave
it there as it is of little concern to "outsiders".

>
> Regarding the internal mailing lists, yes, there are communication
> facilities of the committee
> that are not public, and these forums have provided ample reason to
> keep things that way.

Here we go. Thanks for providing citable feedback on the fact that these
public lists are only considered a gimmick and that things are decided
in your private EWG quarters. As long as these lists provide you
marketing pool to sell your "open" character, they serve their purpose.
You do not really need the ideas presented by true outsiders here. You
guys don't really have respect for all volunteers, just for your
"volunteers" - and that is /_my_/ first-hand experience.

>
> You seem to be the last person to lecture about "derailing into
> off-topicness", as far as I can see.
>

Everytime you will be defensive of current EWG practices with /me/,
/"/you/" /will be getting your disarming reply, on-topic or off-topic
given that "you" did not respect "your" rules when you had to. This has
nothing to do with you as a person (you are an ok guy), but as an EWGer,
you won't be able to defend those practices. Since all of you EWGers
will be more careful from now on and follow your own rules, I think that
something is gained for any contributors that may come. I gain _zero_
out of this.

Other than that, again you are a valid technical commenter /I respect/
on the things you really do know about. I will gladly accept to be
/proven/ wrong by you on a really technical subject. No point in
continuing to go offtopic dear Ville. Let's close /all of it here./ The
technical aspects in C++ are interesting, only that they are deeply
poisoned by social manure and pomposity.

George

--

---
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/.

--------------020804050208010106000807
Content-Type: text/html; charset=UTF-8

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 10/02/2014 09:58 PM, Ville
      Voutilainen wrote:<br>
    </div>
    <blockquote
cite="mid:CAFk2RUbF19EaShmw=Y+b_txasnQDeZw+ba8pkgpgN3JBRKmYyw@mail.gmail.com"
      type="cite">
      <pre wrap="">On 2 October 2014 21:43, George Makrydakis <a class="moz-txt-link-rfc2396E" href="mailto:irrequietus@gmail.com">&lt;irrequietus@gmail.com&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">"Secretly"? Does
<a class="moz-txt-link-freetext" href="https://github.com/cplusplus/concepts-ts/">https://github.com/cplusplus/concepts-ts/</a>
perhaps not work for you?


For informing you of your "not published yet" policy for things you guys
limit access, this comes from your message Ville:

<a class="moz-txt-link-freetext" href="https://groups.google.com/a/isocpp.org/d/msg/std-proposals/klC8PjzRNzI/FkZf3Wv7620J">https://groups.google.com/a/isocpp.org/d/msg/std-proposals/klC8PjzRNzI/FkZf3Wv7620J</a>

On 10/02/2014 01:13 PM, Ville Voutilainen wrote:

Based on a very new working draft that is not yet published, yes, I am sure.
I took the example I pasted from that draft
</pre>
      </blockquote>
      <pre wrap="">
It so happens that that draft is apparently public, since the version
in that repository contains the very
example I quoted. So you can look at how the new auto semantics work
just fine, if you happen to look
at the non-secret work that is happening in that repository.</pre>
    </blockquote>
    <br>
    Exactly where I want you. You seem to be assuming that there is <b>no</b>
    "secret" work happening <b><u><i>as the default</i></u></b>, which
    is quite the opposite. That is the end-pit of concepts. Not the
    fountain. This is not the thread for starting a real hellfire of
    certain quite galant and generous EWG practices of which I do have
    first hand experience. You also are aware of how things are
    "delegated" aren't you. So let's leave it there as it is of little
    concern to "outsiders".<br>
    <br>
    <blockquote
cite="mid:CAFk2RUbF19EaShmw=Y+b_txasnQDeZw+ba8pkgpgN3JBRKmYyw@mail.gmail.com"
      type="cite">
      <pre wrap="">

Regarding the internal mailing lists, yes, there are communication
facilities of the committee
that are not public, and these forums have provided ample reason to
keep things that way.</pre>
    </blockquote>
    <br>
    Here we go. Thanks for providing citable feedback on the fact that
    these public lists are only considered a gimmick and that things are
    decided in your private EWG quarters. As long as these lists provide
    you marketing pool to sell your "open" character, they serve their
    purpose. You do not really need the ideas presented by true
    outsiders here. You guys don't really have respect for all
    volunteers, just for your "volunteers" - and that is <i><u>my</u></i>
    first-hand experience.<br>
    <br>
    <blockquote
cite="mid:CAFk2RUbF19EaShmw=Y+b_txasnQDeZw+ba8pkgpgN3JBRKmYyw@mail.gmail.com"
      type="cite">
      <pre wrap="">

You seem to be the last person to lecture about "derailing into
off-topicness", as far as I can see.

</pre>
    </blockquote>
    <br>
    Everytime you will be defensive of current EWG practices with <i>me</i>,
    <i>"</i>you<i>" </i>will be getting your disarming reply, on-topic
    or off-topic given that "you" did not respect "your" rules when you
    had to. This has nothing to do with you as a person (you are an ok
    guy), but as an EWGer, you won't be able to defend those practices.
    Since all of you EWGers will be more careful from now on and follow
    your own rules, I think that something is gained for any
    contributors that may come. I gain <u>zero</u> out of this.<br>
    <br>
    Other than that, again you are a valid technical commenter <i>I
      respect</i> on the things you really do know about. I will gladly
    accept to be <i>proven</i> wrong by you on a really technical
    subject. No point in continuing to go offtopic dear Ville. Let's
    close <i>all of it here.</i> The technical aspects in C++ are
    interesting, only that they are deeply poisoned by social manure and
    pomposity.<br>
    <br>
    George<br>
    <br>
  </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 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 />

--------------020804050208010106000807--

.

--001a11c25bdab4a28d0504783cdd
Content-Type: text/plain; charset=UTF-8

On 2 October 2014 15:55, George Makrydakis <irrequietus@gmail.com> wrote:

>
> On 10/02/2014 09:58 PM, Ville Voutilainen wrote:
>
> On 2 October 2014 21:43, George Makrydakis <irrequietus@gmail.com> <irrequietus@gmail.com> wrote:
>
>  "Secretly"? Doeshttps://github.com/cplusplus/concepts-ts/
> perhaps not work for you?
>
>
> For informing you of your "not published yet" policy for things you guys
> limit access, this comes from your message Ville:
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/klC8PjzRNzI/FkZf3Wv7620J
>
> On 10/02/2014 01:13 PM, Ville Voutilainen wrote:
>
> Based on a very new working draft that is not yet published, yes, I am sure.
> I took the example I pasted from that draft
>
>  It so happens that that draft is apparently public, since the version
> in that repository contains the very
> example I quoted. So you can look at how the new auto semantics work
> just fine, if you happen to look
> at the non-secret work that is happening in that repository.
>
>
> Exactly where I want you. You seem to be assuming that there is *no*
> "secret" work happening *as the default*, which is quite the opposite.
>

Huh?

People work on papers.  They may or may not have a web cam pointed at their
keyboards so you can watch them type.  They may or may not put them on
public repos while they are working on them.  They may or may not send
drafts to their friends.  They may or may not send drafts to the internal
committee mailing lists.  They may or may not send drafts to this list.  At
some point, if they wish to present it, they will get an N-number and it
will be published as part of a mailing.

I don't see how any of that is secret.  That is just how people work, and
different people work differently.

If you wanted to see the Concepts draft, all you had to do was ask how.
Instead, you chose to fan the flames by saying:

Also, do consider what Ville wrote about 'concepts' authors working on
> extending auto, you wouldn't like to waste your time for something they are
> doing secretly since they have more leverage, regardless of any actual
> worth of any argument they put through...


Was that really called for?


> That is the end-pit of concepts. Not the fountain. This is not the thread
> for starting a real hellfire of certain quite galant and generous EWG
> practices of which I do have first hand experience. You also are aware of
> how things are "delegated" aren't you. So let's leave it there as it is of
> little concern to "outsiders".
>

Then why do you keep bringing it up??

> Regarding the internal mailing lists, yes, there are communication
> facilities of the committee
> that are not public, and these forums have provided ample reason to
> keep things that way.
>
>
> Here we go. Thanks for providing citable feedback on the fact that these
> public lists are only considered a gimmick and that things are decided in
> your private EWG quarters.
>

They aren't a gimmick.  In some sense, they are an experiment.  IMO, the
signal to noise ratio is far lower here than on the internal committee
lists.  For me, it isn't yet down to zero, which is why I still
occasionally read it, rarely post to it, but am willing to put any drafts
of papers I'm writing on it because I have gotten useful feedback in the
past.  I have noticed that posting by committee members is way down from
two years ago when this list was created.


> As long as these lists provide you marketing pool to sell your "open"
> character, they serve their purpose. You do not really need the ideas
> presented by true outsiders here. You guys don't really have respect for
> all volunteers, just for your "volunteers" - and that is *my* first-hand
> experience.
>

Yes, you had a bad experience.  Life sucks sometimes.  As you keep telling
us and everybody else, allowing you to present a paper that was not
published in the mailing was a mistake.

Some of us who supported creating these lists in the first place did so
because we thought that making it easier for people to have access to
Committee members was a good thing.  Were we wrong?

If people on this mailing list are going to continually belittle us
Committee members and our efforts, I for one have far better, more positive
things to do with my time.

> You seem to be the last person to lecture about "derailing into
> off-topicness", as far as I can see.
>
>
>
> Everytime you will be defensive of current EWG practices with *me*, *"*you*"
> *will be getting your disarming reply, on-topic or off-topic given that
> "you" did not respect "your" rules when you had to.
>

You, not Ville, are the person who keeps bringing up your EWG experience.
How is that at all relevant to "Generalizing the equivalence of auto and
template type deduction"?


> This has nothing to do with you as a person (you are an ok guy), but as an
> EWGer, you won't be able to defend those practices. Since all of you EWGers
> will be more careful from now on and follow your own rules, I think that
> something is gained for any contributors that may come. I gain *zero* out
> of this.
>
> Other than that, again you are a valid technical commenter *I respect* on
> the things you really do know about. I will gladly accept to be *proven*
> wrong by you on a really technical subject. No point in continuing to go
> offtopic dear Ville. Let's close *all of it here.*
>

You keep saying that, but it sure looks like you'd rather get the last word
in instead of winding it down.  Closing a discussion is easy, and doesn't
require any drama whatsoever.  Just stop posting on the topic.  If others
keep going, just mute the conversation.


> The technical aspects in C++ are interesting, only that they are deeply
> poisoned by social manure and pomposity.
>

Continually using words like "social manure and pomposity" to describe the
Committee poisons this list, at least for me.
--
 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/.

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

<div dir=3D"ltr">On 2 October 2014 15:55, George Makrydakis <span dir=3D"lt=
r">&lt;<a href=3D"mailto:irrequietus@gmail.com" target=3D"_blank">irrequiet=
us@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
    <br>
    <div>On 10/02/2014 09:58 PM, Ville
      Voutilainen wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <pre>On 2 October 2014 21:43, George Makrydakis <a href=3D"mailto:irr=
equietus@gmail.com" target=3D"_blank">&lt;irrequietus@gmail.com&gt;</a> wro=
te:
</pre>
      <blockquote type=3D"cite">
        <pre>&quot;Secretly&quot;? Does
<a href=3D"https://github.com/cplusplus/concepts-ts/" target=3D"_blank">htt=
ps://github.com/cplusplus/concepts-ts/</a>
perhaps not work for you?


For informing you of your &quot;not published yet&quot; policy for things y=
ou guys
limit access, this comes from your message Ville:

<a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/klC8P=
jzRNzI/FkZf3Wv7620J" target=3D"_blank">https://groups.google.com/a/isocpp.o=
rg/d/msg/std-proposals/klC8PjzRNzI/FkZf3Wv7620J</a>

On 10/02/2014 01:13 PM, Ville Voutilainen wrote:

Based on a very new working draft that is not yet published, yes, I am sure=
..
I took the example I pasted from that draft
</pre>
      </blockquote>
      <pre>It so happens that that draft is apparently public, since the ve=
rsion
in that repository contains the very
example I quoted. So you can look at how the new auto semantics work
just fine, if you happen to look
at the non-secret work that is happening in that repository.</pre>
    </blockquote>
    <br></span>
    Exactly where I want you. You seem to be assuming that there is <b>no</=
b>
    &quot;secret&quot; work happening <b><u><i>as the default</i></u></b>, =
which
    is quite the opposite. </div></blockquote><div><br></div><div>Huh?</div=
><div><br></div><div>People work on papers.=C2=A0 They may or may not have =
a web cam pointed at their keyboards so you can watch them type.=C2=A0 They=
 may or may not put them on public repos while they are working on them.=C2=
=A0 They may or may not send drafts to their friends.=C2=A0 They may or may=
 not send drafts to the internal committee mailing lists.=C2=A0 They may or=
 may not send drafts to this list.=C2=A0 At some point, if they wish to pre=
sent it, they will get an N-number and it will be published as part of a ma=
iling.</div><div><br></div><div>I don&#39;t see how any of that is secret.=
=C2=A0 That is just how people work, and different people work differently.=
</div><div><br></div><div>If you wanted to see the Concepts draft, all you =
had to do was ask how.=C2=A0 Instead, you chose to fan the flames by saying=
:</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor=
der-left-style:solid;padding-left:1ex"><span style=3D"font-family:arial,san=
s-serif;font-size:13px">Also, do consider what Ville wrote about &#39;conce=
pts&#39; authors working on extending auto, you wouldn&#39;t like to waste =
your time for something they are doing secretly since they have more levera=
ge, regardless of any actual worth of any argument they put through...</spa=
n></blockquote><div><br></div><div>Was that really called for?=C2=A0</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">=
That is the end-pit of concepts. Not the
    fountain. This is not the thread for starting a real hellfire of
    certain quite galant and generous EWG practices of which I do have
    first hand experience. You also are aware of how things are
    &quot;delegated&quot; aren&#39;t you. So let&#39;s leave it there as it=
 is of little
    concern to &quot;outsiders&quot;.</div></blockquote><div><br></div><div=
>Then why do you keep bringing it up??</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000"><span class=3D""><blockquote type=3D"cite"><p=
re>Regarding the internal mailing lists, yes, there are communication
facilities of the committee
that are not public, and these forums have provided ample reason to
keep things that way.</pre>
    </blockquote>
    <br></span>
    Here we go. Thanks for providing citable feedback on the fact that
    these public lists are only considered a gimmick and that things are
    decided in your private EWG quarters. </div></blockquote><div><br></div=
><div>They aren&#39;t a gimmick.=C2=A0 In some sense, they are an experimen=
t.=C2=A0 IMO, the signal to noise ratio is far lower here than on the inter=
nal committee lists.=C2=A0 For me, it isn&#39;t yet down to zero, which is =
why I still occasionally read it, rarely post to it, but am willing to put =
any drafts of papers I&#39;m writing on it because I have gotten useful fee=
dback in the past.=C2=A0 I have noticed that posting by committee members i=
s way down from two years ago when this list was created.</div><div>=C2=A0<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">As long=
 as these lists provide
    you marketing pool to sell your &quot;open&quot; character, they serve =
their
    purpose. You do not really need the ideas presented by true
    outsiders here. You guys don&#39;t really have respect for all
    volunteers, just for your &quot;volunteers&quot; - and that is <i><u>my=
</u></i>
    first-hand experience.</div></blockquote><div><br></div><div>Yes, you h=
ad a bad experience.=C2=A0 Life sucks sometimes.=C2=A0 As you keep telling =
us and everybody else, allowing you<i>=C2=A0</i>to present a paper that was=
 not published in the mailing was a mistake.</div><div><br></div><div>Some =
of us who supported creating these lists in the first place did so because =
we thought that making it easier for people to have access to Committee mem=
bers was a good thing.=C2=A0 Were we wrong?</div><div><br></div><div>If peo=
ple on this mailing list are going to continually belittle us Committee mem=
bers and our efforts, I for one have far better, more positive things to do=
 with my time.</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#0000=
00"><span class=3D""><blockquote type=3D"cite"><pre>You seem to be the last=
 person to lecture about &quot;derailing into
off-topicness&quot;, as far as I can see.

</pre>
    </blockquote>
    <br></span>
    Everytime you will be defensive of current EWG practices with <i>me</i>=
,
    <i>&quot;</i>you<i>&quot; </i>will be getting your disarming reply, on-=
topic
    or off-topic given that &quot;you&quot; did not respect &quot;your&quot=
; rules when you
    had to.</div></blockquote><div><br></div><div>You, not Ville, are the p=
erson who keeps bringing up your EWG experience.=C2=A0 How is that at all r=
elevant to &quot;Generalizing the equivalence of auto and template type ded=
uction&quot;?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor=3D"#FFFFF=
F" text=3D"#000000"> This has nothing to do with you as a person (you are a=
n ok
    guy), but as an EWGer, you won&#39;t be able to defend those practices.
    Since all of you EWGers will be more careful from now on and follow
    your own rules, I think that something is gained for any
    contributors that may come. I gain <u>zero</u> out of this.<br>
    <br>
    Other than that, again you are a valid technical commenter <i>I
      respect</i> on the things you really do know about. I will gladly
    accept to be <i>proven</i> wrong by you on a really technical
    subject. No point in continuing to go offtopic dear Ville. Let&#39;s
    close <i>all of it here.</i> </div></blockquote><div><br></div><div>You=
 keep saying that, but it sure looks like you&#39;d rather get the last wor=
d in instead of winding it down.=C2=A0 Closing a discussion is easy, and do=
esn&#39;t require any drama whatsoever.=C2=A0 Just stop posting on the topi=
c.=C2=A0 If others keep going, just mute the conversation.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">The techni=
cal aspects in C++ are
    interesting, only that they are deeply poisoned by social manure and
    pomposity.</div></blockquote><div><br></div><div>Continually using word=
s like &quot;social manure and pomposity&quot; to describe the Committee po=
isons this list, at least for me.</div></div>-- <br>=C2=A0Nevin &quot;:-)&q=
uot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" targe=
t=3D"_blank">nevin@eviloverlord.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 />

--001a11c25bdab4a28d0504783cdd--

.

This is a multi-part message in MIME format.
--------------070608020809030803020705
Content-Type: text/plain; charset=UTF-8; format=flowed


On 10/03/2014 01:35 AM, Nevin Liber wrote:
>
> People work on papers.  They may or may not have a web cam pointed at
> their keyboards so you can watch them type.  They may or may not put
> them on public repos while they are working on them.  They may or may
> not send drafts to their friends.  They may or may not send drafts to
> the internal committee mailing lists.  They may or may not send drafts
> to this list.  At some point, if they wish to present it, they will
> get an N-number and it will be published as part of a mailing.
>
> I don't see how any of that is secret.  That is just how people work,
> and different people work differently.
>
Mr Liber,

First, you seemed to be one of the kindest people in the last meeting.
Now, I am very much aware of all the papers in question since I have
cited them in the past, if you follow technical discussions here as well
as being overly protective of your community (as you should be). The
"secret" has to do with what goes behind the scenes, especially when
prominent members of your community make convenient procedural
"mistakes" because they are favoring particular lobbies instead of
evaluating technical arguments that have already been made. My
documented disillusionment of the EWG, was important in understanding
this - as well as helping me out in becoming aware of who actually does
any work there and who comes out as doing it.

Your prominent members cannot be giving a library recommendation based
on non-arguments for one thing to its original author in draft stage and
start work on a language feature implementation on the same thing the
next day without any mention of what already went through. You should be
fully aware of how this looks. And everybody loses.

> You keep saying that, but it sure looks like you'd rather get the last
> word in instead of winding it down. Closing a discussion is easy, and
> doesn't require any drama whatsoever.  Just stop posting on the
> topic.  If others keep going, just mute the conversation.
>
>     The technical aspects in C++ are interesting, only that they are
>     deeply poisoned by social manure and pomposity.
>
>
> Continually using words like "social manure and pomposity" to describe
> the Committee poisons this list, at least for me.
>

My first hand experience is that certain procedures followed in your
meetings are problematic, as is questionable the way certain groups
within the language operate in respect to newcoming authors. I do not
need to remind you of Herb Sutter's remark held during a presentation on
why following procedure is important. Deviating from said procedure, is
what truly poisons your community. It makes contributions on this
mailing list feel rehearsed enough by certain lobbies to be marketing
ploys for scavenging the good will and effort of others.
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/qcKUf-U7_YU/14de0yze2>


 1. <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/qcKUf-U7_YU/14de0yze2>https://groups.google.com/a/isocpp.org/d/msg/std-proposals/qcKUf-U7_YU/14de0yze2b8J
 2. https://groups.google.com/a/isocpp.org/d/msg/std-proposals/qIs0Ws7WdwA/sE0lf-aYGGoJ

Given that you love what you do, make sure that the language subgroups
you are involved with, stay clean in respect to their dealings with
truly external contributors in the future - /that are invited to do
something/. I gain _zero_ out of winning an argument with you, since
your own knowledge of the situation is rather incomplete and your good
will misguided. As was mine.

Regards,

George

--

---
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/.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    <div class=3D"moz-cite-prefix">On 10/03/2014 01:35 AM, Nevin Liber
      wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CAGg_6+MDBkjqENpkPCGpyOerqVRAtxM+Unjz7zChLp6YXGPbfQ@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>People work on papers.=C2=A0 They may or may not have a we=
b
              cam pointed at their keyboards so you can watch them
              type.=C2=A0 They may or may not put them on public repos whil=
e
              they are working on them.=C2=A0 They may or may not send draf=
ts
              to their friends.=C2=A0 They may or may not send drafts to th=
e
              internal committee mailing lists.=C2=A0 They may or may not
              send drafts to this list.=C2=A0 At some point, if they wish t=
o
              present it, they will get an N-number and it will be
              published as part of a mailing.</div>
            <div><br>
            </div>
            <div>I don't see how any of that is secret.=C2=A0 That is just
              how people work, and different people work differently.</div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    Mr Liber,<br>
    <br>
    First, you seemed to be one of the kindest people in the last
    meeting. Now, I am very much aware of all the papers in question
    since I have cited them in the past, if you follow technical
    discussions here as well as being overly protective of your
    community (as you should be). The "secret" has to do with what goes
    behind the scenes, especially when prominent members of your
    community make convenient procedural "mistakes" because they are
    favoring particular lobbies instead of evaluating technical
    arguments that have already been made. My documented disillusionment
    of the EWG, was important in understanding this - as well as helping
    me out in becoming aware of who actually does any work there and who
    comes out as doing it.<br>
    <br>
    Your prominent members cannot be giving a library recommendation
    based on non-arguments for one thing to its original author in draft
    stage and start work on a language feature implementation on the
    same thing the next day without any mention of what already went
    through. You should be fully aware of how this looks. And everybody
    loses.<br>
    <br>
    <blockquote
cite=3D"mid:CAGg_6+MDBkjqENpkPCGpyOerqVRAtxM+Unjz7zChLp6YXGPbfQ@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>You keep saying that, but it sure looks like you'd
              rather get the last word in instead of winding it down.=C2=A0
              Closing a discussion is easy, and doesn't require any
              drama whatsoever.=C2=A0 Just stop posting on the topic.=C2=A0=
 If
              others keep going, just mute the conversation.</div>
            <div>=C2=A0</div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">
              <div bgcolor=3D"#FFFFFF" text=3D"#000000">The technical
                aspects in C++ are interesting, only that they are
                deeply poisoned by social manure and pomposity.</div>
            </blockquote>
            <div><br>
            </div>
            <div>Continually using words like "social manure and
              pomposity" to describe the Committee poisons this list, at
              least for me.</div>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    My first hand experience is that certain procedures followed in your
    meetings are problematic, as is questionable the way certain groups
    within the language operate in respect to newcoming authors. I do
    not need to remind you of Herb Sutter's remark held during a
    presentation on why following procedure is important. Deviating from
    said procedure, is what truly poisons your community. It makes
    contributions on this mailing list feel rehearsed enough by certain
    lobbies to be marketing ploys for scavenging the good will and
    effort of others.<a
href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/qcKUf-U7=
_YU/14de0yze2"><br>
    </a>
    <ol>
      <li><a
href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/qcKUf-U7=
_YU/14de0yze2"><a>https://groups.google.com/a/isocpp.org/d/msg/std-proposal=
s/qcKUf-U7_YU/14de0yze2</a><a>b8J</a></a></li>
      <li><a
href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/qIs0Ws7W=
dwA/sE0lf-aYGGoJ">https://groups.google.com/a/isocpp.org/d/msg/std-proposal=
s/qIs0Ws7WdwA/sE0lf-aYGGoJ</a></li>
    </ol>
    Given that you love what you do, make sure that the language
    subgroups you are involved with, stay clean in respect to their
    dealings with truly external contributors in the future - <i>that
      are invited to do something</i>. I gain <u>zero</u> out of
    winning an argument with you, since your own knowledge of the
    situation is rather incomplete and your good will misguided. As was
    mine.<br>
    <br>
    Regards,<br>
    <br>
    George<br>
  </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 />

--------------070608020809030803020705--

.