------=_Part_2702_454119849.1409109144179
Content-Type: text/plain; charset=UTF-8

Whats missing from the template system is the ability to specify a single
underlying type but templatize on the cv qualifiers and ref qualifiers.
Also possibly number of pointers and array extends (is that useful??).

I have no idea what the syntax would look like, but maybe something awful
like this:

//Creates template overloads for void*, volatile void*, const void*, const
volatile void*
template <const volatile typename T==void*>
bool do_something(T p);

Or maybe some more exotic syntax with a new character:

template <>
bool do_something(void$cv * p);

template <typename T>
bool do_something_else(void$cv * p, T q);

template <>
bool do_something_tricky(void$cv *$cv * dbl_ptr; }

We could also solve the perfect forwarding too many function overloads
problem:

//Implements all 9 of lvalue and rvalue reference overloads for
std::string, real universal reference
void store(std::string$r  first_name, std::string$r last_name,
std::string$r address) {

  do_stuff_with(first_name, last_name, address);

_vec.store(std::forward<std::string$r>(first_name),
std::forward<std::string$r>(last_name),
std::forward<std::string$r>(address));
}

//Template over cv qualifiers, references, pointers, and array extends

template <>
void something_weird(std::string$cvrpa s);

//Templating qualifiers over this
//Implements const and non-const operator[].
template <>
auto& operator[](int index) $c { return _data[index]; }

Another syntax:

template <const C, volatile V, & R, * P, [] A, typename T>
void something_wierd(std::string CVRPA s, T&& x, std::vector<int>CV v);

This kind of thing might be possible with concepts, but will the syntax be
compact enough for very simple and common use cases such as this?
Particularly for perfect forwarding, where this feature might get used a
lot and a bulky syntax would be painful.

The $ syntax is pretty compact, but it also reminds me a perl...

What do you think?

--

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

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

<div dir=3D"ltr">Whats missing from the template system is the ability to s=
pecify a single underlying type but templatize on the cv qualifiers and ref=
 qualifiers. Also possibly number of pointers and array extends (is that us=
eful??).<div><br></div><div>I have no idea what the syntax would look like,=
 but maybe something awful like this:</div><div><br></div><div>//Creates te=
mplate overloads for void*, volatile void*, const void*, const volatile voi=
d*</div><div>template &lt;const volatile typename T=3D=3Dvoid*&gt;</div><di=
v>bool do_something(T p);</div><div><br></div><div>Or maybe some more exoti=
c syntax with a new character:</div><div><br></div><div>template &lt;&gt;</=
div><div>bool do_something(void$cv * p);</div><div><br></div><div>template =
&lt;typename T&gt;</div><div>bool do_something_else(void$cv&nbsp;<span styl=
e=3D"font-size: 13px;">* p, T q);</span></div><div><br></div><div>template =
&lt;&gt;</div><div>bool do_something_tricky(void$cv *$cv * dbl_ptr; }</div>=
<div><br></div><div>We could also solve the perfect forwarding too many fun=
ction overloads problem:</div><div><br></div><div>//Implements all 9 of lva=
lue and rvalue reference overloads for std::string, real universal referenc=
e</div><div>void store(std::string$r &nbsp;first_name, std::string$r last_n=
ame, std::string$r address) {</div><div><br></div><div>&nbsp; do_stuff_with=
(first_name, last_name, address);<br><br></div><div>_vec.store(std::forward=
&lt;std::string$r&gt;(first_name), std::forward&lt;std::string$r&gt;(last_n=
ame), std::forward&lt;std::string$r&gt;(address));</div><div>}</div><div><b=
r></div><div>//Template over cv qualifiers, references, pointers, and array=
 extends</div><div><br></div><div>template &lt;&gt;</div><div>void somethin=
g_weird(std::string$cvrpa s);</div><div><br></div><div>//Templating qualifi=
ers over this</div><div>//Implements const and non-const operator[].</div><=
div>template &lt;&gt;</div><div>auto&amp; operator[](int index) $c { return=
 _data[index]; }&nbsp;</div><div><br></div><div>Another syntax:</div><div><=
br></div><div>template &lt;const C, volatile V, &amp; R, * P, [] A, typenam=
e T&gt;</div><div>void something_wierd(std::string CVRPA s, T&amp;&amp; x, =
std::vector&lt;int&gt;CV v);</div><div><br></div><div>This kind of thing mi=
ght be possible with concepts, but will the syntax be compact enough for ve=
ry simple and common use cases such as this? Particularly for perfect forwa=
rding, where this feature might get used a lot and a bulky syntax would be =
painful.</div><div><br></div><div>The $ syntax is pretty compact, but it al=
so reminds me a perl...</div><div><br></div><div>What do you think?</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_2702_454119849.1409109144179--

.

--Apple-Mail=_E3BFBB56-15A2-475B-911E-371B538D5ADD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-08-27, at 11:12 AM, Matthew Fioravante <fmatthew5876@gmail.com> wro=
te:

> Whats missing from the template system is the ability to specify a single=
 underlying type but templatize on the cv qualifiers and ref qualifiers. Al=
so possibly number of pointers and array extends (is that useful??).
>=20
> I have no idea what the syntax would look like, but maybe something awful=
 like this:
>=20
> //Creates template overloads for void*, volatile void*, const void*, cons=
t volatile void*
> template <const volatile typename T=3D=3Dvoid*>
> bool do_something(T p);

It would be really nice, especially if you could apply it to the implicit t=
his parameter, and furthermore if you could then tell whether the implicit =
object parameter (=A713.3.1/5, the parameter is a reference) was bound to a=
n lvalue or rvalue before it got mangled to a pointer.

I suggest two changes: Don't adjust the type inside the pointer, but let yo=
ur example signature be written do_something( T * p ). And list the desired=
 combinations rather than generating them all.

// generate f( rec & ), f( rec const & ), f( rec && )
template< typename & : const & : && : rec T >
void f( T );=20

// generate f( std::unique_ptr< rec > ), f( std::unique_ptr< rec const > )
template< typename : const : rec T >
void g( std::unique_ptr< T > );

Extend to the implicit argument by assigning such meaning to this used as a=
 template parameter declaration, and also letting decltype(f) be the signat=
ure of the enclosing function template f:

struct s {
    rec mem;

    // generate f() &, f() const &, f() &&
    template< typename & : const & : && : this >
    auto f() -> transfer_qualifiers< decltype(f), rec >
        { return move_if< is_rvalue_qualified< decltype(f) > >( mem ); }
};

