------=_Part_3682_680518006.1480921851145
Content-Type: multipart/alternative;
 boundary="----=_Part_3683_314418435.1480921851146"

------=_Part_3683_314418435.1480921851146
Content-Type: text/plain; charset=UTF-8

What if there were an additional parameter list allowed for defining custom
literals, specifically:

template< typename ...Args > <return_type> operator ""_<suffix> ( Args
&&... ) { /*...*/ }

This syntax for invoking this literal operator would use an
aggregate-initialization block, such as would be used to initialize a
struct.  So for example, this could be used to define a terse suffix for
std::tuple:

template< typename ...Args > auto operator ""_tuple ( Args &&...args ) {
    return tuple( std::forward<Args>( args )... ); // Relies on new class
template argument deduction from C++17
}
// ...
auto tup = { 1.0f, "unnamed", '\n' }_tuple;

I realize that this particular example might not be particularly
motivating, since we already have std::make_tuple, and the new class
template arg deduction feature alongside that means that both give nice
terse syntax for creating a tuple.  I use it here mostly because it
provides a straightforward way to express the idea.  Another example could
offer a natural ordered-pair-like syntax for a custom linear algebra Vector
class:

template< typename T, size_t N >
struct Vector : std::array<T, N> {
    // ...
};

template< typename T, typename S, size_t N >
Scalar dot( Vector<T, N> const &v1, Vector<S, N> const &v2 ) {
    // compute and return dot product of v1 and v2...
}

template< typename ...Args > auto operator ""_v ( Args &&...args ) {
    return Vector<std::common_type_t<Args...>, sizeof...(Args)>{
std::forward<Args>( args )... };
}
// ...
auto vec3f = {0.74f, 0.74f, 0.0f}_v;
float s = dot( vec3f, {1.0f, 0.0f, 0.0f}_v );

Of course, the above could be achieved with the currently permissible 'char
*' parameter for custom literal operators, but that would require some
tricky compile-time parsing of the char * string to determine the Vector's
template arguments T and N, as well as other compile-time parsing, and the
resulting syntax doesn't seem quite as natural or as close to the common
mathematics notation for ordered pairs:

auto vec3f = "0.74f, 0.74f, 0.0f"_v;
float s = dot( vec3f, "1.0f, 0.0f, 0.0f"_v );

I also realize the above could also be achieved using normal template
functions or 'make_vector" functions, and in a pinch if terseness is
desired the make_ functions could just be given very short names.  But
pointing that out would serve as an argument against custom literal
operators in general, not only this specific extension to them.

Another objection I could anticipate is if this could maybe be seen as
another gateway towards the objection compiler implementors have had
against the proposed compile-time string literals which return each string
character as a separate 'char' non-type template argument, namely that of
encouraging the use of too many template arguments which can slow
compilation.  But at least for that specific use case I don't see this
likely to lead to the same result; it wouldn't make constructing such
templates any more convenient than it is presently, since it would still
require listing separate characters separately:

auto constexpr s = {'s', 't', 'r', 'i', 'n', 'g', '\0'}_string_literal;

So, does this seem to others like a useful extension to the custom user
literals mechanism?  I personally quite like, in the Vector example, how it
would enable a notation quite close to traditional math notations.  It
could make life easier for any custom type that is convenient to express
tersely as some ordered heterogeneous tuple: the compiler would provide
type checking and automatic separation of the different arguments without
requiring compile-time string parsing.

-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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/daa04461-f354-4c44-826a-444d2aee3c94%40isocpp.org.

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

<div dir=3D"ltr">What if there were an additional parameter list allowed fo=
r defining custom literals, specifically:<div><br></div><div>template&lt; t=
ypename ...Args &gt; &lt;return_type&gt; operator &quot;&quot;_&lt;suffix&g=
t; ( Args &amp;&amp;... ) { /*...*/ }</div><div><br></div><div>This syntax =
for invoking this literal operator would use an aggregate-initialization bl=
ock, such as would be used to initialize a struct. =C2=A0So for example, th=
is could be used to define a terse suffix for std::tuple:</div><div><br></d=
iv><div>template&lt; typename ...Args &gt; auto operator &quot;&quot;_tuple=
 ( Args &amp;&amp;...args ) {</div><div>=C2=A0 =C2=A0 return tuple( std::fo=
rward&lt;Args&gt;( args )... ); // Relies on new class template argument de=
duction from C++17</div><div>}</div><div>// ...</div><div>auto tup =3D { 1.=
0f, &quot;unnamed&quot;, &#39;\n&#39; }_tuple;</div><div><br></div><div>I r=
ealize that this particular example might not be particularly motivating, s=
ince we already have std::make_tuple, and the new class template arg deduct=
ion feature alongside that means that both give nice terse syntax for creat=
ing a tuple. =C2=A0I use it here mostly because it provides a straightforwa=
rd way to express the idea. =C2=A0Another example could offer a natural ord=
ered-pair-like syntax for a custom linear algebra Vector class:</div><div><=
br></div><div>template&lt; typename T, size_t N &gt;</div><div>struct Vecto=
r : std::array&lt;T, N&gt; {</div><div>=C2=A0 =C2=A0 // ...</div><div>};</d=
iv><div><br></div><div>template&lt; typename T, typename S, size_t N &gt;</=
div><div>Scalar dot( Vector&lt;T, N&gt; const &amp;v1, Vector&lt;S, N&gt; c=
onst &amp;v2 ) {</div><div>=C2=A0 =C2=A0 // compute and return dot product =
of v1 and v2...</div><div>}</div><div><br></div><div>template&lt; typename =
....Args &gt; auto operator &quot;&quot;_v ( Args &amp;&amp;...args ) {</div=
><div>=C2=A0 =C2=A0 return Vector&lt;std::common_type_t&lt;Args...&gt;, siz=
eof...(Args)&gt;{ std::forward&lt;Args&gt;( args )... };</div><div>}</div><=
div>// ...</div><div>auto vec3f =3D {0.74f, 0.74f, 0.0f}_v;</div><div>float=
 s =3D dot( vec3f, {1.0f, 0.0f, 0.0f}_v );</div><div><br></div><div>Of cour=
se, the above could be achieved with the currently permissible &#39;char *&=
#39; parameter for custom literal operators, but that would require some tr=
icky compile-time parsing of the char * string to determine the Vector&#39;=
s template arguments T and N, as well as other compile-time parsing, and th=
e resulting syntax doesn&#39;t seem quite as natural or as close to the com=
mon mathematics notation for ordered pairs:</div><div><br></div><div>auto v=
ec3f =3D &quot;0.74f, 0.74f, 0.0f&quot;_v;</div><div>float s =3D dot( vec3f=
, &quot;1.0f, 0.0f, 0.0f&quot;_v );</div><div><br></div><div>I also realize=
 the above could also be achieved using normal template functions or &#39;m=
ake_vector&quot; functions, and in a pinch if terseness is desired the make=
_ functions could just be given very short names. =C2=A0But pointing that o=
ut would serve as an argument against custom literal operators in general, =
not only this specific extension to them.</div><div><br></div><div>Another =
objection I could anticipate is if this could maybe be seen as another gate=
way towards the objection compiler implementors have had against the propos=
ed compile-time string literals which return each string character as a sep=
arate &#39;char&#39; non-type template argument, namely that of encouraging=
 the use of too many template arguments which can slow compilation. =C2=A0B=
ut at least for that specific use case I don&#39;t see this likely to lead =
to the same result; it wouldn&#39;t make constructing such templates any mo=
re convenient than it is presently, since it would still require listing se=
parate characters separately:</div><div><br></div><div>auto constexpr s =3D=
 {&#39;s&#39;, &#39;t&#39;, &#39;r&#39;, &#39;i&#39;, &#39;n&#39;, &#39;g&#=
39;, &#39;\0&#39;}_string_literal;</div><div><br></div><div>So, does this s=
eem to others like a useful extension to the custom user literals mechanism=
? =C2=A0I personally quite like, in the Vector example, how it would enable=
 a notation quite close to traditional math notations. =C2=A0It could make =
life easier for any custom type that is convenient to express tersely as so=
me ordered heterogeneous tuple: the compiler would provide type checking an=
d automatic separation of the different arguments without requiring compile=
-time string parsing.</div><div><br></div><div>-Andy</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/daa04461-f354-4c44-826a-444d2aee3c94%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/daa04461-f354-4c44-826a-444d2aee3c94=
%40isocpp.org</a>.<br />

------=_Part_3683_314418435.1480921851146--

------=_Part_3682_680518006.1480921851145--

.

------=_Part_1411_2121055818.1480923865575
Content-Type: multipart/alternative;
 boundary="----=_Part_1412_912076792.1480923865575"

------=_Part_1412_912076792.1480923865575
Content-Type: text/plain; charset=UTF-8

After writing all of the above, I began to realize all my examples had a
variadic template parameter list.  It occurred to me that level of
genericness might not always be desired.  For example, with my Vector
class, there could be a suffix that enforced a certain scalar type and
dimension, with compile-type errors if the suffix is used but the wrong
scalar type and dimension are given.  This would be a natural consequence
of the compiler simply failing to find an overload of the custom literal
operator that matches:

Vector<float, 3> operator ""_v3f ( float s1, float s2, float s3 ) {
    return Vector<float, 3>{s1, s2, s3};
}
auto vec3 = {0.74f, 0.74f, 0.0f, 1.0f}_v3f // error: no overload of
operator ""_v3f takes four arguments


So I realized what I'm proposing, (unless the variadic template signature
were explicitly required by the standard), is essentially that the
restriction to only a certain set of accepted parameter signature be
lifted.  That gives me some pause, since I assume that committee did a lot
of work to come up with that specific set of allowable parameter signatures
and that there were good reasons for it.  Still, it would be fun if the
more mathematical kinds of notation this would allow are as appealing to
others as they would be to me, so that there might be some motivation to
revisit the reasons for those restrictions.

I wonder if arbitrary function signatures were indeed considered by the
committee.  If so, had one of the issues been how to accommodate multiple
arguments with a single invoking suffix?  Had the
brace-enclosed-initializer syntax I've suggested here been looked at?  Was
it rejected on ground that it would complicated parsing?  Since I wasn't
involved at all, I'm just speculating wildly; I'm really just trying to
anticipate objections or problems there could be so I can think about them.

Warning, from here on, I get very out-there and general in exploring
ramifications of this proposal, in a rambling stream of conscious:

Another funny thing about this idea is that, with permitting arbitrary
function signatures for literal operators, it would really amount to little
more than an alternate suffix-based notation for defining and invoking
ordinary free functions; the chief difference being that the argument list
is enclosed with braces {} rather than parentheses (), and the function
name, obviously, follows the argument list.  I do like the {} for enclosing
the list, as braces historically carry more of a connotation of
initialization or aggregate data, which is much closer to the expected
use-case for user-defined literals.  Is there a reason to allow some free
functions to be defined as invokable only with prefix-with-parentheses
notation and others only with braces-with-suffix?  If more general use for
this tool were found later, would be yet another headache for generic
library programmers, to accommodate yet another function invocation syntax
(for example, proposals having to do with overloading operator . or
introducing a universal member function calling syntax seem to be efforts
designed to overcome that kind of issue with function invocation in generic
code).  If so, could that be resolved by permitting _all_ functions to be
called either by the prefix-based or the suffix-based notation?  I.e. what
if some classical function 'int foo(char c)' that's been around for a long
time could not be invoked with 'auto t = {'s'}_foo'?  Or, if 'bar' were
declared: 'int operator ""_bar (char c);', it could also be invoked by
'auto t = bar('s')'.  Hmm... I'm not sure that would be good at all, since
it could suddenly introduce name collisions and unintended overload set
expansions to existing code, just because some literal suffix operator was
added in some header that happened to use a suffix that matched some other
function's name...

It would be hard to argue that all of the above is worth resolving for a
feature that amounts to syntactic sugar, and that doesn't really enable any
new language functionality.  Maybe it really would be best to not try to
marry a '{a, b, c}_suffix' mechanism with the general notion of free
functions.  So it's probably best to just stick with trying to fulfill the
better-scoped use case of convenient math-like notation for initializations.

-Andy

On Monday, December 5, 2016 at 12:10:51 AM UTC-7, Anthony Hall wrote:
>
> What if there were an additional parameter list allowed for defining
> custom literals, specifically:
>
> template< typename ...Args > <return_type> operator ""_<suffix> ( Args
> &&... ) { /*...*/ }
>
> This syntax for invoking this literal operator would use an
> aggregate-initialization block, such as would be used to initialize a
> struct.  So for example, this could be used to define a terse suffix for
> std::tuple:
>
> template< typename ...Args > auto operator ""_tuple ( Args &&...args ) {
>     return tuple( std::forward<Args>( args )... ); // Relies on new class
> template argument deduction from C++17
> }
> // ...
> auto tup = { 1.0f, "unnamed", '\n' }_tuple;
>
> I realize that this particular example might not be particularly
> motivating, since we already have std::make_tuple, and the new class
> template arg deduction feature alongside that means that both give nice
> terse syntax for creating a tuple.  I use it here mostly because it
> provides a straightforward way to express the idea.  Another example could
> offer a natural ordered-pair-like syntax for a custom linear algebra Vector
> class:
>
> template< typename T, size_t N >
> struct Vector : std::array<T, N> {
>     // ...
> };
>
> template< typename T, typename S, size_t N >
> Scalar dot( Vector<T, N> const &v1, Vector<S, N> const &v2 ) {
>     // compute and return dot product of v1 and v2...
> }
>
> template< typename ...Args > auto operator ""_v ( Args &&...args ) {
>     return Vector<std::common_type_t<Args...>, sizeof...(Args)>{
> std::forward<Args>( args )... };
> }
> // ...
> auto vec3f = {0.74f, 0.74f, 0.0f}_v;
> float s = dot( vec3f, {1.0f, 0.0f, 0.0f}_v );
>
> Of course, the above could be achieved with the currently permissible
> 'char *' parameter for custom literal operators, but that would require
> some tricky compile-time parsing of the char * string to determine the
> Vector's template arguments T and N, as well as other compile-time parsing,
> and the resulting syntax doesn't seem quite as natural or as close to the
> common mathematics notation for ordered pairs:
>
> auto vec3f = "0.74f, 0.74f, 0.0f"_v;
> float s = dot( vec3f, "1.0f, 0.0f, 0.0f"_v );
>
> I also realize the above could also be achieved using normal template
> functions or 'make_vector" functions, and in a pinch if terseness is
> desired the make_ functions could just be given very short names.  But
> pointing that out would serve as an argument against custom literal
> operators in general, not only this specific extension to them.
>
> Another objection I could anticipate is if this could maybe be seen as
> another gateway towards the objection compiler implementors have had
> against the proposed compile-time string literals which return each string
> character as a separate 'char' non-type template argument, namely that of
> encouraging the use of too many template arguments which can slow
> compilation.  But at least for that specific use case I don't see this
> likely to lead to the same result; it wouldn't make constructing such
> templates any more convenient than it is presently, since it would still
> require listing separate characters separately:
>
> auto constexpr s = {'s', 't', 'r', 'i', 'n', 'g', '\0'}_string_literal;
>
> So, does this seem to others like a useful extension to the custom user
> literals mechanism?  I personally quite like, in the Vector example, how it
> would enable a notation quite close to traditional math notations.  It
> could make life easier for any custom type that is convenient to express
> tersely as some ordered heterogeneous tuple: the compiler would provide
> type checking and automatic separation of the different arguments without
> requiring compile-time string parsing.
>
> -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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/62e59a3a-6a50-45a4-8758-67302ebb6b9c%40isocpp.org.

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

<div dir=3D"ltr">After writing all of the above, I began to realize all my =
examples had a variadic template parameter list. =C2=A0It occurred to me th=
at level of genericness might not always be desired. =C2=A0For example, wit=
h my Vector class, there could be a suffix that enforced a certain scalar t=
ype and dimension, with compile-type errors if the suffix is used but the w=
rong scalar type and dimension are given. =C2=A0This would be a natural con=
sequence of the compiler simply failing to find an overload of the custom l=
iteral operator that matches:<div><br></div><div class=3D"prettyprint" styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; word-wrap: break-word;"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #606=
;" class=3D"styled-by-prettify">Vector</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">float</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>3</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #080;" class=3D"styled-by-prettify">&quot;&quot;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">_v3f </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">float</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> s1</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">float</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> s2</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">float</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> s3 </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Vector</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">float</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: #0=
66;" class=3D"styled-by-prettify">3</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&gt;{</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">s1</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> s2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> s3</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><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> vec3 </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0.74f</sp=
an><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: #066;" class=3D"styled-by-prettify">0.74f</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: #066;" class=3D"=
styled-by-prettify">0.0f</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">1.0f=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">_v3f </span><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">// error: no overload of=
 operator &quot;&quot;_v3f takes four arguments</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br></span></div></code></div><div><br=
><br>So I realized what I&#39;m proposing, (unless the variadic template si=
gnature were explicitly required by the standard), is essentially that the =
restriction to only a certain set of accepted parameter signature be lifted=
.. =C2=A0That gives me some pause, since I assume that committee did a lot o=
f work to come up with that specific set of allowable parameter signatures =
and that there were good reasons for it. =C2=A0Still, it would be fun if th=
e more mathematical kinds of notation this would allow are as appealing to =
others as they would be to me, so that there might be some motivation to re=
visit the reasons for those restrictions.</div><div><br></div><div>I wonder=
 if arbitrary function signatures were indeed considered by the committee. =