> Or maybe some more exotic syntax with a new character:

Be careful interpreting the recent thread. Most current implementations tre=
at the $ character as alphanumeric with nary a warning, so you might want t=
o check that they're willing to let go of it.

> Another syntax:
>=20
> template <const C, volatile V, & R, * P, [] A, typename T>
> void something_wierd(std::string CVRPA s, T&& x, std::vector<int>CV v);

This already has a meaning if C or V are found by unqualified lookup. It wo=
uld be very brittle.

> This kind of thing might be possible with concepts, but will the syntax b=
e compact enough for very simple and common use cases such as this? Particu=
larly for perfect forwarding, where this feature might get used a lot and a=
 bulky syntax would be painful.

Concepts (Lite) are essentially a compact form of SFINAE with broadened app=
licability. Although SFINAE like std::enable_if_t< std::is_same_v< int, std=
::decay_t< T > > > is roughly equivalent, really we want overload set seman=
tics rather than deduction semantics. Implicit conversions should apply.

--=20

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

--Apple-Mail=_E3BFBB56-15A2-475B-911E-371B538D5ADD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08&ndash;27, at 11:12 AM, Matthew Fioravante &lt;<a href=3D"mailto:fm=
atthew5876@gmail.com">fmatthew5876@gmail.com</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">W=
hats missing from the template system is the ability to specify a single un=
derlying type but templatize on the cv qualifiers and ref qualifiers. Also =
possibly number of pointers and array extends (is that useful??).<div><br><=
/div><div>I have no idea what the syntax would look like, but maybe somethi=
ng awful like this:</div><div><br></div><div>//Creates template overloads f=
or void*, volatile void*, const void*, const volatile void*</div><div>templ=
ate &lt;const volatile typename T=3D=3Dvoid*&gt;</div><div>bool do_somethin=
g(T p);</div></div></blockquote><div><br></div><div>It would be really nice=
, especially if you could apply it to the implicit <font face=3D"Courier">t=
his</font> parameter, and furthermore if you could then tell whether the im=
plicit object parameter (=A713.3.1/5, the parameter is a reference) was bou=
nd to an lvalue or rvalue before it got mangled to a pointer.</div><div><br=
></div><div>I suggest two changes: Don&rsquo;t adjust the type inside the p=
ointer, but let your example signature be written <font face=3D"Courier">do=
_something( T * p )</font>. And list the desired combinations rather than g=
enerating them all.</div><div><br></div><div><span style=3D"font-family: Co=
urier;">// generate f( rec &amp; ), f( rec const &amp; ), f(&nbsp;</span><s=
pan style=3D"font-family: Courier;">rec</span><span style=3D"font-family: C=
ourier;">&nbsp;&amp;&amp; )</span></div><div><font face=3D"Courier">templat=
e&lt; typename &amp; : const &amp; : &amp;&amp; :&nbsp;</font><span style=
=3D"font-family: Courier;">rec</span><font face=3D"Courier">&nbsp;T &gt;</f=
ont></div><div><font face=3D"Courier">void f( T );&nbsp;</font></div><div><=
br></div><div><font face=3D"Courier">// generate f( std::unique_ptr&lt;&nbs=
p;</font><span style=3D"font-family: Courier;">rec</span><font face=3D"Cour=
ier">&nbsp;&gt; ),&nbsp;</font><span style=3D"font-family: Courier;">f( std=
::unique_ptr&lt;&nbsp;</span><span style=3D"font-family: Courier;">rec</spa=
n><span style=3D"font-family: Courier;">&nbsp;const &gt; )</span></div><div=
><div><font face=3D"Courier">template&lt; typename : const :&nbsp;</font><s=
pan style=3D"font-family: Courier;">rec</span><font face=3D"Courier">&nbsp;=
T &gt;</font></div><div><font face=3D"Courier">void g( std::unique_ptr&lt; =
T &gt; );</font></div><div><font face=3D"Courier"><br></font></div></div><d=
iv>Extend to the implicit argument by assigning such meaning to <font face=
=3D"Courier">this</font> used as a template parameter declaration, and also=
 letting&nbsp;<font face=3D"Courier">decltype(f)</font>&nbsp;be the signatu=
re of the enclosing function template <font face=3D"Courier">f</font>:</div=
><div><br></div><div><div><font face=3D"Courier">struct s {</font></div><di=
v><font face=3D"Courier">&nbsp; &nbsp; rec mem;</font></div><div><font face=
=3D"Courier"><br></font></div><div><span style=3D"font-family: Courier;">&n=
bsp; &nbsp;</span><span style=3D"font-family: Courier;">&nbsp;</span><font =
face=3D"Courier">// generate f() &amp;, f() const &amp;, f() &amp;&amp;</fo=
nt></div><div><span style=3D"font-family: Courier;">&nbsp; &nbsp;</span><sp=
an style=3D"font-family: Courier;">&nbsp;</span><font face=3D"Courier">temp=
late&lt; typename &amp; : const &amp; : &amp;&amp; : this &gt;</font></div>=
<div><span style=3D"font-family: Courier;">&nbsp; &nbsp;</span><span style=
=3D"font-family: Courier;">&nbsp;</span><font face=3D"Courier">auto f()&nbs=
p;</font><font face=3D"Courier">-&gt; transfer_qualifiers</font><font face=
=3D"Courier">&lt; decltype(f),&nbsp;rec &gt;</font></div><div><span style=
=3D"font-family: Courier;">&nbsp; &nbsp;&nbsp;</span><span style=3D"font-fa=
mily: Courier;">&nbsp; &nbsp;</span><span style=3D"font-family: Courier;">&=
nbsp;</span><span style=3D"font-family: Courier;">{ return move_if&lt; is_r=
value_qualified&lt; decltype(f) &gt; &gt;( mem ); }</span></div><div><font =
face=3D"Courier">};</font></div></div><br><blockquote type=3D"cite"><div di=
r=3D"ltr"><div>Or maybe some more exotic syntax with a new character:</div>=
</div></blockquote><div><br></div><div>Be careful interpreting the recent t=
hread. Most current implementations treat the <font face=3D"Courier">$</fon=
t> character as alphanumeric with nary a warning, so you might want to chec=
k that they&rsquo;re willing to let go of it.</div><br><blockquote type=3D"=
cite"><div dir=3D"ltr"><div>Another syntax:</div><div><br></div><div>templa=
te &lt;const C, volatile V, &amp; R, * P, [] A, typename T&gt;</div><div>vo=
id something_wierd(std::string CVRPA s, T&amp;&amp; x, std::vector&lt;int&g=
t;CV v);</div></div></blockquote><div><br></div><div>This already has a mea=
ning if C or V are found by unqualified lookup. It would be very brittle.</=
div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>This kind of thing =
might be possible with concepts, but will the syntax be compact enough for =
very simple and common use cases such as this? Particularly for perfect for=
warding, where this feature might get used a lot and a bulky syntax would b=
e painful.</div></div></blockquote><div><br></div><div>Concepts (Lite) are =
essentially a compact form of SFINAE with broadened applicability. Although=
 SFINAE like <font face=3D"Courier">std::enable_if_t&lt; std::is_same_v&lt;=
 int, std::decay_t&lt; T &gt; &gt; &gt;</font>&nbsp;is roughly equivalent, =