=C2=A0If so, had one of the issues been how to accommodate multiple argumen=
ts with a single invoking suffix? =C2=A0Had the brace-enclosed-initializer =
syntax I&#39;ve suggested here been looked at? =C2=A0Was it rejected on gro=
und that it would complicated parsing? =C2=A0Since I wasn&#39;t involved at=
 all, I&#39;m just speculating wildly; I&#39;m really just trying to antici=
pate objections or problems there could be so I can think about them.</div>=
<div><br>Warning, from here on, I get very out-there and general in explori=
ng ramifications of this proposal, in a rambling stream of conscious:<br><b=
r></div><div>Another funny thing about this idea is that, with permitting a=
rbitrary function signatures for literal operators, it would really amount =
to little more than an alternate suffix-based notation for defining and inv=
oking ordinary free functions; the chief difference being that the argument=
 list is enclosed with braces {} rather than parentheses (), and the functi=
on name, obviously, follows the argument list. =C2=A0I do like the {} for e=
nclosing the list, as braces historically carry more of a connotation of in=
itialization or aggregate data, which is much closer to the expected use-ca=
se for user-defined literals. =C2=A0Is there a reason to allow some free fu=
nctions to be defined as invokable only with prefix-with-parentheses notati=
on and others only with braces-with-suffix? =C2=A0If more general use for t=
his tool were found later, would be yet another headache for generic librar=
y programmers, to accommodate yet another function invocation syntax (for e=
xample, proposals having to do with overloading operator . or introducing a=
 universal member function calling syntax seem to be efforts designed to ov=
ercome that kind of issue with function invocation in generic code). =C2=A0=
If so, could that be resolved by permitting _all_ functions to be called ei=
ther by the prefix-based or the suffix-based notation? =C2=A0I.e. what if s=
ome classical function &#39;int foo(char c)&#39; that&#39;s been around for=
 a long time could not be invoked with &#39;auto t =3D {&#39;s&#39;}_foo&#3=
9;? =C2=A0Or, if &#39;bar&#39; were declared: &#39;int operator &quot;&quot=
;_bar (char c);&#39;, it could also be invoked by &#39;auto t =3D bar(&#39;=
s&#39;)&#39;. =C2=A0Hmm... I&#39;m not sure that would be good at all, sinc=
e it could suddenly introduce name collisions and unintended overload set e=
xpansions to existing code, just because some literal suffix operator was a=
dded in some header that happened to use a suffix that matched some other f=
unction&#39;s name...<br><br>It would be hard to argue that all of the abov=
e is worth resolving for a feature that amounts to syntactic sugar, and tha=
t doesn&#39;t really enable any new language functionality. =C2=A0Maybe it =
really would be best to not try to marry a &#39;{a, b, c}_suffix&#39; mecha=
nism with the general notion of free functions. =C2=A0So it&#39;s probably =
best to just stick with trying to fulfill the better-scoped use case of con=
venient math-like notation for initializations.</div><div><br>-Andy<br><br>=
On Monday, December 5, 2016 at 12:10:51 AM UTC-7, Anthony Hall wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">What if there were =
an additional parameter list allowed for defining custom literals, specific=
ally:<div><br></div><div>template&lt; typename ...Args &gt; &lt;return_type=
&gt; operator &quot;&quot;_&lt;suffix&gt; ( Args &amp;&amp;... ) { /*...*/ =
}</div><div><br></div><div>This syntax for invoking this literal operator w=
ould use an aggregate-initialization block, such as would be used to initia=
lize a struct. =C2=A0So for example, this could be used to define a terse s=
uffix for std::tuple:</div><div><br></div><div>template&lt; typename ...Arg=
s &gt; auto operator &quot;&quot;_tuple ( Args &amp;&amp;...args ) {</div><=
div>=C2=A0 =C2=A0 return tuple( std::forward&lt;Args&gt;( args )... ); // R=
elies on new class template argument deduction from C++17</div><div>}</div>=
<div>// ...</div><div>auto tup =3D { 1.0f, &quot;unnamed&quot;, &#39;\n&#39=
; }_tuple;</div><div><br></div><div>I realize that this particular example =
might not be particularly motivating, since we already have std::make_tuple=
, and the new class template arg deduction feature alongside that means tha=
t both give nice terse syntax for creating a tuple. =C2=A0I use it here mos=
tly because it provides a straightforward way to express the idea. =C2=A0An=
other example could offer a natural ordered-pair-like syntax for a custom l=
inear algebra Vector class:</div><div><br></div><div>template&lt; typename =
T, size_t N &gt;</div><div>struct Vector : std::array&lt;T, N&gt; {</div><d=
iv>=C2=A0 =C2=A0 // ...</div><div>};</div><div><br></div><div>template&lt; =
typename T, typename S, size_t N &gt;</div><div>Scalar dot( Vector&lt;T, N&=
gt; const &amp;v1, Vector&lt;S, N&gt; const &amp;v2 ) {</div><div>=C2=A0 =
=C2=A0 // compute and return dot product of v1 and v2...</div><div>}</div><=
div><br></div><div>template&lt; typename ...Args &gt; auto operator &quot;&=
quot;_v ( Args &amp;&amp;...args ) {</div><div>=C2=A0 =C2=A0 return Vector&=
lt;std::common_type_t&lt;<wbr>Args...&gt;, sizeof...(Args)&gt;{ std::forwar=
d&lt;Args&gt;( args )... };</div><div>}</div><div>// ...</div><div>auto vec=
3f =3D {0.74f, 0.74f, 0.0f}_v;</div><div>float s =3D dot( vec3f, {1.0f, 0.0=
f, 0.0f}_v );</div><div><br></div><div>Of course, the above could be achiev=
ed with the currently permissible &#39;char *&#39; parameter for custom lit=
eral operators, but that would require some tricky compile-time parsing of =
the char * string to determine the Vector&#39;s template arguments T and N,=
 as well as other compile-time parsing, and the resulting syntax doesn&#39;=
t seem quite as natural or as close to the common mathematics notation for =
ordered pairs:</div><div><br></div>auto vec3f =3D &quot;0.74f, 0.74f, 0.0f&=
quot;_v;<br>float s =3D dot( vec3f, &quot;1.0f, 0.0f, 0.0f&quot;_v );<div><=
br></div><div>I also realize the above could also be achieved using normal =
template functions or &#39;make_vector&quot; functions, and in a pinch if t=
erseness is desired the make_ functions could just be given very short name=
s. =C2=A0But pointing that out would serve as an argument against custom li=
teral operators in general, not only this specific extension to them.</div>=
<div><br></div><div>Another objection I could anticipate is if this could m=
aybe be seen as another gateway towards the objection compiler implementors=
 have had against the proposed compile-time string literals which return ea=
ch string character as a separate &#39;char&#39; non-type template argument=
, namely that of encouraging the use of too many template arguments which c=
an slow compilation. =C2=A0But at least for that specific use case I don&#3=
9;t see this likely to lead to the same result; it wouldn&#39;t make constr=
ucting such templates any more convenient than it is presently, since it wo=
uld still require listing separate characters separately:</div><div><br></d=
iv>auto constexpr s =3D {&#39;s&#39;, &#39;t&#39;, &#39;r&#39;, &#39;i&#39;=
, &#39;n&#39;, &#39;g&#39;, &#39;\0&#39;}_string_literal;<br><div><br></div=
><div>So, does this seem to others like a useful extension to the custom us=
er literals mechanism? =C2=A0I personally quite like, in the Vector example=
, how it would enable a notation quite close to traditional math notations.=
 =C2=A0It could make life easier for any custom type that is convenient to =
express tersely as some ordered heterogeneous tuple: the compiler would pro=
vide type checking and automatic separation of the different arguments with=
out requiring compile-time string parsing.</div><div><br></div><div>-Andy</=
div></div></blockquote></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/62e59a3a-6a50-45a4-8758-67302ebb6b9c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/62e59a3a-6a50-45a4-8758-67302ebb6b9c=
%40isocpp.org</a>.<br />

------=_Part_1412_912076792.1480923865575--

------=_Part_1411_2121055818.1480923865575--

.

------=_Part_1378_484529671.1480936121380
Content-Type: multipart/alternative;
 boundary="----=_Part_1379_1517826641.1480936121381"

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

Why not use a single std::initializer_list<T> argument instead of variadic=
=20
argument list?=20

=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 5 =D0=
=B4=D0=B5=D0=BA=D0=B0=D0=B1=D1=80=D1=8F 2016 =D0=B3., 10:10:51 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Anthony =
Hall=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> What if there were an additional parameter list allowed for defining=20
> custom literals, specifically:
>
> template< typename ...Args > <return_type> operator ""_<suffix> ( Args=20
> &&... ) { /*...*/ }
>
> This syntax for invoking this literal operator would use an=20
> aggregate-initialization block, such as would be used to initialize a=20
> struct.  So for example, this could be used to define a terse suffix for=
=20
> std::tuple:
>
> template< typename ...Args > auto operator ""_tuple ( Args &&...args ) {
>     return tuple( std::forward<Args>( args )... ); // Relies on new class=
=20
> template argument deduction from C++17
> }
> // ...
> auto tup =3D { 1.0f, "unnamed", '\n' }_tuple;
>
> I realize that this particular example might not be particularly=20
> motivating, since we already have std::make_tuple, and the new class=20
> template arg deduction feature alongside that means that both give nice=
=20
> terse syntax for creating a tuple.  I use it here mostly because it=20
> provides a straightforward way to express the idea.  Another example coul=
d=20
> offer a natural ordered-pair-like syntax for a custom linear algebra Vect=
or=20
> class:
>
> template< typename T, size_t N >
> struct Vector : std::array<T, N> {
>     // ...
> };
>
> template< typename T, typename S, size_t N >
> Scalar dot( Vector<T, N> const &v1, Vector<S, N> const &v2 ) {
>     // compute and return dot product of v1 and v2...
> }
>
> template< typename ...Args > auto operator ""_v ( Args &&...args ) {
>     return Vector<std::common_type_t<Args...>, sizeof...(Args)>{=20
> std::forward<Args>( args )... };
> }
> // ...
> auto vec3f =3D {0.74f, 0.74f, 0.0f}_v;
> float s =3D dot( vec3f, {1.0f, 0.0f, 0.0f}_v );
>
> Of course, the above could be achieved with the currently permissible=20
> 'char *' parameter for custom literal operators, but that would require=
=20
> some tricky compile-time parsing of the char * string to determine the=20
> Vector's template arguments T and N, as well as other compile-time parsin=
g,=20
> and the resulting syntax doesn't seem quite as natural or as close to the=
=20
> common mathematics notation for ordered pairs:
>
> auto vec3f =3D "0.74f, 0.74f, 0.0f"_v;
> float s =3D dot( vec3f, "1.0f, 0.0f, 0.0f"_v );
>
> I also realize the above could also be achieved using normal template=20
> functions or 'make_vector" functions, and in a pinch if terseness is=20
> desired the make_ functions could just be given very short names.  But=20
> pointing that out would serve as an argument against custom literal=20
> operators in general, not only this specific extension to them.
>
> Another objection I could anticipate is if this could maybe be seen as=20
> another gateway towards the objection compiler implementors have had=20
> against the proposed compile-time string literals which return each strin=
g=20
> character as a separate 'char' non-type template argument, namely that of=
=20
> encouraging the use of too many template arguments which can slow=20
> compilation.  But at least for that specific use case I don't see this=20
> likely to lead to the same result; it wouldn't make constructing such=20
> templates any more convenient than it is presently, since it would still=
=20
> require listing separate characters separately:
>
> auto constexpr s =3D {'s', 't', 'r', 'i', 'n', 'g', '\0'}_string_literal;
>
> So, does this seem to others like a useful extension to the custom user=
=20
> literals mechanism?  I personally quite like, in the Vector example, how =
it=20
> would enable a notation quite close to traditional math notations.  It=20
> could make life easier for any custom type that is convenient to express=
=20
> tersely as some ordered heterogeneous tuple: the compiler would provide=
=20
> type checking and automatic separation of the different arguments without=
=20
> requiring compile-time string parsing.
>
> -Andy
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/fc7570a3-337f-462b-9818-fc0047d1b757%40isocpp.or=
g.

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

<div dir=3D"ltr">Why not use a single std::initializer_list&lt;T&gt; argume=
nt instead of variadic argument list?=C2=A0<br><br>=D0=BF=D0=BE=D0=BD=D0=B5=
=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 5 =D0=B4=D0=B5=D0=BA=D0=B0=D0=
=B1=D1=80=D1=8F 2016 =D0=B3., 10:10:51 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=
=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Anthony Hall =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0=D0=BB:<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">What if there were an additional parameter list allowed for def=
ining custom literals, specifically:<div><br></div><div>template&lt; typena=
me ...Args &gt; &lt;return_type&gt; operator &quot;&quot;_&lt;suffix&gt; ( =
Args &amp;&amp;... ) { /*...*/ }</div><div><br></div><div>This syntax for i=
nvoking this literal operator would use an aggregate-initialization block, =
such as would be used to initialize a struct. =C2=A0So for example, this co=
uld be used to define a terse suffix for std::tuple:</div><div><br></div><d=
iv>template&lt; typename ...Args &gt; auto operator &quot;&quot;_tuple ( Ar=
gs &amp;&amp;...args ) {</div><div>=C2=A0 =C2=A0 return tuple( std::forward=
&lt;Args&gt;( args )... ); // Relies on new class template argument deducti=
on from C++17</div><div>}</div><div>// ...</div><div>auto tup =3D { 1.0f, &=
quot;unnamed&quot;, &#39;\n&#39; }_tuple;</div><div><br></div><div>I realiz=
e that this particular example might not be particularly motivating, since =
we already have std::make_tuple, and the new class template arg deduction f=
eature alongside that means that both give nice terse syntax for creating a=
 tuple. =C2=A0I use it here mostly because it provides a straightforward wa=
y to express the idea. =C2=A0Another example could offer a natural ordered-=
pair-like syntax for a custom linear algebra Vector class:</div><div><br></=
div><div>template&lt; typename T, size_t N &gt;</div><div>struct Vector : s=
td::array&lt;T, N&gt; {</div><div>=C2=A0 =C2=A0 // ...</div><div>};</div><d=
iv><br></div><div>template&lt; typename T, typename S, size_t N &gt;</div><=
div>Scalar dot( Vector&lt;T, N&gt; const &amp;v1, Vector&lt;S, N&gt; const =
&amp;v2 ) {</div><div>=C2=A0 =C2=A0 // compute and return dot product of v1=
 and v2...</div><div>}</div><div><br></div><div>template&lt; typename ...Ar=
gs &gt; auto operator &quot;&quot;_v ( Args &amp;&amp;...args ) {</div><div=
>=C2=A0 =C2=A0 return Vector&lt;std::common_type_t&lt;Args...&gt;, sizeof..=
..(Args)&gt;{ std::forward&lt;Args&gt;( args )... };</div><div>}</div><div>/=
/ ...</div><div>auto vec3f =3D {0.74f, 0.74f, 0.0f}_v;</div><div>float s =
=3D dot( vec3f, {1.0f, 0.0f, 0.0f}_v );</div><div><br></div><div>Of course,=
 the above could be achieved with the currently permissible &#39;char *&#39=
; parameter for custom literal operators, but that would require some trick=
y compile-time parsing of the char * string to determine the Vector&#39;s t=
emplate arguments T and N, as well as other compile-time parsing, and the r=
esulting syntax doesn&#39;t seem quite as natural or as close to the common=
 mathematics notation for ordered pairs:</div><div><br></div><div>auto vec3=
f =3D &quot;0.74f, 0.74f, 0.0f&quot;_v;</div><div>float s =3D dot( vec3f, &=
quot;1.0f, 0.0f, 0.0f&quot;_v );</div><div><br></div><div>I also realize th=
e above could also be achieved using normal template functions or &#39;make=
_vector&quot; functions, and in a pinch if terseness is desired the make_ f=
unctions could just be given very short names. =C2=A0But pointing that out =
would serve as an argument against custom literal operators in general, not=
 only this specific extension to them.</div><div><br></div><div>Another obj=
ection I could anticipate is if this could maybe be seen as another gateway=
 towards the objection compiler implementors have had against the proposed =
compile-time string literals which return each string character as a separa=
te &#39;char&#39; non-type template argument, namely that of encouraging th=
e use of too many template arguments which can slow compilation. =C2=A0But =
at least for that specific use case I don&#39;t see this likely to lead to =
the same result; it wouldn&#39;t make constructing such templates any more =
convenient than it is presently, since it would still require listing separ=
ate characters separately:</div><div><br></div><div>auto constexpr s =3D {&=
#39;s&#39;, &#39;t&#39;, &#39;r&#39;, &#39;i&#39;, &#39;n&#39;, &#39;g&#39;=
, &#39;\0&#39;}_string_literal;</div><div><br></div><div>So, does this seem=
 to others like a useful extension to the custom user literals mechanism? =
=C2=A0I personally quite like, in the Vector example, how it would enable a=
 notation quite close to traditional math notations. =C2=A0It could make li=
fe easier for any custom type that is convenient to express tersely as some=
 ordered heterogeneous tuple: the compiler would provide type checking and =
automatic separation of the different arguments without requiring compile-t=
ime string parsing.</div><div><br></div><div>-Andy</div></div></blockquote>=
</div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fc7570a3-337f-462b-9818-fc0047d1b757%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fc7570a3-337f-462b-9818-fc0047d1b757=
%40isocpp.org</a>.<br />

------=_Part_1379_1517826641.1480936121381--

------=_Part_1378_484529671.1480936121380--

.

------=_Part_4104_1745837042.1480956361409
Content-Type: multipart/alternative;
 boundary="----=_Part_4105_796749369.1480956361409"

------=_Part_4105_796749369.1480956361409
Content-Type: text/plain; charset=UTF-8



On Monday, December 5, 2016 at 2:10:51 AM UTC-5, Anthony Hall wrote:
>
> What if there were an additional parameter list allowed for defining
> custom literals, specifically:
>
> template< typename ...Args > <return_type> operator ""_<suffix> ( Args
> &&... ) { /*...*/ }
>
> This syntax for invoking this literal operator would use an
> aggregate-initialization block, such as would be used to initialize a
> struct.  So for example, this could be used to define a terse suffix for
> std::tuple:
>
> template< typename ...Args > auto operator ""_tuple ( Args &&...args ) {
>     return tuple( std::forward<Args>( args )... ); // Relies on new class
> template argument deduction from C++17
> }
> // ...
> auto tup = { 1.0f, "unnamed", '\n' }_tuple;
>

> I realize that this particular example might not be particularly
> motivating, since we already have std::make_tuple, and the new class
> template arg deduction feature alongside that means that both give nice
> terse syntax for creating a tuple.  I use it here mostly because it
> provides a straightforward way to express the idea.  Another example could
> offer a natural ordered-pair-like syntax for a custom linear algebra Vector
> class:
>
> template< typename T, size_t N >
> struct Vector : std::array<T, N> {
>     // ...
> };
>

Wasn't there a discussion somewhere about template deduction guides and
arrays? Some question about whether or not one could make it work for
`std::array`, where it could deduce the number of elements from the number
of parameters?

I think it looked something like this:

template<typename ...Args>
std::array(Args &&...args) -> std::array</*extract the T type*/, sizeof...(
Args)>;

This would work even though `array` is an aggregate. The deduction guide
part is only used to determine the template parameters; the actual
initialization happens as normal.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e3714a15-0379-4ede-a796-5d898d6c5238%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Monday, December 5, 2016 at 2:10:51 AM UTC-5, A=
nthony Hall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">What if there were an additional parameter list allowed for defining c=
ustom literals, specifically:<div><br></div><div>template&lt; typename ...A=
rgs &gt; &lt;return_type&gt; operator &quot;&quot;_&lt;suffix&gt; ( Args &a=
mp;&amp;... ) { /*...*/ }</div><div><br></div><div>This syntax for invoking=
 this literal operator would use an aggregate-initialization block, such as=
 would be used to initialize a struct. =C2=A0So for example, this could be =
used to define a terse suffix for std::tuple:</div><div><br></div><div>temp=
late&lt; typename ...Args &gt; auto operator &quot;&quot;_tuple ( Args &amp=
;&amp;...args ) {</div><div>=C2=A0 =C2=A0 return tuple( std::forward&lt;Arg=
s&gt;( args )... ); // Relies on new class template argument deduction from=
 C++17</div><div>}</div><div>// ...</div><div>auto tup =3D { 1.0f, &quot;un=
named&quot;, &#39;\n&#39; }_tuple;</div></div></blockquote><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px soli=
d rgb(204, 204, 204); padding-left: 1ex;"><div><br></div></blockquote><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>I =
realize that this particular example might not be particularly motivating, =
since we already have std::make_tuple, and the new class template arg deduc=
tion feature alongside that means that both give nice terse syntax for crea=
ting a tuple. =C2=A0I use it here mostly because it provides a straightforw=
ard way to express the idea. =C2=A0Another example could offer a natural or=
dered-pair-like syntax for a custom linear algebra Vector class:</div><div>=
<br></div><div>template&lt; typename T, size_t N &gt;</div><div>struct Vect=
or : std::array&lt;T, N&gt; {</div><div>=C2=A0 =C2=A0 // ...</div><div>};</=
div></div></blockquote><div><br>Wasn&#39;t there a discussion somewhere abo=
ut template deduction guides and arrays? Some question about whether or not=
 one could make it work for `std::array`, where it could deduce the number =
of elements from the number of parameters?<br><br>I think it looked somethi=
ng like this:<br><br><div style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; ove=
rflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">template</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">typename</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Args</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">array</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" clas=
s=3D"styled-by-prettify">Args</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&amp;&amp;...</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">args</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&gt;</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">array</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: =
#800;" class=3D"styled-by-prettify">/*extract the T type*/</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">sizeof</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">...(</span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Args</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">)&gt;;</span></div></code></div><br>This would work even thou=
gh `array` is an aggregate. The deduction guide part is only used to determ=
ine the template parameters; the actual initialization happens as normal.</=
div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e3714a15-0379-4ede-a796-5d898d6c5238%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e3714a15-0379-4ede-a796-5d898d6c5238=
%40isocpp.org</a>.<br />

------=_Part_4105_796749369.1480956361409--

------=_Part_4104_1745837042.1480956361409--

.

Em domingo, 4 de dezembro de 2016, =C3=A0s 23:10:51 PST, Anthony Hall escre=
veu:
> auto vec3f =3D {0.74f, 0.74f, 0.0f}_v;
> float s =3D dot( vec3f, {1.0f, 0.0f, 0.0f}_v );

Why can't you write:

 auto vec3f =3D v(0.74f, 0.74f, 0.f);
 float s =3D dot(vec3f, v{1.0f, 0.0f, 0.0f});

With a suitably-defined "v" function somewhere that operates like make_tupl=
e?

Why does it need to be an UDL?

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1761696.CnmSmY9c4V%40tjmaciei-mobl1.

.

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

>
> Why can't you write:
>         auto vec3f =3D v(0.74f, 0.74f, 0.f);
>         float s =3D dot(vec3f, v{1.0f, 0.0f, 0.0f});
> With a suitably-defined "v" function somewhere that operates like
> make_tuple?
> Why does it need to be an UDL?


I did acknowledge that exact possibility (a 'make'-like function with a
terse name) as a current workaround; the essence of my response was that
much the same argument could be made against even having the feature of
UDLs in the language, but that's a done deal, so evidently the committee
did see some use for suffixes as opposed to named constructors or make-
functions for at least simple user-defined types.  I could understand,
though, if introducing the more general brace-initilaizer syntax takes it
outside the intended scope and motivation for UDLs.

I realize the examples I gave weren't very motivating for the feature of
having a brace-initializer syntax for UDLs, with arbitrary type arguments.
The Vector example, for instance, has viable workarounds in the current
standard, as responses thus far have shown.

I am still curious though, aside from solving the particular examples I
gave, what the objections would be to the proposed extensions to the UDL
facility itself.  But maybe the point of the responses is that, given the
examples, we don't see sufficient motivation for it.

-Andy

On Mon, Dec 5, 2016 at 2:15 PM, Thiago Macieira <thiago@macieira.org> wrote=
:

> Em domingo, 4 de dezembro de 2016, =C3=A0s 23:10:51 PST, Anthony Hall esc=
reveu:
> > auto vec3f =3D {0.74f, 0.74f, 0.0f}_v;
> > float s =3D dot( vec3f, {1.0f, 0.0f, 0.0f}_v );
>
> Why can't you write:
>
>         auto vec3f =3D v(0.74f, 0.74f, 0.f);
>         float s =3D dot(vec3f, v{1.0f, 0.0f, 0.0f});
>
> With a suitably-defined "v" function somewhere that operates like
> make_tuple?
>
> Why does it need to be an UDL?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/BZ5kC9_B3i8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/1761696.CnmSmY9c4V%40tjmaciei-mobl1.
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAApgN58Zr92Zv6SEKJOetzmX1afnKPTqxTPt6tM63_SUWCk=
pLA%40mail.gmail.com.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span st=
yle=3D"font-size:12.8px">Why can&#39;t you write:</span><br style=3D"font-s=
ize:12.8px"><span style=3D"font-size:12.8px">=C2=A0 =C2=A0 =C2=A0 =C2=A0 au=
to vec3f =3D v(0.74f, 0.74f, 0.f);<br></span><span style=3D"font-size:12.8p=
x">=C2=A0 =C2=A0 =C2=A0 =C2=A0 float s =3D dot(vec3f, v{1.0f, 0.0f, 0.0f});=
</span><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">With=
 a suitably-defined &quot;v&quot; function somewhere that operates like mak=
e_tuple?</span><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8=
px">Why does it need to be an UDL?</span></blockquote><div><br></div><div>I=
 did acknowledge that exact possibility (a &#39;make&#39;-like function wit=
h a terse name) as a current workaround; the essence of my response was tha=
t much the same argument could be made against even having the feature of U=
DLs in the language, but that&#39;s a done deal, so evidently the committee=
 did see some use for suffixes as opposed to named constructors or make- fu=
nctions for at least simple user-defined types.=C2=A0 I could understand, t=
hough, if introducing the more general brace-initilaizer syntax takes it ou=
tside the intended scope and motivation for UDLs.</div><div><br></div><div>=
I realize the examples I gave weren&#39;t very motivating for the feature o=
f having a brace-initializer syntax for UDLs, with arbitrary type arguments=
..=C2=A0 The Vector example, for instance, has viable workarounds in the cur=
rent standard, as responses thus far have shown.<br><br>I am still curious =
though, aside from solving the particular examples I gave, what the objecti=
ons would be to the proposed extensions to the UDL facility itself.=C2=A0 B=
ut maybe the point of the responses is that, given the examples, we don&#39=
;t see sufficient motivation for it.</div><div><br></div><div>-Andy</div></=
div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Dec 5=
, 2016 at 2:15 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto:=
thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><span class=3D"">Em domingo, 4 de d=
ezembro de 2016, =C3=A0s 23:10:51 PST, Anthony Hall escreveu:<br>
&gt; auto vec3f =3D {0.74f, 0.74f, 0.0f}_v;<br>
&gt; float s =3D dot( vec3f, {1.0f, 0.0f, 0.0f}_v );<br>
<br>
</span>Why can&#39;t you write:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto vec3f =3D v(0.74f, 0.74f, 0.f);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 float s =3D dot(vec3f, v{1.0f, 0.0f, 0.0f});<br=
>
<br>
With a suitably-defined &quot;v&quot; function somewhere that operates like=
 make_tuple?<br>
<br>
Why does it need to be an UDL?<br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<span class=3D""><br>
--<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/BZ5kC9_B3i8/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/topic/s=
td-<wbr>proposals/BZ5kC9_B3i8/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/1761696.CnmSmY9c4V%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/1761696.CnmSmY9c4V%<wbr>40tjmaciei-=
mobl1</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAApgN58Zr92Zv6SEKJOetzmX1afnKPTqxTPt=
6tM63_SUWCkpLA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAApgN58Zr92Zv6SE=
KJOetzmX1afnKPTqxTPt6tM63_SUWCkpLA%40mail.gmail.com</a>.<br />

--001a11407f5879eb730542f0665d--

.