really we want overload set semantics rather than deduction semantics. Impl=
icit conversions should apply.</div></div><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 />

--Apple-Mail=_E3BFBB56-15A2-475B-911E-371B538D5ADD--

.

On Wed, Aug 27, 2014 at 3:22 AM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9308=E2=80=9327, at 11:12 AM, Matthew Fioravante <fmatthew5=
876@gmail.com>
> wrote:
>
> Whats missing from the template system is the ability to specify a single
> underlying type but templatize on the cv qualifiers and ref qualifiers. A=
lso
> possibly number of pointers and array extends (is that useful??).
>
> I have no idea what the syntax would look like, but maybe something awful
> like this:
>
> //Creates template overloads for void*, volatile void*, const void*, cons=
t
> volatile void*
> template <const volatile typename T=3D=3Dvoid*>
> bool do_something(T p);
>
>
> It would be really nice, especially if you could apply it to the implicit
> this parameter, and furthermore if you could then tell whether the implic=
it
> object parameter (=C2=A713.3.1/5, the parameter is a reference) was bound=
 to an
> lvalue or rvalue before it got mangled to a pointer.

Not sure if it applies to this: how would this example be implemented?

struct S
{
    int x;

    int& getX() { return x; }
    int getX() const { return x; }
};

when the body is the same, how could this help to write the method only onc=
e?

>
> I suggest two changes: Don=E2=80=99t adjust the type inside the pointer, =
but let
> your example signature be written do_something( T * p ). And list the
> desired combinations rather than generating them all.
>
> // generate f( rec & ), f( rec const & ), f( rec && )
> template< typename & : const & : && : rec T >
> void f( T );
>
> // generate f( std::unique_ptr< rec > ), f( std::unique_ptr< rec const > =
)
> template< typename : const : rec T >
> void g( std::unique_ptr< T > );
>
> Extend to the implicit argument by assigning such meaning to this used as=
 a
> template parameter declaration, and also letting decltype(f) be the
> signature of the enclosing function template f:
>
> struct s {
>     rec mem;
>
>     // generate f() &, f() const &, f() &&
>     template< typename & : const & : && : this >
>     auto f() -> transfer_qualifiers< decltype(f), rec >
>         { return move_if< is_rvalue_qualified< decltype(f) > >( mem ); }
> };
>
> Or maybe some more exotic syntax with a new character:
>
>
> Be careful interpreting the recent thread. Most current implementations
> treat the $ character as alphanumeric with nary a warning, so you might w=
ant
> to check that they=E2=80=99re willing to let go of it.
>
> Another syntax:
>
> template <const C, volatile V, & R, * P, [] A, typename T>
> void something_wierd(std::string CVRPA s, T&& x, std::vector<int>CV v);
>
>
> This already has a meaning if C or V are found by unqualified lookup. It
> would be very brittle.
>
> This kind of thing might be possible with concepts, but will the syntax b=
e
> compact enough for very simple and common use cases such as this?
> Particularly for perfect forwarding, where this feature might get used a =
lot
> and a bulky syntax would be painful.
>
>
> Concepts (Lite) are essentially a compact form of SFINAE with broadened
> applicability. Although SFINAE like std::enable_if_t< std::is_same_v< int=
,
> std::decay_t< T > > > is roughly equivalent, really we want overload set
> semantics rather than deduction semantics. Implicit conversions should
> apply.
>
> --
>
> ---
> 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
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

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



On Wednesday, August 27, 2014 2:48:34 PM UTC-4, dgutson wrote:
>
>
> Not sure if it applies to this: how would this example be implemented?
>
> struct S
> {
>     int x;
>
>     int& getX() { return x; }
>     int getX() const { return x; }
> };
>
> when the body is the same, how could this help to write the method only
> once?
>
>
I'm not sure that would be possible. Maybe with some ugly template
conditionals.

Something like

template <>
typename
std::conditional<std::is_const<decltype(this)>::value,int,int&>::type
getX() $c { return x; }

But in my opinion that's more ugly and unreadable than the 2 separate
overloads.

--

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

<div dir=3D"ltr"><br><br>On Wednesday, August 27, 2014 2:48:34 PM UTC-4, dg=
utson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Not sure if it=
 applies to this: how would this example be implemented?
<br>
<br>struct S
<br>{
<br>&nbsp; &nbsp; int x;
<br>
<br>&nbsp; &nbsp; int&amp; getX() { return x; }
<br>&nbsp; &nbsp; int getX() const { return x; }
<br>};
<br>
<br>when the body is the same, how could this help to write the method only=
 once?
<br><br></blockquote><div><br></div><div>I'm not sure that would be possibl=
e. Maybe with some ugly template conditionals.</div><div><br></div><div>Som=
ething like</div><div><br></div><div>template &lt;&gt;</div><div>typename s=
td::conditional&lt;std::is_const&lt;decltype(this)&gt;::value,int,int&amp;&=
gt;::type getX() $c { return x; }</div><div><br></div><div>But in my opinio=
n that's more ugly and unreadable than the 2 separate overloads.</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_22_202570427.1409188095404--

.

--Apple-Mail=_41ED8572-170F-4C93-9B18-E311827DED40
Content-Type: text/plain; charset=ISO-8859-1


On 2014-08-28, at 2:48 AM, dgutson . <danielgutson@gmail.com> wrote:

> Not sure if it applies to this: how would this example be implemented?

It's a perfect example.

> struct S
> {
>    int x;
>
>    int& getX() { return x; }
>    int getX() const { return x; }
> };
>
> when the body is the same, how could this help to write the method only once?

As Matthew said, there needs to be some metaprocessing logic to transfer the const qualification to forming a reference type. You wouldn't write std::conditional every time, though.

struct S {
int x;

template< typename : const : this >
auto getX() -> value_if_const< decltype(getX), int & >
{ return x; }
};

There should be standard library facilities to accompany such a feature, to make the common cases painless.

Why should that accessor return by value instead of const reference? Returns by value are useful for rvalue qualified overloads, as rvalues tend to represent value-semantic expressions. But an rvalue object expression would still select the int& accessor.


On 2014-08-28, at 9:08 AM, Matthew Fioravante <fmatthew5876@gmail.com> wrote:

> But in my opinion that's more ugly and unreadable than the 2 separate overloads.

The problem is that these days, we often need more than two. And accessors tend to run in herds.

Copy-paste leads to errors of omission.

My illustration above is still a bit ugly. I don't think it's all ready for proposal quite yet. But it's a problem worth solving.

--

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

--Apple-Mail=_41ED8572-170F-4C93-9B18-E311827DED40
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08&ndash;28, at 2:48 AM, dgutson . &lt;<a href=3D"mailto:danielgutson=
@gmail.com">danielgutson@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-i=
nterchange-newline"><blockquote type=3D"cite"><div style=3D"font-size: 12px=
; font-style: normal; font-variant: normal; font-weight: normal; letter-spa=
cing: normal; line-height: normal; orphans: auto; text-align: start; text-i=
ndent: 0px; text-transform: none; white-space: normal; widows: auto; word-s=
pacing: 0px; -webkit-text-stroke-width: 0px;">Not sure if it applies to thi=
s: how would this example be implemented?<br></div></blockquote><div><br></=
div><div>It&rsquo;s a perfect example.</div><br><blockquote type=3D"cite"><=
div style=3D"font-size: 12px; font-style: normal; font-variant: normal; fon=
t-weight: normal; letter-spacing: normal; line-height: normal; orphans: aut=
o; text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">s=
truct S<br>{<br>&nbsp;&nbsp;&nbsp;int x;<br><br>&nbsp;&nbsp;&nbsp;int&amp; =
getX() { return x; }<br>&nbsp;&nbsp;&nbsp;int getX() const { return x; }<br=
>};<br><br>when the body is the same, how could this help to write the meth=
od only once?<br></div></blockquote><div><br></div><div>As Matthew said, th=
ere needs to be some metaprocessing logic to transfer the const qualificati=
on to forming a reference type. You wouldn&rsquo;t write <font face=3D"Cour=
ier">std::conditional</font> every time, though.</div><div><br></div><div><=
font face=3D"Courier">struct S {</font></div><div><font face=3D"Courier">in=
t x;</font></div><div><font face=3D"Courier"><br></font></div><div><font fa=
ce=3D"Courier">template&lt; typename : const : this &gt;</font></div><div><=
font face=3D"Courier">auto getX() -&gt; value_if_const&lt; decltype(getX), =
int &amp; &gt;</font></div><div><font face=3D"Courier">{ return x; }</font>=
</div><div><font face=3D"Courier">};</font></div><div><br></div><div>There =
should be standard library facilities to accompany such a feature, to make =
the common cases painless.</div><div><br></div><div>Why should that accesso=
r return by value instead of const reference? Returns by value are useful f=
or rvalue qualified overloads, as rvalues tend to represent value-semantic =
expressions. But an rvalue object expression would still select the <font f=
ace=3D"Courier">int&amp;</font> accessor.</div><div><br></div><div><br></di=
v><div><div>On 2014&ndash;08&ndash;28, at 9:08 AM, Matthew Fioravante &lt;<=
a href=3D"mailto:fmatthew5876@gmail.com">fmatthew5876@gmail.com</a>&gt; wro=
te:</div><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">=
<div dir=3D"ltr">But in my opinion that's more ugly and unreadable than the=
 2 separate overloads.</div></blockquote><div><div dir=3D"ltr"><br></div></=
div><div dir=3D"ltr">The problem is that these days, we often need more tha=
n two. And accessors tend to run in herds.</div><div dir=3D"ltr"><br></div>=
<div dir=3D"ltr">Copy-paste leads to errors of omission.</div><div dir=3D"l=
tr"><br></div><div dir=3D"ltr">My illustration above is still a bit ugly. I=
 don&rsquo;t think it&rsquo;s all ready for proposal quite yet. But it&rsqu=
o;s a problem worth solving.</div><div dir=3D"ltr"><br></div></div></div></=
body></html>

<p></p>

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

--Apple-Mail=_41ED8572-170F-4C93-9B18-E311827DED40--

.

------=_Part_1078_247808642.1409363532146
Content-Type: text/plain; charset=UTF-8

Another thing this syntax could enable is creating a variadic function
which takes a variable number of objects of the same type:

template <typename... : std::string T>
std::string concat(T&&...);

Similarly for class templates.

--

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

<div dir=3D"ltr">Another thing this syntax could enable is creating a varia=
dic function which takes a variable number of objects of the same type:<div=
><br></div><div>template &lt;typename... : std::string T&gt;</div><div>std:=
:string concat(T&amp;&amp;...);</div><div><br></div><div>Similarly for clas=
s templates.</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_1078_247808642.1409363532146--

.

--Apple-Mail=_AA7C4DEC-C4A0-47D4-A6F7-66D368E9EB41
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-08-30, at 9:52 AM, Matthew Fioravante <fmatthew5876@gmail.com> wrot=
e:

> Another thing this syntax could enable is creating a variadic function wh=
ich takes a variable number of objects of the same type:
>=20
> template <typename... : std::string T>
> std::string concat(T&&...);
>=20
> Similarly for class templates.

It's worth mentioning the already-proposed bracket syntax:

std::string concat( std::string ...[] );

Your example implements the reference collapsing part of perfect forwarding=
 without type deduction, which is nice. The template keyword might be seen =
as noise, but it's also exposition that the declaration is a template. The =
immediate declaration T&& is a little obfuscated, but the user can (and sho=
uld) just use a better identifier:

template <typename... : std::string fwd_string>
std::string concat(fwd_string&&...);

=3D=3D=3D=3D=3D=3D

Another case for typename this is when a base class method wants to know th=
e static type of the object it was invoked on. Currently this requires a fr=
iend and/or static member. Access qualification is an issue when this isn't=
 the type of the enclosing class, but I think it should be handled the same=
 as any derived object in a static member function. (Also, inline friends s=
hould have the same access as static members, but there's currently impleme=
ntation variance on that point.)

--=20

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

--Apple-Mail=_AA7C4DEC-C4A0-47D4-A6F7-66D368E9EB41
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08&ndash;30, at 9:52 AM, Matthew Fioravante &lt;<a href=3D"mailto:fma=
tthew5876@gmail.com">fmatthew5876@gmail.com</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">A=
nother thing this syntax could enable is creating a variadic function which=
 takes a variable number of objects of the same type:<div><br></div><div>te=
mplate &lt;typename... : std::string T&gt;</div><div>std::string concat(T&a=
mp;&amp;...);</div><div><br></div><div>Similarly for class templates.</div>=
</div></blockquote><div><br></div><div>It&rsquo;s worth mentioning the alre=
ady-proposed bracket syntax:</div><div><br></div><div><font face=3D"Courier=
">std::string concat( std::string &hellip;[] );<br></font><br></div><div>Yo=
ur example implements the reference collapsing part of perfect forwarding w=
ithout type deduction, which is nice. The template keyword might be seen as=
 noise, but it&rsquo;s also exposition that the declaration is a template. =
The immediate declaration <font face=3D"Courier">T&amp;&amp;</font> is a li=
ttle obfuscated, but the user can (and should) just use a better identifier=
:</div><div><br></div><div><font face=3D"Courier">template &lt;typename... =
: std::string fwd_string&gt;<br>std::string concat(fwd_string&amp;&amp;...)=
;<br></font><br></div><div>=3D=3D=3D=3D=3D=3D</div><div><br></div><div>Anot=
her case for <font face=3D"Courier">typename this</font>&nbsp;is when a bas=
e class method wants to know the static type of the object it was invoked o=
n. Currently this requires a <font face=3D"Courier">friend</font>&nbsp;and/=
or <font face=3D"Courier">static</font> member. Access qualification is an =
issue when <font face=3D"Courier">this</font> isn&rsquo;t the type of the e=
nclosing class, but I think it should be handled the same as any derived ob=
ject in a static member function. (Also, inline friends should have the sam=
e access as static members, but there&rsquo;s currently implementation vari=
ance on that point.)</div><div><br></div></div></body></html>

<p></p>

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

--Apple-Mail=_AA7C4DEC-C4A0-47D4-A6F7-66D368E9EB41--

.

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



On Friday, August 29, 2014 10:33:56 PM UTC-4, David Krauss wrote:
>
>
>
> It=E2=80=99s worth mentioning the already-proposed bracket syntax:
>
> std::string concat( std::string =E2=80=A6[] );
>

Nice, I didn't know about that. Is this a written proposal or just an idea=
=20
someone floated on this forum?

I think this thing could actually be implemented not as a template but=20
instead as an array of runtime size (wow the first actual use case I've=20
been able to find for those!). The ABI can easily put an extra argument on=
=20
the stack which is the number of strings passed. Then its more like a C=20
style varargs, without type safety problems. In which case it would have a=
=20
lot of value existing along side of a template solution because there would=
=20
only be 1 function (which could be hidden inside a separate translation=20
unit like normal functions).

>
> Your example implements the reference collapsing part of perfect=20
> forwarding without type deduction, which is nice.=20
>

This could also be a shorthand for the 3 string example from earlier. I=20
like your proposed syntax the most but its wordy for the 3 string example.

Consider:

template <typename : std::string s1, typename : std::string s2, typename :=
=20
std::string s3>
void foo(s1&& first_name, s2&& last_name, s3&& address);

template <typename const & : && : std::string s1, typename const & : && :=
=20
std::string s2, typename const & : && std::string s3>
void foo(s1 first_name, s2 last_name, s3 address);

The "universal reference" comes with code bloat however. It will provide 18=
=20
overloads ( &, const &, &&, const && (likely not compile)). In most cases=
=20
when your intention is just to template whether to copy or move, the &=20
overload is superfluous (it would be perfectly valid to convert to const &)=
=20
and becomes template code bloat.
=20

> The template keyword might be seen as noise, but it=E2=80=99s also exposi=
tion that=20
> the declaration is a template.=20
>

I think anything that's a template, no matter what fancy shorthand syntax=
=20
it uses should at minimum have a template <> tag in front of it. Its more=
=20
typing but it means that anything that's a template is clearly spelled out.=
=20
Otherwise we have rules saying that something is a template if it has=20
template <> syntax except when... C++ already has too much of  "except=20
when" in the rules
=20

> The immediate declaration T&& is a little obfuscated, but the user can=20
> (and should) just use a better identifier:
>
> template <typename... : std::string fwd_string>
> std::string concat(fwd_string&&...);
>

Indeed, that should be recommended practice.
=20

>
> =3D=3D=3D=3D=3D=3D
>
> Another case for typename this is when a base class method wants to know=
=20
> the static type of the object it was invoked on. Currently this requires =
a=20
> friend and/or static member. Access qualification is an issue when this=
=20
> isn=E2=80=99t the type of the enclosing class, but I think it should be h=
andled the=20
> same as any derived object in a static member function. (Also, inline=20
> friends should have the same access as static members, but there=E2=80=99=
s=20
> currently implementation variance on that point.)
>
>
Another use case. There is a lot of fruit to be picked from this tree for=
=20
sure.=20


Here is another possibility, although it may be stepping on concepts turf.

template <typename : std::is_integral<T>::value T>
int count_trailing_0_bits(T x);


Perhaps sketching out a proposal to collect all of these use cases and=20
possibilities is not a bad idea.

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

<div dir=3D"ltr"><br><br>On Friday, August 29, 2014 10:33:56 PM UTC-4, Davi=
d Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"w=
ord-wrap:break-word"><br><div><div><br></div><div>It=E2=80=99s worth mentio=
ning the already-proposed bracket syntax:</div><div><br></div><div><font fa=
ce=3D"Courier">std::string concat( std::string =E2=80=A6[] );<br></font></d=
iv></div></div></blockquote><div><br></div><div>Nice, I didn't know about t=
hat. Is this a written proposal or just an idea someone floated on this for=
um?</div><div><br></div><div>I think this thing could actually be implement=
ed not as a template but instead as an array of runtime size (wow the first=
 actual use case I've been able to find for those!). The ABI can easily put=
 an extra argument on the stack which is the number of strings passed. Then=
 its more like a C style varargs, without type safety problems. In which ca=
se it would have a lot of value existing along side of a template solution =
because there would only be 1 function (which could be hidden inside a sepa=
rate translation unit like normal functions).</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div><div><font fa=
ce=3D"Courier"></font><br></div><div>Your example implements the reference =
collapsing part of perfect forwarding without type deduction, which is nice=
.. </div></div></div></blockquote><div><br></div><div>This could also be a s=
horthand for the 3 string example from earlier. I like your proposed syntax=
 the most but its wordy for the 3 string example.</div><div><br></div><div>=
Consider:</div><div><br></div><div>template &lt;typename : std::string s1, =
typename : std::string s2, typename : std::string s3&gt;</div><div>void foo=
(s1&amp;&amp; first_name, s2&amp;&amp; last_name, s3&amp;&amp; address);</d=
iv><div><br></div><div>template &lt;typename const &amp; : &amp;&amp; : std=
::string s1, typename const &amp; : &amp;&amp; : std::string s2, typename c=
onst &amp; : &amp;&amp; std::string s3&gt;</div><div>void foo(s1 first_name=
, s2 last_name, s3 address);</div><div><br></div><div>The "universal refere=
nce" comes with code bloat however. It will provide 18 overloads ( &amp;, c=
onst &amp;, &amp;&amp;, const &amp;&amp; (likely not compile)). In most cas=
es when your intention is just to template whether to copy or move, the &am=
p; overload is superfluous (it would be perfectly valid to convert to const=
 &amp;) and becomes template code bloat.</div><div>&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div><=
div>The template keyword might be seen as noise, but it=E2=80=99s also expo=
sition that the declaration is a template. </div></div></div></blockquote><=
div><br></div><div>I think anything that's a template, no matter what fancy=
 shorthand syntax it uses should at minimum have a template &lt;&gt; tag in=
 front of it. Its more typing but it means that anything that's a template =
is clearly spelled out. Otherwise we have rules saying that something is a =
template if it has template &lt;&gt; syntax except when... C++ already has =
too much of &nbsp;"except when" in the rules</div><div>&nbsp;</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><d=
iv><div>The immediate declaration <font face=3D"Courier">T&amp;&amp;</font>=
 is a little obfuscated, but the user can (and should) just use a better id=
entifier:</div><div><br></div><div><font face=3D"Courier">template &lt;type=
name... : std::string fwd_string&gt;<br>std::string concat(fwd_string&amp;&=
amp;...);<br></font></div></div></div></blockquote><div><br></div><div>Inde=
ed, that should be recommended practice.</div><div>&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div><=
div><font face=3D"Courier"></font><br></div><div>=3D=3D=3D=3D=3D=3D</div><d=
iv><br></div><div>Another case for <font face=3D"Courier">typename this</fo=
nt>&nbsp;is when a base class method wants to know the static type of the o=
bject it was invoked on. Currently this requires a <font face=3D"Courier">f=
riend</font>&nbsp;and/or <font face=3D"Courier">static</font> member. Acces=
s qualification is an issue when <font face=3D"Courier">this</font> isn=E2=
=80=99t the type of the enclosing class, but I think it should be handled t=
he same as any derived object in a static member function. (Also, inline fr=
iends should have the same access as static members, but there=E2=80=99s cu=
rrently implementation variance on that point.)</div><div><br></div></div><=
/div></blockquote><div><br></div><div>Another use case. There is a lot of f=
ruit to be picked from this tree for sure.&nbsp;</div><div><br></div><div><=
br></div><div>Here is another possibility, although it may be stepping on c=
oncepts turf.</div><div><br></div><div>template &lt;typename : std::is_inte=
gral&lt;T&gt;::value T&gt;</div><div>int count_trailing_0_bits(T x);</div><=
div><br></div><div><br></div><div>Perhaps sketching out a proposal to colle=
ct all of these use cases and possibilities is not a bad idea.<br></div></d=
iv>

<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_1156_777258756.1409382194737--

.

--Apple-Mail=_6EBB1240-0CA2-4FE0-AEB9-EDED698C1D77
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-08-30, at 3:03 PM, Matthew Fioravante <fmatthew5876@gmail.com> wrot=
e:

>=20
>=20
> On Friday, August 29, 2014 10:33:56 PM UTC-4, David Krauss wrote:
> std::string concat( std::string ...[] );
>=20
> Nice, I didn't know about that. Is this a written proposal or just an ide=
a someone floated on this forum?

I seem to recall an official proposal.

> I think this thing could actually be implemented not as a template but in=
stead as an array of runtime size (wow the first actual use case I've been =
able to find for those!). The ABI can easily put an extra argument on the s=
tack which is the number of strings passed. Then its more like a C style va=
rargs, without type safety problems.

That would just be an initializer_list. ;v)

> The "universal reference" comes with code bloat however. It will provide =
18 overloads ( &, const &, &&, const && (likely not compile)). In most case=
s when your intention is just to template whether to copy or move, the & ov=
erload is superfluous (it would be perfectly valid to convert to const &) a=
nd becomes template code bloat.

Code bloat is always a potential issue. But you have a choice between non-d=
educed perfect forwarding:

template <typename... : std::string fwd_string>
std::string concat( fwd_string&& ... );

Explicit, imperfect reference overload generation excluding the superfluous=
 case:

template <typename... const & : && : std::string ref_string>
std::string concat( ref_string ... );

Or not using references at all:

template <typename... : std::string value_string>
std::string concat( value_string ... );

> Here is another possibility, although it may be stepping on concepts turf=
..
>=20
> template <typename : std::is_integral<T>::value T>
> int count_trailing_0_bits(T x);

I don't get how to parse this. It looks like T was used before declaration.

> Perhaps sketching out a proposal to collect all of these use cases and po=
ssibilities is not a bad idea.

Feel free... I'm still drafting inline variables, category-qualified classe=
s, and constexpr numerics. And then there's backlog.

--=20

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

--Apple-Mail=_6EBB1240-0CA2-4FE0-AEB9-EDED698C1D77
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08&ndash;30, at 3:03 PM, Matthew Fioravante &lt;<a href=3D"mailto:fma=
tthew5876@gmail.com">fmatthew5876@gmail.com</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><=
br><br>On Friday, August 29, 2014 10:33:56 PM UTC-4, David Krauss wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-l=
eft-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: s=
olid; padding-left: 1ex; position: static; z-index: auto;"><div style=3D"wo=
rd-wrap:break-word"><div><div><font face=3D"Courier">std::string concat( st=
d::string &hellip;[] );<br></font></div></div></div></blockquote><div><br><=
/div><div>Nice, I didn't know about that. Is this a written proposal or jus=
t an idea someone floated on this forum?</div></div></blockquote><div><br><=
/div><div>I seem to recall an official proposal.</div><br><blockquote type=
=3D"cite"><div dir=3D"ltr"><div>I think this thing could actually be implem=
ented not as a template but instead as an array of runtime size (wow the fi=
rst actual use case I've been able to find for those!). The ABI can easily =
put an extra argument on the stack which is the number of strings passed. T=
hen its more like a C style varargs, without type safety problems. </div></=
div></blockquote><div><br></div><div>That would just be an&nbsp;<font face=
=3D"Courier">initializer_list</font>. ;v)</div><br><blockquote type=3D"cite=
"><div dir=3D"ltr"><div>The "universal reference" comes with code bloat how=
ever. It will provide 18 overloads ( &amp;, const &amp;, &amp;&amp;, const =
&amp;&amp; (likely not compile)). In most cases when your intention is just=
 to template whether to copy or move, the &amp; overload is superfluous (it=
 would be perfectly valid to convert to const &amp;) and becomes template c=
ode bloat.</div></div></blockquote><div><br></div><div>Code bloat is always=
 a potential issue. But you have a choice between non-deduced perfect forwa=
rding:</div><div><br></div><font face=3D"Courier">template &lt;typename... =
: std::string fwd_string&gt;<br>std::string concat( fwd_string&amp;&amp; ..=
.. );</font></div><div><br></div><div>Explicit, imperfect reference overload=
 generation excluding the superfluous case:</div><div><br></div><div><div><=
font face=3D"Courier">template &lt;typename... const &amp; : &amp;&amp; : s=
td::string ref_string&gt;<br>std::string concat( ref_string&nbsp;</font><sp=
an style=3D"font-family: Courier;">...</span><font face=3D"Courier">&nbsp;)=
;</font></div><div><br></div><div>Or not using references at all:</div><div=
><br></div><div><div><font face=3D"Courier">template &lt;typename... : std:=
:string value_string&gt;<br>std::string concat( value_string&nbsp;</font><s=
pan style=3D"font-family: Courier;">...</span><font face=3D"Courier">&nbsp;=
);</font></div><div><br></div></div><blockquote type=3D"cite"><div dir=3D"l=
tr"><div>Here is another possibility, although it may be stepping on concep=
ts turf.</div><div><br></div><div>template &lt;typename : std::is_integral&=
lt;T&gt;::value T&gt;</div><div>int count_trailing_0_bits(T x);</div></div>=
</blockquote><div><br></div>I don&rsquo;t get how to parse this. It looks l=
ike T was used before declaration.</div><div><br><blockquote type=3D"cite">=
<div dir=3D"ltr"><div>Perhaps sketching out a proposal to collect all of th=
ese use cases and possibilities is not a bad idea.</div></div></blockquote>=
</div><br><div>Feel free&hellip; I&rsquo;m still drafting inline variables,=
 category-qualified classes, and constexpr numerics. And then there&rsquo;s=
 backlog.</div><div><br></div></body></html>

<p></p>

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

--Apple-Mail=_6EBB1240-0CA2-4FE0-AEB9-EDED698C1D77--

.

--Apple-Mail=_A1D28909-0CFD-4080-AD4F-376A09567BDA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-08-30, at 3:36 PM, David Krauss <potswa@gmail.com> wrote:

> non-deduced perfect forwarding:
>=20
> template <typename... : std::string fwd_string>
> std::string concat( fwd_string&& ... );
>=20
> Explicit, imperfect reference overload generation excluding the superfluo=
us case:
>=20
> template <typename... const & : && : std::string ref_string>
> std::string concat( ref_string ... );

Actually, I'm not sure that the first case should map to perfect forwarding=
 at all. It looks more like formation of a simple rvalue reference. An exte=
nsion that elaborates overloads as opposed to template argument deduction m=
aybe shouldn't touch or emulate perfect forwarding.

--=20

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

--Apple-Mail=_A1D28909-0CFD-4080-AD4F-376A09567BDA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08&ndash;30, at 3:36 PM, David Krauss &lt;<a href=3D"mailto:potswa@gm=
ail.com">potswa@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchang=
e-newline"><blockquote type=3D"cite"><meta http-equiv=3D"Content-Type" cont=
ent=3D"text/html charset=3Dwindows-1252"><div style=3D"word-wrap: break-wor=
d; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">non-de=
duced perfect forwarding:<br><div><div><br></div><font face=3D"Courier">tem=
plate &lt;typename... : std::string fwd_string&gt;<br>std::string concat( f=
wd_string&amp;&amp; ... );</font></div><div><br></div><div>Explicit, imperf=
ect reference overload generation excluding the superfluous case:</div><div=
><br></div><div><div><font face=3D"Courier">template &lt;typename... const =
&amp; : &amp;&amp; : std::string ref_string&gt;<br>std::string concat( ref_=
string&nbsp;</font><span style=3D"font-family: Courier;">...</span><font fa=
ce=3D"Courier">&nbsp;);</font></div></div></div></blockquote><br></div><div=
>Actually, I&rsquo;m not sure that the first case should map to perfect for=
warding at all. It looks more like formation of a simple rvalue reference. =
An extension that elaborates overloads as opposed to template argument dedu=
ction maybe shouldn&rsquo;t touch or emulate perfect forwarding.</div><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 />

--Apple-Mail=_A1D28909-0CFD-4080-AD4F-376A09567BDA--

.

This is a multi-part message in MIME format.
--------------010905010300040105040707
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


On 08/30/2014 05:33 AM, David Krauss wrote:
>
> On 2014--08--30, at 9:52 AM, Matthew Fioravante
> <fmatthew5876@gmail.com <mailto:fmatthew5876@gmail.com>> wrote:
>
>> Another thing this syntax could enable is creating a variadic
>> function which takes a variable number of objects of the same type:
>>
>> template <typename... : std::string T>
>> std::string concat(T&&...);
>>
>> Similarly for class templates.
>
> It's worth mentioning the already-proposed bracket syntax:
>
> std::string concat( std::string ...[] );
>
>

For the record, according to work I am currently doing at
https://github.com/irrequietus/atpp this case was implicit already in
the annotated template parameter pack semantics draft since its June
2014 revision. I will explain what I mean with an example respecting
those semantics, that wasn't made explicit in the draft:

template<typename ...T{}[sizeof...(T)]>
void somefun(T...) { /* */ }

Essentially due to the '{}[sizeof...(T)]' "annotation" following the
pack identifier T, pack is forced to have all parameters to be of the
same type. In the example above {} is a "size indicating annotator"
whose implicit value is sizeof...(T) in our case while the [K] following
it is a "pattern/tuple annotator" guaranteeing that the parameter pack
is an exact "any"-tuple of a parameter pack comprised of the first
sizeof...(T)/K parameters. Again, this was implicit in previous drafts
of the ongoing work but was not in a direct example.

What happens when K = sizeof...(T) ? simply put, the entire pack must be
comprised of any sizeof...(T)/sizeof...(T) = "1-tuple" packs repeated in
order, meaning /*it must be made out of the repetition of the type
acting as the "head" of the pack.*/ This is the effect you are trying to
propose with template qualifiers in this example and annotated template
parameter packs actually cover it. There are also other creative ways
that the syntax in annotated template parameter packs can be used to
provide full "qualification", but I digress.

This is just so that you know that a certain terse and unambiguous
syntax (unlike typename ... [] for "fixed packs", even missed by certain
expert minds) in "annotated template parameter packs" was actually
covering this case of "template qualification". Also, you made me fix an
obvious editing error in a syntax table of the draft in the repository
and provide evidence to its justified correction from previous revisions
that described these semantics, so big thanks to you all.

It is important to understand that any addition to the template system
must be rigorous and it is not just a "let's see what happens when we
add this syntax", if I haven't been clear enough. If somebody wants to
add size annotation and "template qualifiers", they will be finding
annotated template parameter packs a very interesting read - especially
once it is finished.

Some people missed the memo on quite a few stuff back then.

As for concepts, they lack pack generative features and only focus on
some aspects of giving C++ "better" bounded polymorphism over the hacks
that SFINAE is used for. As a friendly note, what the EWG is unable to
process, tags it as "let's do it with concepts" (_/or worse/_), so every
proposal doing something that _/is considered overlapping with concepts
for no real technical reason/_, must address them for what they are
actually are. This includes the "template qualifiers" idea if it wishes
to have any future.

More things to come in due time.

So long,

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

--------------010905010300040105040707
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 08/30/2014 05:33 AM, David Krauss
      wrote:<br>
    </div>
    <blockquote
      cite="mid:CB5D0646-0B3C-4BAC-AEBE-355C497C2995@gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <br>
      <div>
        <div>On 2014&#8211;08&#8211;30, at 9:52 AM, Matthew Fioravante &lt;<a
            moz-do-not-send="true" href="mailto:fmatthew5876@gmail.com">fmatthew5876@gmail.com</a>&gt;
          wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <div dir="ltr">Another thing this syntax could enable is
            creating a variadic function which takes a variable number
            of objects of the same type:
            <div><br>
            </div>
            <div>template &lt;typename... : std::string T&gt;</div>
            <div>std::string concat(T&amp;&amp;...);</div>
            <div><br>
            </div>
            <div>Similarly for class templates.</div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>It&#8217;s worth mentioning the already-proposed bracket syntax:</div>
        <div><br>
        </div>
        <div><font face="Courier">std::string concat( std::string &#8230;[] );<br>
          </font><br>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    For the record, according to work I am currently doing at <a
      href="https://github.com/irrequietus/atpp">https://github.com/irrequietus/atpp</a>
    this case was implicit already in the annotated template parameter
    pack semantics draft since its June 2014 revision. I will explain
    what I mean with an example respecting those semantics, that wasn't
    made explicit in the draft:<br>
    <br>
    template&lt;typename ...T{}[sizeof...(T)]&gt;<br>
    void somefun(T...) { /* */ }<br>
    <br>
    Essentially due to the '{}[sizeof...(T)]' "annotation" following the
    pack identifier T, pack is forced to have all parameters to be of
    the same type. In the example above {} is a "size indicating
    annotator" whose implicit value is sizeof...(T) in our case while
    the [K] following it is a "pattern/tuple annotator" guaranteeing
    that the parameter pack is an exact "any"-tuple of a parameter pack
    comprised of the first sizeof...(T)/K parameters. Again, this was
    implicit in previous drafts of the ongoing work but was not in a
    direct example.<br>
    <br>
    What happens when K = sizeof...(T) ? simply put, the entire pack
    must be comprised of any sizeof...(T)/sizeof...(T) = "1-tuple" packs
    repeated in order, meaning <i><b>it must be made out of the
        repetition of the type acting as the "head" of the pack.</b></i>
    This is the effect you are trying to propose with template
    qualifiers in this example and annotated template parameter packs
    actually cover it. There are also other creative ways that the
    syntax in annotated template parameter packs can be used to provide
    full "qualification", but I digress.<br>
    <br>
    This is just so that you know that a certain terse and unambiguous
    syntax (unlike typename ... [] for "fixed packs", even missed by
    certain expert minds) in "annotated template parameter packs" was
    actually covering this case of "template qualification". Also, you
    made me fix an obvious editing error in a syntax table of the draft
    in the repository and provide evidence to its justified correction
    from previous revisions that described these semantics, so big
    thanks to you all.<br>
    <br>
    It is important to understand that any addition to the template
    system must be rigorous and it is not just a "let's see what happens
    when we add this syntax", if I haven't been clear enough. If
    somebody wants to add size annotation and "template qualifiers",
    they will be finding annotated template parameter packs a very
    interesting read - especially once it is finished.<br>
    <br>
    Some people missed the memo on quite a few stuff back then.<br>
    <br>
    As for concepts, they lack pack generative features and only focus
    on some aspects of giving C++ "better" bounded polymorphism over the
    hacks that SFINAE is used for. As a friendly note, what the EWG is
    unable to process, tags it as "let's do it with concepts" (<u><i>or
        worse</i></u>), so every proposal doing something that <u><i>is
        considered overlapping with concepts for no real technical
        reason</i></u>, must address them for what they are actually
    are. This includes the "template qualifiers" idea if it wishes to
    have any future.<br>
    <br>
    More things to come in due time.<br>
    <br>
    So long,<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 />

--------------010905010300040105040707--

.