------=_Part_674_7352303.1353625454747
Content-Type: text/plain; charset=ISO-8859-1

The problem is fairly simple: It's too difficult to implement proxy objects
in C++ right now.

In C++11, I feel that, with type deduction, we should move away from
concrete types and move to deal with only the interfaces they offer.

The primary difficulty here comes when we deal with auto and decltype.
These functions, whilst great, break any attempts we make to offer an
interface-based substitute. Especially consider the case of expression
templates- currently, they do not really work, as you cannot do

auto a = b + c + d;

where the author of a has invoked expression templates to reduce
complexity. Nor could you do

std::vector<decltype(b + c)> vec;

Thus, I propose an "automatic" operator. The automatic operator is invoked
whenever type deduction is used, including decltype or auto, or whenever a
requested member is not available. In addition, when overload resolution or
template specialization is considered, an object which has an automatic
operator is considered as the return type of that automatic operator, *not* as
it's actual type, unless the actual type is specified directly and
unambiguously with no intermediate conversions (except reference binding,
cv qualifiers). The sample syntax I am showing is auto operator T(), which
I consider to be the best choice, but it's a bit of a bikeshed issue as
it's only used once at the point of definition and thus not especially
significant.

For now, I think it would be simplest to define that each type may only
have one automatic operator, except that the operator may be overloaded by
cv-qualifier or ref-qualifer- that is, any expression e involving any type
T may automatically convert to one, and only one, type.

For example, consider an expression template. Now, in our proxy objects, we
can define an automatic conversion.

class proxy {
    auto operator real_type() && { return evaluate(); }
};

This would permit us to write

std::vector<decltype(b + c)> vec;

where vec's template argument is actually real_type, not proxy. In
addition, we can perform operations like (b + c).size(); without having to
explicitly forward each and every member in a non-generic and
unmaintainable fashion. Finally, we can introduce new types which are
indistinguishable from previous types, enabling improvements to areas of
the Standard not previously accessible. For example, consider basic_string.
Right now, we could not change that specification to support expression
templates, which offer improved complexity even over move semantics,
because that would break code which relied on type deduction or template
specialization for the return type of operator+. However, if the wording
were changed to say that the return value of operator+ offers the same
interface as basic_string, it would now be possible for implementations to
replace it with an optimized version without breaking existing code, by
having an automatic conversion. In fact, such a wording change may not even
be necessary, since the change would not be observable and thus falls under
the as-if rule.

It would also permit relaxed requirements in some areas of the Standard.
For example, consider operator[] for map and unordered_map. By returning a
value which has an automatic conversion to value&, we can effectively
overload for read or write separately- and there have been many requests
for, for example, an operator[]=. This proposal would effectively solve
that problem, as well as, say, operator*= (for *it = x) for iterators. The
difference between what can be accomplished now, and an implementation
using an automatic conversion, is that it would be impossible to write a
generic proxy which also supported members- such as it->x.

struct proxy {
    auto operator value&() {
        // read: if T is not default-constructible, throw if not found.
    }
    template<typename T> value& operator=(T&& arg) {
        // write: don't require default-constructible
    }
};

Now, assuming a proxy operator[], we can write

map[key].f();

and

map[key] = val;

without having to require default-constructibility, and potentially
improving performance by avoiding default-construction and then assignment.

Finally, we also move a step closer to properties and other similar
mechanisms, since a value of one type can transparently impersonate another.

--




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

The problem is fairly simple: It's too difficult to implement proxy objects=
 in C++ right now.<div><br></div><div>In C++11, I feel that, with type dedu=
ction, we should move away from concrete types and move to deal with only t=
he interfaces they offer.</div><div><br></div><div>The primary difficulty h=
ere comes when we deal with auto and decltype. These functions, whilst grea=
t, break any attempts we make to offer an interface-based substitute. Espec=
ially consider the case of expression templates- currently, they do not rea=
lly work, as you cannot do</div><div><br></div><div><div style=3D"backgroun=
d-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wra=
p: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a=
 </span><font color=3D"#666600"><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> b </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>+</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> d</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span></font></div></code></di=
v><br>where the author of a has invoked expression templates to reduce comp=
lexity. Nor could you do&nbsp;</div><div><br></div><div><div style=3D"backg=
round-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word=
-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div =
class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">vector<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">b </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">+</span><font color=3D"#000000"><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> c</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)&gt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> vec</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">;</span></font></div></code></div><br>T=
hus, I propose an "automatic" operator. The automatic operator is invoked w=
henever type deduction is used, including decltype or auto, or whenever a r=
equested member is not available. In addition, when overload resolution or =
template specialization is considered, an object which has an automatic ope=
rator is considered as the return type of that automatic operator, <i>not</=
i>&nbsp;as it's actual type, unless the actual type is specified directly a=
nd unambiguously with no intermediate conversions (except reference binding=
, cv qualifiers).&nbsp;The sample syntax I am showing is auto operator T(),=
 which I consider to be the best choice, but it's a bit of a bikeshed issue=
 as it's only used once at the point of definition and thus not especially =
significant.</div><div><br></div><div>For now, I think it would be simplest=
 to define that each type may only have one automatic operator, except that=
 the operator may be overloaded by cv-qualifier or ref-qualifer- that is, a=
ny expression e involving any type T may automatically convert to one, and =
only one, type.</div><div><br></div><div>For example, consider an expressio=
n template. Now, in our proxy objects, we can define an automatic conversio=
n.</div><div><br></div><div>class proxy {</div><div>&nbsp; &nbsp; auto oper=
ator real_type() &amp;&amp; { return evaluate(); }</div><div>};</div><div><=
br></div><div>This would permit us to write</div><div><br></div><div>std::v=
ector&lt;decltype(b + c)&gt; vec;</div><div><br></div><div>where vec's temp=
late argument is actually real_type, not proxy. In addition, we can perform=
 operations like (b + c).size(); without having to explicitly forward each =
and every member in a non-generic and unmaintainable fashion. Finally, we c=
an introduce new types which are indistinguishable from previous types, ena=
bling improvements to areas of the Standard not previously accessible. For =
example, consider basic_string. Right now, we could not change that specifi=
cation to support expression templates, which offer improved complexity eve=
n over move semantics, because that would break code which relied on type d=
eduction or template specialization for the return type of operator+. Howev=
er, if the wording were changed to say that the return value of operator+ o=
ffers the same interface as basic_string, it would now be possible for impl=
ementations to replace it with an optimized version without breaking existi=
ng code, by having an automatic conversion. In fact, such a wording change =
may not even be necessary, since the change would not be observable and thu=
s falls under the as-if rule.</div><div><br></div><div>It would also permit=
 relaxed requirements in some areas of the Standard. For example, consider =
operator[] for map and unordered_map. By returning a value which has an aut=
omatic conversion to value&amp;, we can effectively overload for read or wr=
ite separately- and there have been many requests for, for example, an oper=
ator[]=3D. This proposal would effectively solve that problem, as well as, =
say, operator*=3D (for *it =3D x) for iterators. The difference between wha=
t can be accomplished now, and an implementation using an automatic convers=
ion, is that it would be impossible to write a generic proxy which also sup=
ported members- such as it-&gt;x.</div><div><br></div><div>struct proxy {</=
div><div>&nbsp; &nbsp; auto operator value&amp;() {&nbsp;</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp; // read: if T is not default-constructible, throw if n=
ot found.</div><div>&nbsp; &nbsp; }</div><div>&nbsp; &nbsp; template&lt;typ=
ename T&gt; value&amp; operator=3D(T&amp;&amp; arg) {&nbsp;</div><div>&nbsp=
; &nbsp; &nbsp; &nbsp; // write: don't require default-constructible&nbsp;<=
/div><div>&nbsp; &nbsp; }</div><div>};</div><div><br></div><div>Now, assumi=
ng a proxy operator[], we can write</div><div><br></div><div>map[key].f();<=
/div><div><br></div><div>and</div><div><br></div><div>map[key] =3D val;</di=
v><div><br></div><div>without having to require default-constructibility, a=
nd potentially improving performance by avoiding default-construction and t=
hen assignment.</div><div><br></div><div>Finally, we also move a step close=
r to properties and other similar mechanisms, since a value of one type can=
 transparently impersonate another.</div>

<p></p>

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

------=_Part_674_7352303.1353625454747--

.

------=_Part_113_14829132.1353626196730
Content-Type: text/plain; charset=ISO-8859-1

Fairly interesting. However, this is going to lead to something akin to the
problems with overriding operator&

With operator& overridden, library writers are going to have to use
`std::addressof<>()` in their code to avoid unintentionally executing
unknown user logic or even just to avoid invoking ADL on the template (and
all types named in it's template arguments etc; the compilation time
implications of this are a bit off topic, but shallow instantiation can
cause code to fail to compile where it would not need to fail).

So, how would you propose people (presumably library writers) would
_override_ this mechanism and get the _actual_ decltype of an 'expression
template' which was auto-type-deduction-enabled?

On Friday, November 23, 2012 12:04:15 AM UTC+1, DeadMG wrote:
>
> The problem is fairly simple: It's too difficult to implement proxy
> objects in C++ right now.
>
> In C++11, I feel that, with type deduction, we should move away from
> concrete types and move to deal with only the interfaces they offer.
>
> The primary difficulty here comes when we deal with auto and decltype.
> These functions, whilst great, break any attempts we make to offer an
> interface-based substitute. Especially consider the case of expression
> templates- currently, they do not really work, as you cannot do
>
> auto a = b + c + d;
>
> where the author of a has invoked expression templates to reduce
> complexity. Nor could you do
>
> std::vector<decltype(b + c)> vec;
>
> Thus, I propose an "automatic" operator. The automatic operator is invoked
> whenever type deduction is used, including decltype or auto, or whenever a
> requested member is not available. In addition, when overload resolution or
> template specialization is considered, an object which has an automatic
> operator is considered as the return type of that automatic operator, *not
> * as it's actual type, unless the actual type is specified directly and
> unambiguously with no intermediate conversions (except reference binding,
> cv qualifiers). The sample syntax I am showing is auto operator T(), which
> I consider to be the best choice, but it's a bit of a bikeshed issue as
> it's only used once at the point of definition and thus not especially
> significant.
>
> For now, I think it would be simplest to define that each type may only
> have one automatic operator, except that the operator may be overloaded by
> cv-qualifier or ref-qualifer- that is, any expression e involving any type
> T may automatically convert to one, and only one, type.
>
> For example, consider an expression template. Now, in our proxy objects,
> we can define an automatic conversion.
>
> class proxy {
>     auto operator real_type() && { return evaluate(); }
> };
>
> This would permit us to write
>
> std::vector<decltype(b + c)> vec;
>
> where vec's template argument is actually real_type, not proxy. In
> addition, we can perform operations like (b + c).size(); without having to
> explicitly forward each and every member in a non-generic and
> unmaintainable fashion. Finally, we can introduce new types which are
> indistinguishable from previous types, enabling improvements to areas of
> the Standard not previously accessible. For example, consider basic_string.
> Right now, we could not change that specification to support expression
> templates, which offer improved complexity even over move semantics,
> because that would break code which relied on type deduction or template
> specialization for the return type of operator+. However, if the wording
> were changed to say that the return value of operator+ offers the same
> interface as basic_string, it would now be possible for implementations to
> replace it with an optimized version without breaking existing code, by
> having an automatic conversion. In fact, such a wording change may not even
> be necessary, since the change would not be observable and thus falls under
> the as-if rule.
>
> It would also permit relaxed requirements in some areas of the Standard.
> For example, consider operator[] for map and unordered_map. By returning a
> value which has an automatic conversion to value&, we can effectively
> overload for read or write separately- and there have been many requests
> for, for example, an operator[]=. This proposal would effectively solve
> that problem, as well as, say, operator*= (for *it = x) for iterators. The
> difference between what can be accomplished now, and an implementation
> using an automatic conversion, is that it would be impossible to write a
> generic proxy which also supported members- such as it->x.
>
> struct proxy {
>     auto operator value&() {
>         // read: if T is not default-constructible, throw if not found.
>     }
>     template<typename T> value& operator=(T&& arg) {
>         // write: don't require default-constructible
>     }
> };
>
> Now, assuming a proxy operator[], we can write
>
> map[key].f();
>
> and
>
> map[key] = val;
>
> without having to require default-constructibility, and potentially
> improving performance by avoiding default-construction and then assignment.
>
> Finally, we also move a step closer to properties and other similar
> mechanisms, since a value of one type can transparently impersonate another.
>

--




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

<div>Fairly interesting. However, this is going to lead to something akin t=
o the problems with overriding operator&amp;<br></div><div><br></div><div>W=
ith operator&amp; overridden, library writers are going to have to use `std=
::addressof&lt;&gt;()` in their code to avoid unintentionally executing unk=
nown user logic or even just to avoid invoking ADL on the template (and all=
 types named in it's template arguments etc; the compilation time implicati=
ons of this are a bit off topic, but shallow instantiation can cause code t=
o fail to compile where it would not need to fail).&nbsp;</div><div><br></d=
iv><div>So, how would you propose people (presumably library writers) would=
 _override_ this mechanism and get the _actual_ decltype of an 'expression =
template' which was auto-type-deduction-enabled?</div><br>On Friday, Novemb=
er 23, 2012 12:04:15 AM UTC+1, DeadMG wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">The problem is fairly simple: It's too difficult to implement=
 proxy objects in C++ right now.<div><br></div><div>In C++11, I feel that, =
with type deduction, we should move away from concrete types and move to de=
al with only the interfaces they offer.</div><div><br></div><div>The primar=
y difficulty here comes when we deal with auto and decltype. These function=
s, whilst great, break any attempts we make to offer an interface-based sub=
stitute. Especially consider the case of expression templates- currently, t=
hey do not really work, as you cannot do</div><div><br></div><div><div styl=
e=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187);wo=
rd-wrap:break-word"><code><div><span style=3D"color:#008">auto</span><span =
style=3D"color:#000"> a </span><font color=3D"#666600"><span style=3D"color=
:#660">=3D</span><span style=3D"color:#000"> b </span><span style=3D"color:=
#660">+</span><span style=3D"color:#000"> c </span><span style=3D"color:#66=
0">+</span><span style=3D"color:#000"> d</span><span style=3D"color:#660">;=
</span></font></div></code></div><br>where the author of a has invoked expr=
ession templates to reduce complexity. Nor could you do&nbsp;</div><div><br=
></div><div><div style=3D"background-color:rgb(250,250,250);border:1px soli=
d rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D"color:#0=
00">std</span><span style=3D"color:#660">::</span><span style=3D"color:#000=
">vector</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#=
008">decltype</span><span style=3D"color:#660">(</span><span style=3D"color=
:#000">b </span><span style=3D"color:#660">+</span><font color=3D"#000000">=
<span style=3D"color:#000"> c</span><span style=3D"color:#660">)&gt;</span>=
<span style=3D"color:#000"> vec</span><span style=3D"color:#660">;</span></=
font></div></code></div><br>Thus, I propose an "automatic" operator. The au=
tomatic operator is invoked whenever type deduction is used, including decl=
type or auto, or whenever a requested member is not available. In addition,=
 when overload resolution or template specialization is considered, an obje=
ct which has an automatic operator is considered as the return type of that=
 automatic operator, <i>not</i>&nbsp;as it's actual type, unless the actual=
 type is specified directly and unambiguously with no intermediate conversi=
ons (except reference binding, cv qualifiers).&nbsp;The sample syntax I am =
showing is auto operator T(), which I consider to be the best choice, but i=
t's a bit of a bikeshed issue as it's only used once at the point of defini=
tion and thus not especially significant.</div><div><br></div><div>For now,=
 I think it would be simplest to define that each type may only have one au=
tomatic operator, except that the operator may be overloaded by cv-qualifie=
r or ref-qualifer- that is, any expression e involving any type T may autom=
atically convert to one, and only one, type.</div><div><br></div><div>For e=
xample, consider an expression template. Now, in our proxy objects, we can =
define an automatic conversion.</div><div><br></div><div>class proxy {</div=
><div>&nbsp; &nbsp; auto operator real_type() &amp;&amp; { return evaluate(=
); }</div><div>};</div><div><br></div><div>This would permit us to write</d=
iv><div><br></div><div>std::vector&lt;decltype(b + c)&gt; vec;</div><div><b=
r></div><div>where vec's template argument is actually real_type, not proxy=
.. In addition, we can perform operations like (b + c).size(); without havin=
g to explicitly forward each and every member in a non-generic and unmainta=
inable fashion. Finally, we can introduce new types which are indistinguish=
able from previous types, enabling improvements to areas of the Standard no=
t previously accessible. For example, consider basic_string. Right now, we =
could not change that specification to support expression templates, which =
offer improved complexity even over move semantics, because that would brea=
k code which relied on type deduction or template specialization for the re=
turn type of operator+. However, if the wording were changed to say that th=
e return value of operator+ offers the same interface as basic_string, it w=
ould now be possible for implementations to replace it with an optimized ve=
rsion without breaking existing code, by having an automatic conversion. In=
 fact, such a wording change may not even be necessary, since the change wo=
uld not be observable and thus falls under the as-if rule.</div><div><br></=
div><div>It would also permit relaxed requirements in some areas of the Sta=
ndard. For example, consider operator[] for map and unordered_map. By retur=
ning a value which has an automatic conversion to value&amp;, we can effect=
ively overload for read or write separately- and there have been many reque=
sts for, for example, an operator[]=3D. This proposal would effectively sol=
ve that problem, as well as, say, operator*=3D (for *it =3D x) for iterator=
s. The difference between what can be accomplished now, and an implementati=
on using an automatic conversion, is that it would be impossible to write a=
 generic proxy which also supported members- such as it-&gt;x.</div><div><b=
r></div><div>struct proxy {</div><div>&nbsp; &nbsp; auto operator value&amp=
;() {&nbsp;</div><div>&nbsp; &nbsp; &nbsp; &nbsp; // read: if T is not defa=
ult-constructible, throw if not found.</div><div>&nbsp; &nbsp; }</div><div>=
&nbsp; &nbsp; template&lt;typename T&gt; value&amp; operator=3D(T&amp;&amp;=
 arg) {&nbsp;</div><div>&nbsp; &nbsp; &nbsp; &nbsp; // write: don't require=
 default-constructible&nbsp;</div><div>&nbsp; &nbsp; }</div><div>};</div><d=
iv><br></div><div>Now, assuming a proxy operator[], we can write</div><div>=
<br></div><div>map[key].f();</div><div><br></div><div>and</div><div><br></d=
iv><div>map[key] =3D val;</div><div><br></div><div>without having to requir=
e default-constructibility, and potentially improving performance by avoidi=
ng default-construction and then assignment.</div><div><br></div><div>Final=
ly, we also move a step closer to properties and other similar mechanisms, =
since a value of one type can transparently impersonate another.</div></blo=
ckquote>

<p></p>

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

------=_Part_113_14829132.1353626196730--

.

------=_Part_85_26102504.1353627102936
Content-Type: text/plain; charset=ISO-8859-1

You can't. That's the entire purpose of the feature. If you are a library
writer without previous explicit knowledge of that type, then it is
completely non-observable whether you are dealing with a proxy or a
non-proxy- in fact, you would never, ever deal with the proxy object,
either implicitly or explicitly, because if a proxy was passed to your
function, it would be automatically converted to a real_type.

--




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

You can't. That's the entire purpose of the feature. If you are a library w=
riter without previous explicit knowledge of that type, then it is complete=
ly non-observable whether you are dealing with a proxy or a non-proxy- in f=
act, you would never, ever deal with the proxy object, either implicitly or=
 explicitly, because if a proxy was passed to your function, it would be au=
tomatically converted to a real_type.

<p></p>

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

------=_Part_85_26102504.1353627102936--

.

------=_Part_813_27101847.1353630126862
Content-Type: text/plain; charset=ISO-8859-1

On Friday, November 23, 2012 12:31:43 AM UTC+1, DeadMG wrote:
>
> You can't. That's the entire purpose of the feature. If you are a library
> writer without previous explicit knowledge of that type, then it is
> completely non-observable whether you are dealing with a proxy or a
> non-proxy- in fact, you would never, ever deal with the proxy object,
> either implicitly or explicitly, because if a proxy was passed to your
> function, it would be automatically converted to a real_type.


Hmm. That might be a sound strategy. Certainly looks the simplest.

I think I had a brainfart relating to ADL for user-definef conversion
operators in general. Conversion ops can't be 'friend' declared, so in fact
the compiler wouldn't need to shallow instantiate any ADL associated type
namespaces to resolve any 'auto' conversion operator.

Let's see what others have to say about this proposal


--




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

On Friday, November 23, 2012 12:31:43 AM UTC+1, DeadMG wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">You can't. That's the entire purpose of the =
feature. If you are a library writer without previous explicit knowledge of=
 that type, then it is completely non-observable whether you are dealing wi=
th a proxy or a non-proxy- in fact, you would never, ever deal with the pro=
xy object, either implicitly or explicitly, because if a proxy was passed t=
o your function, it would be automatically converted to a real_type.</block=
quote><div><br></div><div>Hmm. That might be a sound strategy. Certainly lo=
oks the simplest. </div><div><br></div><div>I think I had a brainfart relat=
ing to ADL for user-definef conversion operators in general. Conversion ops=
 can't be 'friend' declared, so in fact the compiler wouldn't need to shall=
ow instantiate any ADL associated type namespaces to resolve any 'auto' con=
version operator. </div><div><br></div><div>Let's see what others have to s=
ay about this proposal</div><div><br></div><div><br></div>

<p></p>

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

------=_Part_813_27101847.1353630126862--

.

------=_Part_154_3255157.1353630310875
Content-Type: text/plain; charset=ISO-8859-1

I think also, what's important to note is that overloading operator& gives
an* unusual interface*. The whole purpose of this proposal allows *unusual
implementations* to conform to* usual interfaces.* It should significantly
reduce headache, not increase it.

--




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

I think also, what's important to note is that overloading operator& gi=
ves an<i> unusual interface</i>. The whole purpose of this proposal allows =
<i>unusual implementations</i>&nbsp;to conform to<i>&nbsp;usual interfaces.=
</i>&nbsp;It should significantly reduce headache, not increase it.

<p></p>

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

------=_Part_154_3255157.1353630310875--

.

------=_Part_233_16925008.1353633372219
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, November 22, 2012 3:04:15 PM UTC-8, DeadMG wrote:
>
> The problem is fairly simple: It's too difficult to implement proxy
> objects in C++ right now.
>
> In C++11, I feel that, with type deduction, we should move away from
> concrete types and move to deal with only the interfaces they offer.
>
> The primary difficulty here comes when we deal with auto and decltype.
> These functions, whilst great, break any attempts we make to offer an
> interface-based substitute. Especially consider the case of expression
> templates- currently, they do not really work, as you cannot do
>
> auto a = b + c + d;
>
> where the author of a has invoked expression templates to reduce
> complexity. Nor could you do
>
> std::vector<decltype(b + c)> vec;
>
> Thus, I propose an "automatic" operator. The automatic operator is invoked
> whenever type deduction is used, including decltype or auto, or whenever a
> requested member is not available. In addition, when overload resolution or
> template specialization is considered, an object which has an automatic
> operator is considered as the return type of that automatic operator, *not
> * as it's actual type, unless the actual type is specified directly and
> unambiguously with no intermediate conversions (except reference binding,
> cv qualifiers). The sample syntax I am showing is auto operator T(), which
> I consider to be the best choice, but it's a bit of a bikeshed issue as
> it's only used once at the point of definition and thus not especially
> significant.
>
> For now, I think it would be simplest to define that each type may only
> have one automatic operator, except that the operator may be overloaded by
> cv-qualifier or ref-qualifer- that is, any expression e involving any type
> T may automatically convert to one, and only one, type.
>
> For example, consider an expression template. Now, in our proxy objects,
> we can define an automatic conversion.
>
> class proxy {
>     auto operator real_type() && { return evaluate(); }
> };
>

Why not `operator auto()`? Someone out there might actually have a
`real_type`, so we can't keyword it. Plus, this is what it is, right? It's
a conversion operator that is called when `proxy` is *auto*matically
type-deduced. It makes sense to use `auto` in that context.


> This would permit us to write
>
> std::vector<decltype(b + c)> vec;
>
> where vec's template argument is actually real_type, not proxy. In
> addition, we can perform operations like (b + c).size(); without having to
> explicitly forward each and every member in a non-generic and
> unmaintainable fashion. Finally, we can introduce new types which are
> indistinguishable from previous types, enabling improvements to areas of
> the Standard not previously accessible. For example, consider basic_string.
> Right now, we could not change that specification to support expression
> templates, which offer improved complexity even over move semantics,
> because that would break code which relied on type deduction or template
> specialization for the return type of operator+. However, if the wording
> were changed to say that the return value of operator+ offers the same
> interface as basic_string, it would now be possible for implementations to
> replace it with an optimized version without breaking existing code, by
> having an automatic conversion. In fact, such a wording change may not even
> be necessary, since the change would not be observable and thus falls under
> the as-if rule.
>
> It would also permit relaxed requirements in some areas of the Standard.
> For example, consider operator[] for map and unordered_map. By returning a
> value which has an automatic conversion to value&, we can effectively
> overload for read or write separately- and there have been many requests
> for, for example, an operator[]=. This proposal would effectively solve
> that problem, as well as, say, operator*= (for *it = x) for iterators. The
> difference between what can be accomplished now, and an implementation
> using an automatic conversion, is that it would be impossible to write a
> generic proxy which also supported members- such as it->x.
>
> struct proxy {
>     auto operator value&() {
>         // read: if T is not default-constructible, throw if not found.
>     }
>     template<typename T> value& operator=(T&& arg) {
>         // write: don't require default-constructible
>     }
> };
>
> Now, assuming a proxy operator[], we can write
>
> map[key].f();
>
> and
>
> map[key] = val;
>
> without having to require default-constructibility, and potentially
> improving performance by avoiding default-construction and then assignment.
>
> Finally, we also move a step closer to properties and other similar
> mechanisms, since a value of one type can transparently impersonate another.
>

--




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

<br><br>On Thursday, November 22, 2012 3:04:15 PM UTC-8, DeadMG wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">The problem is fairly simple: It's =
too difficult to implement proxy objects in C++ right now.<div><br></div><d=
iv>In C++11, I feel that, with type deduction, we should move away from con=
crete types and move to deal with only the interfaces they offer.</div><div=
><br></div><div>The primary difficulty here comes when we deal with auto an=
d decltype. These functions, whilst great, break any attempts we make to of=
fer an interface-based substitute. Especially consider the case of expressi=
on templates- currently, they do not really work, as you cannot do</div><di=
v><br></div><div><div style=3D"background-color:rgb(250,250,250);border:1px=
 solid rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D"col=
or:#008">auto</span><span style=3D"color:#000"> a </span><font color=3D"#66=
6600"><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> b </=
span><span style=3D"color:#660">+</span><span style=3D"color:#000"> c </spa=
n><span style=3D"color:#660">+</span><span style=3D"color:#000"> d</span><s=
pan style=3D"color:#660">;</span></font></div></code></div><br>where the au=
thor of a has invoked expression templates to reduce complexity. Nor could =
you do&nbsp;</div><div><br></div><div><div style=3D"background-color:rgb(25=
0,250,250);border:1px solid rgb(187,187,187);word-wrap:break-word"><code><d=
iv><span style=3D"color:#000">std</span><span style=3D"color:#660">::</span=
><span style=3D"color:#000">vector</span><span style=3D"color:#660">&lt;</s=
pan><span style=3D"color:#008">decltype</span><span style=3D"color:#660">(<=
/span><span style=3D"color:#000">b </span><span style=3D"color:#660">+</spa=
n><font color=3D"#000000"><span style=3D"color:#000"> c</span><span style=
=3D"color:#660">)&gt;</span><span style=3D"color:#000"> vec</span><span sty=
le=3D"color:#660">;</span></font></div></code></div><br>Thus, I propose an =
"automatic" operator. The automatic operator is invoked whenever type deduc=
tion is used, including decltype or auto, or whenever a requested member is=
 not available. In addition, when overload resolution or template specializ=
ation is considered, an object which has an automatic operator is considere=
d as the return type of that automatic operator, <i>not</i>&nbsp;as it's ac=
tual type, unless the actual type is specified directly and unambiguously w=
ith no intermediate conversions (except reference binding, cv qualifiers).&=
nbsp;The sample syntax I am showing is auto operator T(), which I consider =
to be the best choice, but it's a bit of a bikeshed issue as it's only used=
 once at the point of definition and thus not especially significant.</div>=
<div><br></div><div>For now, I think it would be simplest to define that ea=
ch type may only have one automatic operator, except that the operator may =
be overloaded by cv-qualifier or ref-qualifer- that is, any expression e in=
volving any type T may automatically convert to one, and only one, type.</d=
iv><div><br></div><div>For example, consider an expression template. Now, i=
n our proxy objects, we can define an automatic conversion.</div><div><br><=
/div><div>class proxy {</div><div>&nbsp; &nbsp; auto operator real_type() &=
amp;&amp; { return evaluate(); }</div><div>};</div></blockquote><div><br>Wh=
y not `operator auto()`? Someone out there might actually have a `real_type=
`, so we can't keyword it. Plus, this is what it is, right? It's a conversi=
on operator that is called when `proxy` is <i>auto</i>matically type-deduce=
d. It makes sense to use `auto` in that context.<br>&nbsp;</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div></div><div>This would permit us to w=
rite</div><div><br></div><div>std::vector&lt;decltype(b + c)&gt; vec;</div>=
<div><br></div><div>where vec's template argument is actually real_type, no=
t proxy. In addition, we can perform operations like (b + c).size(); withou=
t having to explicitly forward each and every member in a non-generic and u=
nmaintainable fashion. Finally, we can introduce new types which are indist=
inguishable from previous types, enabling improvements to areas of the Stan=
dard not previously accessible. For example, consider basic_string. Right n=
ow, we could not change that specification to support expression templates,=
 which offer improved complexity even over move semantics, because that wou=
ld break code which relied on type deduction or template specialization for=
 the return type of operator+. However, if the wording were changed to say =
that the return value of operator+ offers the same interface as basic_strin=
g, it would now be possible for implementations to replace it with an optim=
ized version without breaking existing code, by having an automatic convers=
ion. In fact, such a wording change may not even be necessary, since the ch=
ange would not be observable and thus falls under the as-if rule.</div><div=
><br></div><div>It would also permit relaxed requirements in some areas of =
the Standard. For example, consider operator[] for map and unordered_map. B=
y returning a value which has an automatic conversion to value&amp;, we can=
 effectively overload for read or write separately- and there have been man=
y requests for, for example, an operator[]=3D. This proposal would effectiv=
ely solve that problem, as well as, say, operator*=3D (for *it =3D x) for i=
terators. The difference between what can be accomplished now, and an imple=
mentation using an automatic conversion, is that it would be impossible to =
write a generic proxy which also supported members- such as it-&gt;x.</div>=
<div><br></div><div>struct proxy {</div><div>&nbsp; &nbsp; auto operator va=
lue&amp;() {&nbsp;</div><div>&nbsp; &nbsp; &nbsp; &nbsp; // read: if T is n=
ot default-constructible, throw if not found.</div><div>&nbsp; &nbsp; }</di=
v><div>&nbsp; &nbsp; template&lt;typename T&gt; value&amp; operator=3D(T&am=
p;&amp; arg) {&nbsp;</div><div>&nbsp; &nbsp; &nbsp; &nbsp; // write: don't =
require default-constructible&nbsp;</div><div>&nbsp; &nbsp; }</div><div>};<=
/div><div><br></div><div>Now, assuming a proxy operator[], we can write</di=
v><div><br></div><div>map[key].f();</div><div><br></div><div>and</div><div>=
<br></div><div>map[key] =3D val;</div><div><br></div><div>without having to=
 require default-constructibility, and potentially improving performance by=
 avoiding default-construction and then assignment.</div><div><br></div><di=
v>Finally, we also move a step closer to properties and other similar mecha=
nisms, since a value of one type can transparently impersonate another.</di=
v></blockquote>

<p></p>

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

------=_Part_233_16925008.1353633372219--

.

------=_Part_420_8897613.1353633429063
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, November 22, 2012 5:16:12 PM UTC-8, Nicol Bolas wrote:
>
>
>
> On Thursday, November 22, 2012 3:04:15 PM UTC-8, DeadMG wrote:
>>
>> The problem is fairly simple: It's too difficult to implement proxy
>> objects in C++ right now.
>>
>> In C++11, I feel that, with type deduction, we should move away from
>> concrete types and move to deal with only the interfaces they offer.
>>
>> The primary difficulty here comes when we deal with auto and decltype.
>> These functions, whilst great, break any attempts we make to offer an
>> interface-based substitute. Especially consider the case of expression
>> templates- currently, they do not really work, as you cannot do
>>
>> auto a = b + c + d;
>>
>> where the author of a has invoked expression templates to reduce
>> complexity. Nor could you do
>>
>> std::vector<decltype(b + c)> vec;
>>
>> Thus, I propose an "automatic" operator. The automatic operator is
>> invoked whenever type deduction is used, including decltype or auto, or
>> whenever a requested member is not available. In addition, when overload
>> resolution or template specialization is considered, an object which has an
>> automatic operator is considered as the return type of that automatic
>> operator, *not* as it's actual type, unless the actual type is specified
>> directly and unambiguously with no intermediate conversions (except
>> reference binding, cv qualifiers). The sample syntax I am showing is auto
>> operator T(), which I consider to be the best choice, but it's a bit of a
>> bikeshed issue as it's only used once at the point of definition and thus
>> not especially significant.
>>
>> For now, I think it would be simplest to define that each type may only
>> have one automatic operator, except that the operator may be overloaded by
>> cv-qualifier or ref-qualifer- that is, any expression e involving any type
>> T may automatically convert to one, and only one, type.
>>
>> For example, consider an expression template. Now, in our proxy objects,
>> we can define an automatic conversion.
>>
>> class proxy {
>>     auto operator real_type() && { return evaluate(); }
>> };
>>
>
> Why not `operator auto()`? Someone out there might actually have a
> `real_type`, so we can't keyword it. Plus, this is what it is, right? It's
> a conversion operator that is called when `proxy` is *auto*matically
> type-deduced. It makes sense to use `auto` in that context.
>

I forgot to mention that the return type would be the one that is the type
that it would be deduced as.


>
>
>> This would permit us to write
>>
>> std::vector<decltype(b + c)> vec;
>>
>> where vec's template argument is actually real_type, not proxy. In
>> addition, we can perform operations like (b + c).size(); without having to
>> explicitly forward each and every member in a non-generic and
>> unmaintainable fashion. Finally, we can introduce new types which are
>> indistinguishable from previous types, enabling improvements to areas of
>> the Standard not previously accessible. For example, consider basic_string.
>> Right now, we could not change that specification to support expression
>> templates, which offer improved complexity even over move semantics,
>> because that would break code which relied on type deduction or template
>> specialization for the return type of operator+. However, if the wording
>> were changed to say that the return value of operator+ offers the same
>> interface as basic_string, it would now be possible for implementations to
>> replace it with an optimized version without breaking existing code, by
>> having an automatic conversion. In fact, such a wording change may not even
>> be necessary, since the change would not be observable and thus falls under
>> the as-if rule.
>>
>> It would also permit relaxed requirements in some areas of the Standard.
>> For example, consider operator[] for map and unordered_map. By returning a
>> value which has an automatic conversion to value&, we can effectively
>> overload for read or write separately- and there have been many requests
>> for, for example, an operator[]=. This proposal would effectively solve
>> that problem, as well as, say, operator*= (for *it = x) for iterators. The
>> difference between what can be accomplished now, and an implementation
>> using an automatic conversion, is that it would be impossible to write a
>> generic proxy which also supported members- such as it->x.
>>
>> struct proxy {
>>     auto operator value&() {
>>         // read: if T is not default-constructible, throw if not found.
>>     }
>>     template<typename T> value& operator=(T&& arg) {
>>         // write: don't require default-constructible
>>     }
>> };
>>
>> Now, assuming a proxy operator[], we can write
>>
>> map[key].f();
>>
>> and
>>
>> map[key] = val;
>>
>> without having to require default-constructibility, and potentially
>> improving performance by avoiding default-construction and then assignment.
>>
>> Finally, we also move a step closer to properties and other similar
>> mechanisms, since a value of one type can transparently impersonate another.
>>
>

--




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

<br><br>On Thursday, November 22, 2012 5:16:12 PM UTC-8, Nicol Bolas wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Thursday, November =
22, 2012 3:04:15 PM UTC-8, DeadMG wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex">The problem is fairly simple: It's too difficult to implement proxy ob=
jects in C++ right now.<div><br></div><div>In C++11, I feel that, with type=
 deduction, we should move away from concrete types and move to deal with o=
nly the interfaces they offer.</div><div><br></div><div>The primary difficu=
lty here comes when we deal with auto and decltype. These functions, whilst=
 great, break any attempts we make to offer an interface-based substitute. =
Especially consider the case of expression templates- currently, they do no=
t really work, as you cannot do</div><div><br></div><div><div style=3D"back=
ground-color:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:b=
reak-word"><code><div><span style=3D"color:#008">auto</span><span style=3D"=
color:#000"> a </span><font color=3D"#666600"><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> b </span><span style=3D"color:#660">+=
</span><span style=3D"color:#000"> c </span><span style=3D"color:#660">+</s=
pan><span style=3D"color:#000"> d</span><span style=3D"color:#660">;</span>=
</font></div></code></div><br>where the author of a has invoked expression =
templates to reduce complexity. Nor could you do&nbsp;</div><div><br></div>=
<div><div style=3D"background-color:rgb(250,250,250);border:1px solid rgb(1=
87,187,187);word-wrap:break-word"><code><div><span style=3D"color:#000">std=
</span><span style=3D"color:#660">::</span><span style=3D"color:#000">vecto=
r</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">de=
cltype</span><span style=3D"color:#660">(</span><span style=3D"color:#000">=
b </span><span style=3D"color:#660">+</span><font color=3D"#000000"><span s=
tyle=3D"color:#000"> c</span><span style=3D"color:#660">)&gt;</span><span s=
tyle=3D"color:#000"> vec</span><span style=3D"color:#660">;</span></font></=
div></code></div><br>Thus, I propose an "automatic" operator. The automatic=
 operator is invoked whenever type deduction is used, including decltype or=
 auto, or whenever a requested member is not available. In addition, when o=
verload resolution or template specialization is considered, an object whic=
h has an automatic operator is considered as the return type of that automa=
tic operator, <i>not</i>&nbsp;as it's actual type, unless the actual type i=
s specified directly and unambiguously with no intermediate conversions (ex=
cept reference binding, cv qualifiers).&nbsp;The sample syntax I am showing=
 is auto operator T(), which I consider to be the best choice, but it's a b=
it of a bikeshed issue as it's only used once at the point of definition an=
d thus not especially significant.</div><div><br></div><div>For now, I thin=
k it would be simplest to define that each type may only have one automatic=
 operator, except that the operator may be overloaded by cv-qualifier or re=
f-qualifer- that is, any expression e involving any type T may automaticall=
y convert to one, and only one, type.</div><div><br></div><div>For example,=
 consider an expression template. Now, in our proxy objects, we can define =
an automatic conversion.</div><div><br></div><div>class proxy {</div><div>&=
nbsp; &nbsp; auto operator real_type() &amp;&amp; { return evaluate(); }</d=
iv><div>};</div></blockquote><div><br>Why not `operator auto()`? Someone ou=
t there might actually have a `real_type`, so we can't keyword it. Plus, th=
is is what it is, right? It's a conversion operator that is called when `pr=
oxy` is <i>auto</i>matically type-deduced. It makes sense to use `auto` in =
that context.<br></div></blockquote><div><br>I forgot to mention that the r=
eturn type would be the one that is the type that it would be deduced as.<b=
r>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>&nbsp;</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div></div><div>This would permit =
us to write</div><div><br></div><div>std::vector&lt;decltype(b + c)&gt; vec=
;</div><div><br></div><div>where vec's template argument is actually real_t=
ype, not proxy. In addition, we can perform operations like (b + c).size();=
 without having to explicitly forward each and every member in a non-generi=
c and unmaintainable fashion. Finally, we can introduce new types which are=
 indistinguishable from previous types, enabling improvements to areas of t=
he Standard not previously accessible. For example, consider basic_string. =
Right now, we could not change that specification to support expression tem=
plates, which offer improved complexity even over move semantics, because t=
hat would break code which relied on type deduction or template specializat=
ion for the return type of operator+. However, if the wording were changed =
to say that the return value of operator+ offers the same interface as basi=
c_string, it would now be possible for implementations to replace it with a=
n optimized version without breaking existing code, by having an automatic =
conversion. In fact, such a wording change may not even be necessary, since=
 the change would not be observable and thus falls under the as-if rule.</d=
iv><div><br></div><div>It would also permit relaxed requirements in some ar=
eas of the Standard. For example, consider operator[] for map and unordered=
_map. By returning a value which has an automatic conversion to value&amp;,=
 we can effectively overload for read or write separately- and there have b=
een many requests for, for example, an operator[]=3D. This proposal would e=
ffectively solve that problem, as well as, say, operator*=3D (for *it =3D x=
) for iterators. The difference between what can be accomplished now, and a=
n implementation using an automatic conversion, is that it would be impossi=
ble to write a generic proxy which also supported members- such as it-&gt;x=
..</div><div><br></div><div>struct proxy {</div><div>&nbsp; &nbsp; auto oper=
ator value&amp;() {&nbsp;</div><div>&nbsp; &nbsp; &nbsp; &nbsp; // read: if=
 T is not default-constructible, throw if not found.</div><div>&nbsp; &nbsp=
; }</div><div>&nbsp; &nbsp; template&lt;typename T&gt; value&amp; operator=
=3D(T&amp;&amp; arg) {&nbsp;</div><div>&nbsp; &nbsp; &nbsp; &nbsp; // write=
: don't require default-constructible&nbsp;</div><div>&nbsp; &nbsp; }</div>=
<div>};</div><div><br></div><div>Now, assuming a proxy operator[], we can w=
rite</div><div><br></div><div>map[key].f();</div><div><br></div><div>and</d=
iv><div><br></div><div>map[key] =3D val;</div><div><br></div><div>without h=
aving to require default-constructibility, and potentially improving perfor=
mance by avoiding default-construction and then assignment.</div><div><br><=
/div><div>Finally, we also move a step closer to properties and other simil=
ar mechanisms, since a value of one type can transparently impersonate anot=
her.</div></blockquote></blockquote>

<p></p>

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

------=_Part_420_8897613.1353633429063--

.

------=_Part_193_7389102.1353633712446
Content-Type: text/plain; charset=ISO-8859-1

On Friday, November 23, 2012 2:16:12 AM UTC+1, Nicol Bolas wrote

> Why not `operator auto()`? Someone out there might actually have a
> `real_type`, so we can't keyword it. Plus, this is what it is, right? It's
> a conversion operator that is called when `proxy` is *auto*matically
> type-deduced. It makes sense to use `auto` in that context.
>

I don't think that `real_type` was meant as anything other than a
placeholder for some type.

--




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

On Friday, November 23, 2012 2:16:12 AM UTC+1, Nicol Bolas wrote<br><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div>Why not `operator auto()`? Someo=
ne out there might actually have a `real_type`, so we can't keyword it. Plu=
s, this is what it is, right? It's a conversion operator that is called whe=
n `proxy` is <i>auto</i>matically type-deduced. It makes sense to use `auto=
` in that context. <br></div></blockquote><div><br>I don't think that `real=
_type` was meant as anything other than a placeholder for some type. <br></=
div>

<p></p>

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

------=_Part_193_7389102.1353633712446--

.

------=_Part_1120_2846848.1353634026800
Content-Type: text/plain; charset=ISO-8859-1

Yeah. real_type is not a keyword or anything like that, it's any type or
type-expression-thingy like std::remove_pointer<T>::type (I forget the
Standardese).

Why not `operator auto()`?


Because that doesn't tell the compiler what the intended conversion target
is, only that you wish to convert. That's not enough information to perform
the conversion.

--




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

Yeah. real_type is not a keyword or anything like that, it's any type or ty=
pe-expression-thingy like std::remove_pointer&lt;T&gt;::type (I forget the =
Standardese).<div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, =
204, 204); border-left-style: solid; padding-left: 1ex;">Why not `operator =
auto()`?</blockquote><div><br></div><div>Because that doesn't tell the comp=
iler what the intended conversion target is, only that you wish to convert.=
 That's not enough information to perform the conversion.&nbsp;</div>

<p></p>

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

------=_Part_1120_2846848.1353634026800--

.

------=_Part_1464_28623640.1353635826219
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, November 22, 2012 5:27:07 PM UTC-8, DeadMG wrote:
>
> Yeah. real_type is not a keyword or anything like that, it's any type or
> type-expression-thingy like std::remove_pointer<T>::type (I forget the
> Standardese).
>
> Why not `operator auto()`?
>
>
> Because that doesn't tell the compiler what the intended conversion target
> is, only that you wish to convert. That's not enough information to perform
> the conversion.
>

The concern is that `auto operator <insert typename here>() {...}` looks
very much like `auto operator +() {...}`, which mean two very different
things. If we have auto-deduced return values, then `auto operator
<something>` should mean automatically deducing the return value of an
`operator <something>`.

Grammatically it should parse, since the `<something>` is a typename rather
than a proper operator name. But from a user perspective, it looks similar
yet behaves differently.

Also, my way lets you do this:

auto operator auto() {return DeduceTheTypeOfThis();}

Or, a more real example:

auto operator auto() {return (std::string)(*this);}

This would invoke the conversion constructor for `this`, or any implicit
constructors for `std::string`. And I don't have to type the typename
multiple times.

So if I have some expression type `Expr`, and I have some value-type, I can
just do this:

auto operator auto() {return (value_type)(*this);}

I can put that conversion into either `value_type` or `Expr`, as I see fit.
And again, I won't have to

Having it be `operator auto` means that it's an operator that's
specifically invoked for type-deduction contexts. It also allows you to
neatly duck issues like:

auto operator std::string() {...}
auto operator int() {...}

Because you can only declare `operator auto` once. Your way would require
special language that says that you can only have an single conversion
operator declared with `auto`.

I just think it's more clear having it be `operator auto` rather than `auto
operator`.

--




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

<br><br>On Thursday, November 22, 2012 5:27:07 PM UTC-8, DeadMG wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">Yeah. real_type is not a keyword or=
 anything like that, it's any type or type-expression-thingy like std::remo=
ve_pointer&lt;T&gt;::type (I forget the Standardese).<div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex">Why not `operator auto()`?</blockquote><div><br></div><div>Becaus=
e that doesn't tell the compiler what the intended conversion target is, on=
ly that you wish to convert. That's not enough information to perform the c=
onversion.&nbsp;</div></blockquote><div><br>The concern is that `auto opera=
tor &lt;insert typename here&gt;() {...}` looks very much like `auto operat=
or +() {...}`, which mean two very different things. If we have auto-deduce=
d return values, then `auto operator &lt;something&gt;` should mean automat=
ically deducing the return value of an `operator &lt;something&gt;`.<br><br=
>Grammatically it should parse, since the `&lt;something&gt;` is a typename=
 rather than a proper operator name. But from a user perspective, it looks =
similar yet behaves differently.<br><br>Also, my way lets you do this:<br><=
br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250)=
; border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px;=
 word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprett=
yprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Deduc=
eTheTypeOfThis</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">();}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span></div></code></div><br>Or, a more real example:<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">operator</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">auto</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">{</span><span style=3D"color: #008;" class=3D"styled-by-prettify">retur=
n</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">string</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)(*</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">this</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">);}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span></div></code></div><br>This would invoke the conversi=
on constructor for `this`, or any implicit constructors for `std::string`. =
And I don't have to type the typename multiple times.<br><br>So if I have s=
ome expression type `Expr`, and I have some value-type, I can just do this:=
<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,=
 250); border-color: rgb(187, 187, 187); border-style: solid; border-width:=
 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"sub=
prettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">operator</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">value_t=
ype</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)(*</sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">this</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">);}</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></d=
iv><br>I can put that conversion into either `value_type` or `Expr`, as I s=
ee fit. And again, I won't have to <br><br>Having it be `operator auto` mea=
ns that it's an operator that's specifically invoked for type-deduction con=
texts. It also allows you to neatly duck issues like:<br><br><div class=3D"=
prettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: r=
gb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break=
-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">operator</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">string</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{..=
..}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{...}</span></div></code></div><br>Because you can only decl=
are `operator auto` once. Your way would require special language that says=
 that you can only have an single conversion operator declared with `auto`.=
<br><br>I just think it's more clear having it be `operator auto` rather th=
an `auto operator`.<br></div>

<p></p>

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

------=_Part_1464_28623640.1353635826219--

.

------=_Part_97_19503732.1353635928603
Content-Type: text/plain; charset=ISO-8859-1

But, more importantly, you can only return deduced types. I don't
personally have a problem with allowing automatic conversions to deduced
types, but I do have a problem with not permitting non-deduced types.

--




------=_Part_97_19503732.1353635928603
Content-Type: text/html; charset=ISO-8859-1

But, more importantly, you can only return deduced types. I don't personally have a problem with allowing automatic conversions to deduced types, but I do have a problem with not permitting non-deduced types.

<p></p>

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

------=_Part_97_19503732.1353635928603--

.

------=_Part_1038_929325.1353636322762
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, November 22, 2012 5:58:48 PM UTC-8, DeadMG wrote:
>
> But, more importantly, you can only return deduced types. I don't
> personally have a problem with allowing automatic conversions to deduced
> types, but I do have a problem with not permitting non-deduced types.


I'm not entirely sure how that applies to what I said.

--




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

On Thursday, November 22, 2012 5:58:48 PM UTC-8, DeadMG wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">But, more importantly, you can only return =
deduced types. I don't personally have a problem with allowing automatic co=
nversions to deduced types, but I do have a problem with not permitting non=
-deduced types.</blockquote><div><br>I'm not entirely sure how that applies=
 to what I said.<br></div>

<p></p>

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

------=_Part_1038_929325.1353636322762--

.

------=_Part_19_21270033.1353636395599
Content-Type: text/plain; charset=ISO-8859-1

Your proposal details no means of specifying the return type if necessary.

--




------=_Part_19_21270033.1353636395599
Content-Type: text/html; charset=ISO-8859-1

Your proposal details no means of specifying the return type if necessary.

<p></p>

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

------=_Part_19_21270033.1353636395599--

.

------=_Part_143_21292927.1353636627000
Content-Type: text/plain; charset=ISO-8859-1

A friend of mine suggested that you might mean

T operator auto()

as in, a non-conversion operator. That would certainly be fine. IMO the
difference between T operator auto() and auto operator T() is a bit of a
bikeshed, but I don't mind bikeshedding that much. If you did mean that,
then communication fail by at least one of us :P

--




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

A friend of mine suggested that you might mean<div><br></div><div>T operato=
r auto()</div><div><br></div><div>as in, a non-conversion operator. That wo=
uld certainly be fine. IMO the difference between T operator auto() and aut=
o operator T() is a bit of a bikeshed, but I don't mind bikeshedding that m=
uch. If you did mean that, then communication fail by at least one of us :P=
</div>

<p></p>

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

------=_Part_143_21292927.1353636627000--

.

------=_Part_151_30577629.1353637276270
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, November 22, 2012 6:10:27 PM UTC-8, DeadMG wrote:
>
> A friend of mine suggested that you might mean
>
> T operator auto()
>
> as in, a non-conversion operator. That would certainly be fine. IMO the
> difference between T operator auto() and auto operator T() is a bit of a
> bikeshed, but I don't mind bikeshedding that much. If you did mean that,
> then communication fail by at least one of us :P
>

Yeah, that's what I was going for. That there is an `operator auto`, just
like an `operator ()`, `operator +` and so forth. Thus, the type is the
return value.

The point being that `auto operator auto` means the same thing as `auto
operator +` or `auto operator()`. It's a consistency thing.

--




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

<br><br>On Thursday, November 22, 2012 6:10:27 PM UTC-8, DeadMG wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">A friend of mine suggested that you=
 might mean<div><br></div><div>T operator auto()</div><div><br></div><div>a=
s in, a non-conversion operator. That would certainly be fine. IMO the diff=
erence between T operator auto() and auto operator T() is a bit of a bikesh=
ed, but I don't mind bikeshedding that much. If you did mean that, then com=
munication fail by at least one of us :P</div></blockquote><div><br>Yeah, t=
hat's what I was going for. That there is an `operator auto`, just like an =
`operator ()`, `operator +` and so forth. Thus, the type is the return valu=
e.<br><br>The point being that `auto operator auto` means the same thing as=
 `auto operator +` or `auto operator()`. It's a consistency thing.<br></div=
>

<p></p>

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

------=_Part_151_30577629.1353637276270--

.

------=_Part_138_30430382.1353637402267
Content-Type: text/plain; charset=ISO-8859-1

If that's the only quibble you could think of, then I'm a happy man. In
fact, you might well be right that it's a superior way of going about it. I
simply thought that auto operator T() is more consistent with the semantics
of what's going on, namely, that it's a conversion operator, and the auto
specifies the conditions in which the conversion is valid- all the time-
similar to explicit operator T() and implicit operator T().

--




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

If that's the only quibble you could think of, then I'm a happy man. In fac=
t, you might well be right that it's a superior way of going about it. I si=
mply thought that auto operator T() is more consistent with the semantics o=
f what's going on, namely, that it's a conversion operator, and the auto sp=
ecifies the conditions in which the conversion is valid- all the time- simi=
lar to explicit operator T() and implicit operator T().

<p></p>

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

------=_Part_138_30430382.1353637402267--

.

------=_Part_161_31312272.1353638004734
Content-Type: text/plain; charset=ISO-8859-1

It occurs to me that expression templates is hardly the only place that
this could prove useful. Consider an implementation which changed the
address-of operator to yield a different type depending on where the object
was, and then added an automatic conversion to a normal pointer. Would it
be possible to implement some aliasing optimizations based on that? After
all, logically, the address of a member of a class cannot ever alias the
address of a member of a function parameter.

--




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

It occurs to me that expression templates is hardly the only place that thi=
s could prove useful. Consider an implementation which changed the address-=
of operator to yield a different type depending on where the object was, an=
d then added an automatic conversion to a normal pointer. Would it be possi=
ble to implement some aliasing optimizations based on that? After all, logi=
cally, the address of a member of a class cannot ever alias the address of =
a member of a function parameter.

<p></p>

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

------=_Part_161_31312272.1353638004734--

.

------=_Part_1618_26542077.1353638079675
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, November 22, 2012 6:23:22 PM UTC-8, DeadMG wrote:
>
> If that's the only quibble you could think of, then I'm a happy man. In
> fact, you might well be right that it's a superior way of going about it. I
> simply thought that auto operator T() is more consistent with the semantics
> of what's going on, namely, that it's a conversion operator, and the auto
> specifies the conditions in which the conversion is valid- all the time-
> similar to explicit operator T() and implicit operator T().


Perhaps. But then, what happens if you want to do this:

auto operator std::string() {return {5};}

You can't, because a std::string cannot be implicitly constructed from a
single integer. You have to use the typename:

auto operator std::string() {return std::string{5};}

Whereas, if we have functions that can have automatically-deduced return
values:

auto operator auto() {return std::string{5};}

It's clear what it returns; it's only specified once.

I understand wanting to designate one of the conversion operators as
`auto`, which would be used in such contexts. But I don't see the whole
operation as a conversion operation. It feels more like a special operation
(type-deduction) that ends up with a new type and therefore requires
machinery not-entirely-unlike conversion. But, as you point out, it's more
of a bikeshed issue.

--




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

On Thursday, November 22, 2012 6:23:22 PM UTC-8, DeadMG wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">If that's the only quibble you could think =
of, then I'm a happy man. In fact, you might well be right that it's a supe=
rior way of going about it. I simply thought that auto operator T() is more=
 consistent with the semantics of what's going on, namely, that it's a conv=
ersion operator, and the auto specifies the conditions in which the convers=
ion is valid- all the time- similar to explicit operator T() and implicit o=
perator T().</blockquote><div><br>Perhaps. But then, what happens if you wa=
nt to do this:<br><br><div class=3D"prettyprint" style=3D"background-color:=
 rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid;=
 border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><di=
v class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-=
prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">opera=
tor</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">string</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">5</span><span style=3D"color: #660;" class=3D"styled-by-prettify">};}</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></d=
iv></code></div><br>You can't, because a std::string cannot be implicitly c=
onstructed from a single integer. You have to use the typename:<br><br><div=
 class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-w=
rap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">operator</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">string</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #008;" class=3D"styled-by-prettify">re=
turn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">string</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #066;" class=3D"styled-by-prettify">5</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">};}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span></div></code></div><br>Whereas, if we =
have functions that can have automatically-deduced return values:<br><br><d=
iv class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bor=
der-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word=
-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">return</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: #008;" class=3D"styled-by-prettify">string</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #066;" class=3D"styled-by-prettify">5</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">};}</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span></div></code></div><br>It's cl=
ear what it returns; it's only specified once.<br><br>I understand wanting =
to designate one of the conversion operators as `auto`, which would be used=
 in such contexts. But I don't see the whole operation as a conversion oper=
ation. It feels more like a special operation (type-deduction) that ends up=
 with a new type and therefore requires machinery not-entirely-unlike conve=
rsion. But, as you point out, it's more of a bikeshed issue.<br></div>

<p></p>

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

------=_Part_1618_26542077.1353638079675--

.

------=_Part_1034_21509838.1353638351979
Content-Type: text/plain; charset=ISO-8859-1

auto operator std::string() { return decltype(*this){5}; }

;)

On Friday, November 23, 2012 3:34:39 AM UTC+1, Nicol Bolas wrote:
>
> On Thursday, November 22, 2012 6:23:22 PM UTC-8, DeadMG wrote:
>>
>> If that's the only quibble you could think of, then I'm a happy man. In
>> fact, you might well be right that it's a superior way of going about it. I
>> simply thought that auto operator T() is more consistent with the semantics
>> of what's going on, namely, that it's a conversion operator, and the auto
>> specifies the conditions in which the conversion is valid- all the time-
>> similar to explicit operator T() and implicit operator T().
>
>
> Perhaps. But then, what happens if you want to do this:
>
> auto operator std::string() {return {5};}
>
> You can't, because a std::string cannot be implicitly constructed from a
> single integer. You have to use the typename:
>
> auto operator std::string() {return std::string{5};}
>
> Whereas, if we have functions that can have automatically-deduced return
> values:
>
> auto operator auto() {return std::string{5};}
>
> It's clear what it returns; it's only specified once.
>
> I understand wanting to designate one of the conversion operators as
> `auto`, which would be used in such contexts. But I don't see the whole
> operation as a conversion operation. It feels more like a special operation
> (type-deduction) that ends up with a new type and therefore requires
> machinery not-entirely-unlike conversion. But, as you point out, it's more
> of a bikeshed issue.
>

--




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

<div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); b=
order-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wo=
rd-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypr=
int"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">string</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">return=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(*</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">this</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">){</span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">5</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span></div></code></div><br>;)<br><br>On Friday, November 23, 2012 3:34=
:39 AM UTC+1, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">On Thursday, November 22, 2012 6:23:22 PM UTC-8, DeadMG wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex">If that's the only quibble you could think of,=
 then I'm a happy man. In fact, you might well be right that it's a superio=
r way of going about it. I simply thought that auto operator T() is more co=
nsistent with the semantics of what's going on, namely, that it's a convers=
ion operator, and the auto specifies the conditions in which the conversion=
 is valid- all the time- similar to explicit operator T() and implicit oper=
ator T().</blockquote><div><br>Perhaps. But then, what happens if you want =
to do this:<br><br><div style=3D"background-color:rgb(250,250,250);border-c=
olor:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-w=
ord"><code><div><span style=3D"color:#008">auto</span><span style=3D"color:=
#000"> </span><span style=3D"color:#008">operator</span><span style=3D"colo=
r:#000"> std</span><span style=3D"color:#660">::</span><span style=3D"color=
:#008">string</span><span style=3D"color:#660">()</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#00=
8">return</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">{</span><span style=3D"color:#066">5</span><span style=3D"color:#660">};=
}</span><span style=3D"color:#000"><br></span></div></code></div><br>You ca=
n't, because a std::string cannot be implicitly constructed from a single i=
nteger. You have to use the typename:<br><br><div style=3D"background-color=
:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-w=
idth:1px;word-wrap:break-word"><code><div><span style=3D"color:#008">auto</=
span><span style=3D"color:#000"> </span><span style=3D"color:#008">operator=
</span><span style=3D"color:#000"> std</span><span style=3D"color:#660">::<=
/span><span style=3D"color:#008">string</span><span style=3D"color:#660">()=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</spa=
n><span style=3D"color:#008">return</span><span style=3D"color:#000"> std</=
span><span style=3D"color:#660">::</span><span style=3D"color:#008">string<=
/span><span style=3D"color:#660">{</span><span style=3D"color:#066">5</span=
><span style=3D"color:#660">};}</span><span style=3D"color:#000"><br></span=
></div></code></div><br>Whereas, if we have functions that can have automat=
ically-deduced return values:<br><br><div style=3D"background-color:rgb(250=
,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px=
;word-wrap:break-word"><code><div><span style=3D"color:#008">auto</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#008">operator</span><=
span style=3D"color:#000"> </span><span style=3D"color:#008">auto</span><sp=
an style=3D"color:#660">()</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">{</span><span style=3D"color:#008">return</span><span s=
tyle=3D"color:#000"> std</span><span style=3D"color:#660">::</span><span st=
yle=3D"color:#008">string</span><span style=3D"color:#660">{</span><span st=
yle=3D"color:#066">5</span><span style=3D"color:#660">};}</span><span style=
=3D"color:#000"><br></span></div></code></div><br>It's clear what it return=
s; it's only specified once.<br><br>I understand wanting to designate one o=
f the conversion operators as `auto`, which would be used in such contexts.=
 But I don't see the whole operation as a conversion operation. It feels mo=
re like a special operation (type-deduction) that ends up with a new type a=
nd therefore requires machinery not-entirely-unlike conversion. But, as you=
 point out, it's more of a bikeshed issue.<br></div></blockquote>

<p></p>

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

------=_Part_1034_21509838.1353638351979--

.

------=_Part_11_31757786.1353639375604
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, November 22, 2012 6:39:12 PM UTC-8, Xeo wrote:
>
> auto operator std::string() { return decltype(*this){5}; }
>
> ;)
>

That would only work if `this` actually was `std::string`. This is an
object which is meant to be *converted into* a std::string; it isn't part
of it.

--




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

<br><br>On Thursday, November 22, 2012 6:39:12 PM UTC-8, Xeo wrote:<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"background-color:rgb(250=
,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px=
;word-wrap:break-word"><code><div><span style=3D"color:#008">auto</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#008">operator</span><=
span style=3D"color:#000"> std</span><span style=3D"color:#660">::</span><s=
pan style=3D"color:#008">string</span><span style=3D"color:#660">()</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span =
style=3D"color:#000"> </span><span style=3D"color:#008">return</span><span =
style=3D"color:#000"> </span><span style=3D"color:#008">decltype</span><spa=
n style=3D"color:#660">(*</span><span style=3D"color:#008">this</span><span=
 style=3D"color:#660">){</span><span style=3D"color:#066">5</span><span sty=
le=3D"color:#660">};</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">}</span><span style=3D"color:#000"><br></span></div></code>=
</div><br>;)<br></blockquote><div><br>That would only work if `this` actual=
ly was `std::string`. This is an object which is meant to be <i>converted i=
nto</i> a std::string; it isn't part of it.<br></div>

<p></p>

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

------=_Part_11_31757786.1353639375604--

.

------=_Part_120_4000133.1353639801881
Content-Type: text/plain; charset=ISO-8859-1

On Friday, November 23, 2012 3:56:15 AM UTC+1, Nicol Bolas wrote:
>
> That would only work if `this` actually was `std::string`. This is an
> object which is meant to be *converted into* a std::string; it isn't part
> of it.
>

According to the proposal, the auto operator should also be picked for
decltype, and since the declaration (auto operator std::string) is complete
at that point, I don't see the problem.

--




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

On Friday, November 23, 2012 3:56:15 AM UTC+1, Nicol Bolas wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">That would only work if `this` actually =
was `std::string`. This is an object which is meant to be <i>converted into=
</i> a std::string; it isn't part of it.<br></blockquote><div><br>According=
 to the proposal, the&nbsp;<span style=3D"color: #008;" class=3D"styled-by-=
prettify"><code></code>auto</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">operator</span> should also be picked for&nbsp;<span style=3D"color=
: #008;" class=3D"styled-by-prettify"><code></code>decltype</span><code cla=
ss=3D"prettyprint"></code>, and since the declaration (<span style=3D"color=
: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">operator</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">string</span><code class=3D"prettyprint"></code>) is complete at =
that point, I don't see the problem.<br></div>

<p></p>

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

------=_Part_120_4000133.1353639801881--

.

------=_Part_153_15085203.1353639920896
Content-Type: text/plain; charset=ISO-8859-1

It was just meant as a joke anyways, nothing to get hung up on.

--




------=_Part_153_15085203.1353639920896
Content-Type: text/html; charset=ISO-8859-1

It was just meant as a joke anyways, nothing to get hung up on.<br>

<p></p>

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

------=_Part_153_15085203.1353639920896--

.

------=_Part_1243_32804231.1381599621338
Content-Type: text/plain; charset=ISO-8859-1

I know it's been a while, but has this gotten anywhere near an actual
proposal?
I have a matrix library on the works where this could be extremely useful.
I'm currently having all my expression templates uncopiable and unmoveable
so that users can't get references to expired temporaries by using auto.

Also, the syntax

T operator auto() {}

looks good to me, but is it really necessary? It seems to do two things at
once: tell which type should be deduced by auto and how to convert to that
type. Why not just tell which type it should be converted to with something
like

typedef T auto;

and then the actual conversion would happen as usual, via a constructor in
T, or a separate operator T, which might be optionally declared as explicit.
Any thoughts? Anyone still interested in this?

On Friday, November 23, 2012 4:05:21 AM UTC+1, Xeo wrote:
>
> It was just meant as a joke anyways, nothing to get hung up on.
>

--

---
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_1243_32804231.1381599621338
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I know it's been a while, but has this gotten anywhere nea=
r an actual proposal?<div>I have a matrix library on the works where this c=
ould be extremely useful. I'm currently having all my expression templates =
uncopiable and unmoveable so that users can't get references to expired tem=
poraries by using auto.</div><div><br></div><div>Also, the syntax</div><div=
><br></div><div><div class=3D"prettyprint" style=3D"background-color: rgb(2=
50, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;=
"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"=
color: #000;" class=3D"styled-by-prettify">T </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">operator</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{}</span></div></code></div></div><div><br></div><div>looks good to me, bu=
t is it really necessary? It seems to do two things at once: tell which typ=
e should be deduced by auto and how to convert to that type. Why not just t=
ell which type it should be converted to with something like</div><div><br>=
</div><div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #008;" class=3D"styled-by-prettify">typedef</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> T </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">auto</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span></div></code></div></div><div><br></div><di=
v>and then the actual conversion would happen as usual, via a constructor i=
n T, or a separate operator T, which might be optionally declared as explic=
it.</div><div>Any thoughts? Anyone still interested in this?</div><div><br>=
On Friday, November 23, 2012 4:05:21 AM UTC+1, Xeo wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">It was just meant as a joke anyways, nothing to=
 get hung up on.<br></blockquote></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1243_32804231.1381599621338--

.

On 10/13/13 1:40 AM, Xavi Gratal wrote:
> I know it's been a while, but has this gotten anywhere near an actual
> proposal?
> I have a matrix library on the works where this could be extremely useful.
> I'm currently having all my expression templates uncopiable and unmoveable
> so that users can't get references to expired temporaries by using auto.

A user can still bypass that using a "universal reference," auto &&,
which some might already find idiomatic.

> Also, the syntax
>
> T operator auto() {}
>
> looks good to me, but is it really necessary? It seems to do two things at
> once: tell which type should be deduced by auto and how to convert to that
> type. Why not just tell which type it should be converted to with something
> like
>
> typedef T auto;
>
> and then the actual conversion would happen as usual, via a constructor in
> T, or a separate operator T, which might be optionally declared as explicit.
> Any thoughts? Anyone still interested in this?

The member typedef auto does look cleaner to me. The differences I see
are that

- With two different functions, you have potentially different
behaviors, which would generally be bad.
- If operator auto can be overloaded on const and reference
qualification, that leads to divergent type deduction and behavior. Or,
if it cannot, then the behavior is inconsistent with other conversion
functions. (I haven't checked the proposal for this issue.)

Recently I suggested (on this board, no formal proposal) to forbid a
type from being used to declare a named object. The mechanism is
destructor overloading. A named object would be destroyed by an "lvalue"
destructor.

https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/2tfKrgdKvfo

The behavior would be limited to a compile-time error such as a
static_assert, not an automatic fix. As a library author, what do you
think of that?

--

---
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_2160_30014205.1381658122955
Content-Type: text/plain; charset=ISO-8859-1

I see one potential issue with such a proposal, in some cases this breaks
the ability to use local type inference with intermediate values of
expression templates where a user may not want the expression to be
immediately evaluated at the point of construction but always will because
the library writer has overridden the behavior of auto to do so.

This also brings us back to the originally problem of having to explicitly
define what the type of a potentially complex template expression is for
these intermediate values or force users to write their expressions all
inline, in one expression which could be quite complex and unreadable.

So I think in practice there is very little reason to write/provide such
overloads for most expression template libraries, of-course it is dependent
on the context of what the specific expression template library is trying
to achieve.

There has a to better way than having to change/override the behavior of
type inference engine, maybe library vendors should just define a helper
'eval' function for this specific case and at least this makes it quite
clear what is going on with the expression and what the deduced type will
be e.g.:

auto delta = j - i; // the type of 'delta' is some expression template type
auto x = eval( delta + z ); // the type of 'x' is the final
evaluated/reduced type.

Personally I'm not a fan of such language proposals as there tend to try to
solve very specific problems to workaround solutions to language
deficiencies for more general problems.

What I mean by this is expression templates really is workaround library
solution to the problems of either: before C++ had built-in move semantics,
*or *missing languages features that allow people to write efficient
embedded domain-specific libraries naturally in C++.

On Thursday, November 22, 2012 11:04:15 PM UTC, DeadMG wrote:
>
> The problem is fairly simple: It's too difficult to implement proxy
> objects in C++ right now.
>
> In C++11, I feel that, with type deduction, we should move away from
> concrete types and move to deal with only the interfaces they offer.
>
> The primary difficulty here comes when we deal with auto and decltype.
> These functions, whilst great, break any attempts we make to offer an
> interface-based substitute. Especially consider the case of expression
> templates- currently, they do not really work, as you cannot do
>
> auto a = b + c + d;
>
> where the author of a has invoked expression templates to reduce
> complexity. Nor could you do
>
> std::vector<decltype(b + c)> vec;
>
> Thus, I propose an "automatic" operator. The automatic operator is invoked
> whenever type deduction is used, including decltype or auto, or whenever a
> requested member is not available. In addition, when overload resolution or
> template specialization is considered, an object which has an automatic
> operator is considered as the return type of that automatic operator, *not
> * as it's actual type, unless the actual type is specified directly and
> unambiguously with no intermediate conversions (except reference binding,
> cv qualifiers). The sample syntax I am showing is auto operator T(), which
> I consider to be the best choice, but it's a bit of a bikeshed issue as
> it's only used once at the point of definition and thus not especially
> significant.
>
> For now, I think it would be simplest to define that each type may only
> have one automatic operator, except that the operator may be overloaded by
> cv-qualifier or ref-qualifer- that is, any expression e involving any type
> T may automatically convert to one, and only one, type.
>
> For example, consider an expression template. Now, in our proxy objects,
> we can define an automatic conversion.
>
> class proxy {
>     auto operator real_type() && { return evaluate(); }
> };
>
> This would permit us to write
>
> std::vector<decltype(b + c)> vec;
>
> where vec's template argument is actually real_type, not proxy. In
> addition, we can perform operations like (b + c).size(); without having to
> explicitly forward each and every member in a non-generic and
> unmaintainable fashion. Finally, we can introduce new types which are
> indistinguishable from previous types, enabling improvements to areas of
> the Standard not previously accessible. For example, consider basic_string.
> Right now, we could not change that specification to support expression
> templates, which offer improved complexity even over move semantics,
> because that would break code which relied on type deduction or template
> specialization for the return type of operator+. However, if the wording
> were changed to say that the return value of operator+ offers the same
> interface as basic_string, it would now be possible for implementations to
> replace it with an optimized version without breaking existing code, by
> having an automatic conversion. In fact, such a wording change may not even
> be necessary, since the change would not be observable and thus falls under
> the as-if rule.
>
> It would also permit relaxed requirements in some areas of the Standard.
> For example, consider operator[] for map and unordered_map. By returning a
> value which has an automatic conversion to value&, we can effectively
> overload for read or write separately- and there have been many requests
> for, for example, an operator[]=. This proposal would effectively solve
> that problem, as well as, say, operator*= (for *it = x) for iterators. The
> difference between what can be accomplished now, and an implementation
> using an automatic conversion, is that it would be impossible to write a
> generic proxy which also supported members- such as it->x.
>
> struct proxy {
>     auto operator value&() {
>         // read: if T is not default-constructible, throw if not found.
>     }
>     template<typename T> value& operator=(T&& arg) {
>         // write: don't require default-constructible
>     }
> };
>
> Now, assuming a proxy operator[], we can write
>
> map[key].f();
>
> and
>
> map[key] = val;
>
> without having to require default-constructibility, and potentially
> improving performance by avoiding default-construction and then assignment.
>
> Finally, we also move a step closer to properties and other similar
> mechanisms, since a value of one type can transparently impersonate another.
>

--

---
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_2160_30014205.1381658122955
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I see one potential issue with such a proposal, in some ca=
ses this breaks the ability to use local type inference with intermediate v=
alues of expression templates where a user may not want the expression to b=
e immediately evaluated at the point of construction but always will becaus=
e the library writer has overridden the behavior of auto to do so.<br><br>T=
his also brings us back to the originally problem of having to explicitly d=
efine what the type of a potentially complex template expression is for the=
se intermediate values or force users to write their expressions all inline=
, in one expression which could be quite complex and unreadable.<br><br>So =
I think in practice there is very little reason to write/provide such overl=
oads for most expression template libraries, of-course it is dependent on t=
he context of what the specific expression template library is trying to ac=
hieve.<br><br>There has a to better way than having to change/override the =
behavior of type inference engine, maybe library vendors should just define=
 a helper 'eval' function for this specific case and at least this makes it=
 quite clear what is going on with the expression and what the deduced type=
 will be e.g.:<br><br><div class=3D"prettyprint" style=3D"background-color:=
 rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid;=
 border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><di=
v class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-=
prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> delta </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> j - i=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// the type of '</span><span=
 style=3D"color: #800;" class=3D"styled-by-prettify"><code class=3D"prettyp=
rint"><span style=3D"color: #000;" class=3D"styled-by-prettify">delta</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify"></span></code>' =
is some expression template type</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> x </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">eval</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><code class=3D"pre=
ttyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">delta <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify"></span></co=
de><span style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D=
"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">+ <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify"></span></co=
de>z </span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #800;" class=3D"styled-by-prettify">// the type of 'x' is =
the final evaluated/reduced type.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>Personally I'm no=
t a fan of such language proposals as there tend to try to solve very speci=
fic problems to workaround solutions to language deficiencies for more gene=
ral problems.<br><br>What I mean by this is expression templates really is =
workaround library solution to the problems of either: before C++ had built=
-in move semantics, <i>or </i>missing languages features that allow people =
to write efficient embedded domain-specific libraries naturally in C++.<br>=
<br>On Thursday, November 22, 2012 11:04:15 PM UTC, DeadMG wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">The problem is fairly simple: It's too d=
ifficult to implement proxy objects in C++ right now.<div><br></div><div>In=
 C++11, I feel that, with type deduction, we should move away from concrete=
 types and move to deal with only the interfaces they offer.</div><div><br>=
</div><div>The primary difficulty here comes when we deal with auto and dec=
ltype. These functions, whilst great, break any attempts we make to offer a=
n interface-based substitute. Especially consider the case of expression te=
mplates- currently, they do not really work, as you cannot do</div><div><br=
></div><div><div style=3D"background-color:rgb(250,250,250);border:1px soli=
d rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D"color:#0=
08">auto</span><span style=3D"color:#000"> a </span><font color=3D"#666600"=
><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> b </span>=
<span style=3D"color:#660">+</span><span style=3D"color:#000"> c </span><sp=
an style=3D"color:#660">+</span><span style=3D"color:#000"> d</span><span s=
tyle=3D"color:#660">;</span></font></div></code></div><br>where the author =
of a has invoked expression templates to reduce complexity. Nor could you d=
o&nbsp;</div><div><br></div><div><div style=3D"background-color:rgb(250,250=
,250);border:1px solid rgb(187,187,187);word-wrap:break-word"><code><div><s=
pan style=3D"color:#000">std</span><span style=3D"color:#660">::</span><spa=
n style=3D"color:#000">vector</span><span style=3D"color:#660">&lt;</span><=
span style=3D"color:#008">decltype</span><span style=3D"color:#660">(</span=
><span style=3D"color:#000">b </span><span style=3D"color:#660">+</span><fo=
nt color=3D"#000000"><span style=3D"color:#000"> c</span><span style=3D"col=
or:#660">)&gt;</span><span style=3D"color:#000"> vec</span><span style=3D"c=
olor:#660">;</span></font></div></code></div><br>Thus, I propose an "automa=
tic" operator. The automatic operator is invoked whenever type deduction is=
 used, including decltype or auto, or whenever a requested member is not av=
ailable. In addition, when overload resolution or template specialization i=
s considered, an object which has an automatic operator is considered as th=
e return type of that automatic operator, <i>not</i>&nbsp;as it's actual ty=
pe, unless the actual type is specified directly and unambiguously with no =
intermediate conversions (except reference binding, cv qualifiers).&nbsp;Th=
e sample syntax I am showing is auto operator T(), which I consider to be t=
he best choice, but it's a bit of a bikeshed issue as it's only used once a=
t the point of definition and thus not especially significant.</div><div><b=
r></div><div>For now, I think it would be simplest to define that each type=
 may only have one automatic operator, except that the operator may be over=
loaded by cv-qualifier or ref-qualifer- that is, any expression e involving=
 any type T may automatically convert to one, and only one, type.</div><div=
><br></div><div>For example, consider an expression template. Now, in our p=
roxy objects, we can define an automatic conversion.</div><div><br></div><d=
iv>class proxy {</div><div>&nbsp; &nbsp; auto operator real_type() &amp;&am=
p; { return evaluate(); }</div><div>};</div><div><br></div><div>This would =
permit us to write</div><div><br></div><div>std::vector&lt;decltype(b + c)&=
gt; vec;</div><div><br></div><div>where vec's template argument is actually=
 real_type, not proxy. In addition, we can perform operations like (b + c).=
size(); without having to explicitly forward each and every member in a non=
-generic and unmaintainable fashion. Finally, we can introduce new types wh=
ich are indistinguishable from previous types, enabling improvements to are=
as of the Standard not previously accessible. For example, consider basic_s=
tring. Right now, we could not change that specification to support express=
ion templates, which offer improved complexity even over move semantics, be=
cause that would break code which relied on type deduction or template spec=
ialization for the return type of operator+. However, if the wording were c=
hanged to say that the return value of operator+ offers the same interface =
as basic_string, it would now be possible for implementations to replace it=
 with an optimized version without breaking existing code, by having an aut=
omatic conversion. In fact, such a wording change may not even be necessary=
, since the change would not be observable and thus falls under the as-if r=
ule.</div><div><br></div><div>It would also permit relaxed requirements in =
some areas of the Standard. For example, consider operator[] for map and un=
ordered_map. By returning a value which has an automatic conversion to valu=
e&amp;, we can effectively overload for read or write separately- and there=
 have been many requests for, for example, an operator[]=3D. This proposal =
would effectively solve that problem, as well as, say, operator*=3D (for *i=
t =3D x) for iterators. The difference between what can be accomplished now=
, and an implementation using an automatic conversion, is that it would be =
impossible to write a generic proxy which also supported members- such as i=
t-&gt;x.</div><div><br></div><div>struct proxy {</div><div>&nbsp; &nbsp; au=
to operator value&amp;() {&nbsp;</div><div>&nbsp; &nbsp; &nbsp; &nbsp; // r=
ead: if T is not default-constructible, throw if not found.</div><div>&nbsp=
; &nbsp; }</div><div>&nbsp; &nbsp; template&lt;typename T&gt; value&amp; op=
erator=3D(T&amp;&amp; arg) {&nbsp;</div><div>&nbsp; &nbsp; &nbsp; &nbsp; //=
 write: don't require default-constructible&nbsp;</div><div>&nbsp; &nbsp; }=
</div><div>};</div><div><br></div><div>Now, assuming a proxy operator[], we=
 can write</div><div><br></div><div>map[key].f();</div><div><br></div><div>=
and</div><div><br></div><div>map[key] =3D val;</div><div><br></div><div>wit=
hout having to require default-constructibility, and potentially improving =
performance by avoiding default-construction and then assignment.</div><div=
><br></div><div>Finally, we also move a step closer to properties and other=
 similar mechanisms, since a value of one type can transparently impersonat=
e another.</div></blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_2160_30014205.1381658122955--

.

------=_Part_2127_30008068.1381658443139
Content-Type: text/plain; charset=ISO-8859-1

I see one potential issue with such a proposal, in some cases this breaks
the ability to use local type inference with intermediate values of
expression templates where a user may not want the expression to be
immediately evaluated at the point of construction but always will because
the library writer has overridden the behavior of auto to do so.

This also brings us back to the originally problem of having to explicitly
define what the type of a potentially complex template expression is for
these intermediate values or force users to write their expressions all
inline, in one expression which could be quite complex and unreadable.

So I think in practice there is very little reason to write/provide such
overloads for most expression template libraries, of-course it is dependent
on the context of what the specific expression template library is trying
to achieve.

There has a to better way than having to change/override the behavior of
type inference engine, maybe library vendors should just define a helper
'eval' function for this specific case and at least this makes it quite
clear what is going on with the expression and what the deduced type will
be e.g.:

auto delta = j - i; // the type of 'delta' is some expression template type
auto x = eval( delta + z ); // the type of 'x' is the final
evaluated/reduced type.

Personally I'm not a fan of such language proposals as there tend to try to
solve very specific problems to workaround solutions to language
deficiencies for more general problems.

What I mean by this is expression templates really is workaround library
solution to the problems of either: before C++ had built-in move semantics,
*or *missing languages features that allow people to write efficient
embedded domain-specific languages naturally in C++.

--

---
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_2127_30008068.1381658443139
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I see one potential issue with such a proposal, in some ca=
ses this=20
breaks the ability to use local type inference with intermediate values=20
of expression templates where a user may not want the expression to be=20
immediately evaluated at the point of construction but always will=20
because the library writer has overridden the behavior of auto to do so.<br=
><br>This
 also brings us back to the originally problem of having to explicitly=20
define what the type of a potentially complex template expression is for
 these intermediate values or force users to write their expressions all
 inline, in one expression which could be quite complex and unreadable.<br>=
<br>So
 I think in practice there is very little reason to write/provide such=20
overloads for most expression template libraries, of-course it is=20
dependent on the context of what the specific expression template=20
library is trying to achieve.<br><br>There has a to better way than=20
having to change/override the behavior of type inference engine, maybe=20
library vendors should just define a helper 'eval' function for this=20
specific case and at least this makes it quite clear what is going on=20
with the expression and what the deduced type will be e.g.:<br><br><div sty=
le=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);borde=
r-style:solid;border-width:1px;word-wrap:break-word"><code><div><span style=
=3D"color:#008">auto</span><span style=3D"color:#000"> delta </span><span s=
tyle=3D"color:#660">=3D</span><span style=3D"color:#000"> j - i</span><span=
 style=3D"color:#660">;</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#800">// the type of '</span><span style=3D"color:#800"><code><s=
pan style=3D"color:#000">delta</span><span style=3D"color:#660"></span></co=
de>' is some expression template type</span><span style=3D"color:#000"><br>=
</span><span style=3D"color:#008">auto</span><span style=3D"color:#000"> x =
</span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#008">eval</span><span style=3D"color:#660">(</spa=
n><span style=3D"color:#000"> </span><code><span style=3D"color:#000">delta=
 </span><span style=3D"color:#660"></span></code><span style=3D"color:#000"=
><code><span style=3D"color:#000">+ </span><span style=3D"color:#660"></spa=
n></code>z </span><span style=3D"color:#660">);</span><span style=3D"color:=
#000"> </span><span style=3D"color:#800">// the type of 'x' is the final ev=
aluated/reduced type.</span><span style=3D"color:#000"><br></span></div></c=
ode></div><br>Personally
 I'm not a fan of such language proposals as there tend to try to solve=20
very specific problems to workaround solutions to language deficiencies=20
for more general problems.<br><br>What I mean by this is expression=20
templates really is workaround library solution to the problems of=20
either: before C++ had built-in move semantics, <i>or </i>missing languages=
 features that allow people to write efficient embedded domain-specific lan=
guages naturally in C++.<br><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_2127_30008068.1381658443139--

.

------=_Part_182_25329108.1381658965973
Content-Type: text/plain; charset=ISO-8859-1

 You're making some pretty core errors here.

this breaks the ability to use local type inference with intermediate
> values of expression templates where a user may not want the expression to
> be immediately evaluated at the point of construction but always will
> because the library writer has overridden the behavior of auto to do so.


If you know so much about my library that you want to do this when I have
decided that it is not safe in general, then you can go and name the exact
intermediate type for yourself. It's my library. I know whether or not I
have references to temporaries in my code. You don't. If I don't have
references to temporaries in my code then why would I override operator
auto like this? It wouldn't make sense.

one expression which could be quite complex and unreadable.


That's the current situation anyway, if you want to get full expression
templateness. Because you can't store the expression template result.
Because they contain references to various temporaries.

missing languages features that allow people to write efficient embedded
> domain-specific languages naturally in C++.


You'd need some hardcore reflection to do better than expression 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_182_25329108.1381658965973
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&nbsp;You're making some pretty core errors here.</di=
v><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); =
border-left-style: solid; padding-left: 1ex;">this breaks the ability to us=
e local type inference with intermediate values of expression templates whe=
re a user may not want the expression to be immediately evaluated at the po=
int of construction but always will because the library writer has overridd=
en the behavior of auto to do so.</blockquote><div><br></div><div>If you kn=
ow so much about my library that you want to do this when I have decided th=
at it is not safe in general, then you can go and name the exact intermedia=
te type for yourself. It's my library. I know whether or not I have referen=
ces to temporaries in my code. You don't. If I don't have references to tem=
poraries in my code then why would I override operator auto like this? It w=
ouldn't make sense.</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-colo=
r: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">one ex=
pression which could be quite complex and unreadable.</blockquote><div><br>=
</div><div>That's the current situation anyway, if you want to get full exp=
ression templateness. Because you can't store the expression template resul=
t. Because they contain references to various temporaries.&nbsp;</div><div>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-=
left-style: solid; padding-left: 1ex;">missing languages features that allo=
w people to write efficient embedded domain-specific languages naturally in=
 C++.</blockquote><div><br></div><div>You'd need some hardcore reflection t=
o do better than expression templates.&nbsp;</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_182_25329108.1381658965973--

.

Did you look at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3748.pdf ?

--

---
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_2214_5142429.1381662268257
Content-Type: text/plain; charset=ISO-8859-1


>
>  You're making some pretty core errors here.
>
> this breaks the ability to use local type inference with intermediate
>> values of expression templates where a user may not want the expression to
>> be immediately evaluated at the point of construction but always will
>> because the library writer has overridden the behavior of auto to do so.
>
>
> If you know so much about my library that you want to do this when I have
> decided that it is not safe in general, then you can go and name the exact
> intermediate type for yourself. It's my library. I know whether or not I
> have references to temporaries in my code. You don't. If I don't have
> references to temporaries in my code then why would I override operator
> auto like this? It wouldn't make sense.
>

Please don't misunderstand me, I'm talking in a broader sense here. I
understand your frustration because I've had similar issues myself using
the Eigen linear algbra library where in some cases I didn't want auto to
deduce the type to be the expression template type but I don't I always
want that too happen. What I'm trying to say is there must be a better way
to solve this than having too mess with and complicate the type inference
rules.


> missing languages features that allow people to write efficient embedded
>> domain-specific languages naturally in C++.
>
>
> You'd need some hardcore reflection to do better than expression
> templates.
>

I'm making assumptions as too what you mean here but if I understood what
you're implying this isn't the only way and if you wanted to go the (semi-)
compile-time route then compile-time reflection wouldn't be enough alone.

For specifically writing embedded DSLs (like Boost.Spirit) as far as I am
aware there are usually 2 directions you can go to solve this and both can
be mixed together if both are available.

One approach is support for a real AST based macro systems and code
quotations (and maybe support for syntax extensions for the more extreme
cases).

The second approach requires no AST macro system and can be a complete pure
library approach but this requires a combination of language features,
first-class functions & operators, more flexible support for defining
operators such as specifying fixity & precedence levels and more symbols or
a small set of symbols but can be combined to define new ones. This can be
further enhanced & more flexible with additional language features such as
parametric & higher-kinded/rank polymorphism, support for making
expressions lazy, algebraic data-types and pattern matching.

The latter approach requires no reflection system what so ever :)

Haskell is an example programming language which has support for both
approaches and the latter approach is the most common easiest way to write
eDSL in Haskell. DSL libraries like Boost.Spirit are very easy and natural
to write as a pure libraries in Haskell.

eDSL expression template libraries effectively are a workaround solution to
emulate most of those lacking features in the second approach. If we had
most of those features in the second approach we would not need to write
expression templates at all so maybe we would never have this issue with
how expression template libraries interact with local type inference.

--

---
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_2214_5142429.1381662268257
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>&nbsp;You're making some pretty core errors here.</div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex">this breaks the ability to use local type inference wi=
th intermediate values of expression templates where a user may not want th=
e expression to be immediately evaluated at the point of construction but a=
lways will because the library writer has overridden the behavior of auto t=
o do so.</blockquote><div><br></div><div>If you know so much about my libra=
ry that you want to do this when I have decided that it is not safe in gene=
ral, then you can go and name the exact intermediate type for yourself. It'=
s my library. I know whether or not I have references to temporaries in my =
code. You don't. If I don't have references to temporaries in my code then =
why would I override operator auto like this? It wouldn't make sense.</div>=
</div></blockquote><div><br></div><div>Please don't misunderstand me, I'm t=
alking in a broader sense here. I understand your frustration because I've =
had similar issues myself using the Eigen linear algbra library where in so=
me cases I didn't want auto to deduce the type to be the expression templat=
e type but I don't I always want that too happen. What I'm trying to say is=
 there must be a better way to solve this than having too mess with and com=
plicate the type inference rules.<br></div><div>&nbsp;</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"></blockquot=
e><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex">missing languages features that allow people to write ef=
ficient embedded domain-specific languages naturally in C++.</blockquote><d=
iv><br></div><div>You'd need some hardcore reflection to do better than exp=
ression templates.&nbsp;</div></div></blockquote><div><br></div><div>I'm ma=
king assumptions as too what you mean here but if I understood what you're =
implying this isn't the only way and if you wanted to go the (semi-) compil=
e-time route then compile-time reflection wouldn't be enough alone.</div><d=
iv><br></div><div>For specifically writing embedded DSLs (like Boost.Spirit=
) as far as I am aware there are usually 2 directions you can go to solve t=
his and both can be mixed together if both are available.</div><div><br></d=
iv><div>One approach is support for a real AST based macro systems and code=
 quotations (and maybe support for syntax extensions for the more extreme c=
ases).</div><div><br></div><div>The second approach requires no AST macro s=
ystem and can be a complete pure library approach but this requires a combi=
nation of language features, first-class functions &amp; operators, more fl=
exible support for defining operators such as specifying fixity &amp; prece=
dence levels and more symbols or a small set of symbols but can be combined=
 to define new ones. This can be further enhanced &amp; more flexible with =
additional language features such as parametric &amp; higher-kinded/rank po=
lymorphism, support for making expressions lazy, algebraic data-types and p=
attern matching.</div><div><br></div><div>The latter approach requires no r=
eflection system what so ever :)</div><div><br></div><div>Haskell is an exa=
mple programming language which has support for both approaches and the lat=
ter approach is the most common easiest way to write eDSL in Haskell. DSL l=
ibraries like Boost.Spirit are very easy and natural to write as a pure lib=
raries in Haskell.</div><div><br></div><div>eDSL expression template librar=
ies effectively are a workaround solution to emulate most of those lacking =
features in the second approach. If we had most of those features in the se=
cond approach we would not need to write expression templates at all so may=
be we would never have this issue with how expression template libraries in=
teract with local type inference.</div><div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_2214_5142429.1381662268257--

.

--047d7b10cb1d0f2fda04e8a0d854
Content-Type: text/plain; charset=ISO-8859-1

2013/10/13 David Krauss <potswa@gmail.com>

> On 10/13/13 1:40 AM, Xavi Gratal wrote:
>
>> I know it's been a while, but has this gotten anywhere near an actual
>> proposal?
>> I have a matrix library on the works where this could be extremely useful.
>> I'm currently having all my expression templates uncopiable and unmoveable
>> so that users can't get references to expired temporaries by using auto.
>>
>
> A user can still bypass that using a "universal reference," auto &&, which
> some might already find idiomatic.
>
> True, and that's unfortunate

>
>  Also, the syntax
>>
>> T operator auto() {}
>>
>> looks good to me, but is it really necessary? It seems to do two things at
>> once: tell which type should be deduced by auto and how to convert to that
>> type. Why not just tell which type it should be converted to with
>> something
>> like
>>
>> typedef T auto;
>>
>> and then the actual conversion would happen as usual, via a constructor in
>> T, or a separate operator T, which might be optionally declared as
>> explicit.
>> Any thoughts? Anyone still interested in this?
>>
>
> The member typedef auto does look cleaner to me. The differences I see are
> that
>
> - With two different functions, you have potentially different behaviors,
> which would generally be bad.
> - If operator auto can be overloaded on const and reference qualification,
> that leads to divergent type deduction and behavior. Or, if it cannot, then
> the behavior is inconsistent with other conversion functions. (I haven't
> checked the proposal for this issue.)
>
> Recently I suggested (on this board, no formal proposal) to forbid a type
> from being used to declare a named object. The mechanism is destructor
> overloading. A named object would be destroyed by an "lvalue" destructor.
>
> https://groups.google.com/a/**isocpp.org/forum/#!topic/std-**
> proposals/2tfKrgdKvfo<https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/2tfKrgdKvfo>
>
> The behavior would be limited to a compile-time error such as a
> static_assert, not an automatic fix. As a library author, what do you think
> of that?
>
> That sounds like a good feature to have, even if only because I don't see
any particular reason why destructors cannot be ref-qualified (but maybe
there is, I haven't looked at it in detail).
However, I am not sure it solves the problem you mention of using auto &&
or const auto &, because I am not sure how an object whose life has been
extended because of being bound to a const reference would be destroyed.
The object itself is not named, so it should probably still be destroyed as
an rvalue.
Also, it could prevent auto working in unexpected ways, but it wouldn't
allow auto to be used in the right way, which is part of the goal of this
proposal.

>
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@**isocpp.org<std-proposals%2Bunsubscribe@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/ <http://groups.google.com/a/isocpp.org/group/std-proposals/>.
>

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2013/10/13 David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:pot=
swa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span><br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div class=3D"im">On 10/13/13 1:40 AM, Xavi Gratal wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I know it&#39;s been a while, but has this gotten anywhere near an actual<b=
r>
proposal?<br>
I have a matrix library on the works where this could be extremely useful.<=
br>
I&#39;m currently having all my expression templates uncopiable and unmovea=
ble<br>
so that users can&#39;t get references to expired temporaries by using auto=
..<br>
</blockquote>
<br></div>
A user can still bypass that using a &quot;universal reference,&quot; auto =
&amp;&amp;, which some might already find idiomatic.<div class=3D"im"><br><=
/div></blockquote><div>True, and that&#39;s unfortunate=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<div class=3D"im">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Also, the syntax<br>
<br>
T operator auto() {}<br>
<br>
looks good to me, but is it really necessary? It seems to do two things at<=
br>
once: tell which type should be deduced by auto and how to convert to that<=
br>
type. Why not just tell which type it should be converted to with something=
<br>
like<br>
<br>
typedef T auto;<br>
<br>
and then the actual conversion would happen as usual, via a constructor in<=
br>
T, or a separate operator T, which might be optionally declared as explicit=
..<br>
Any thoughts? Anyone still interested in this?<br>
</blockquote>
<br></div>
The member typedef auto does look cleaner to me. The differences I see are =
that<br>
<br>
- With two different functions, you have potentially different behaviors, w=
hich would generally be bad.<br>
- If operator auto can be overloaded on const and reference qualification, =
that leads to divergent type deduction and behavior. Or, if it cannot, then=
 the behavior is inconsistent with other conversion functions. (I haven&#39=
;t checked the proposal for this issue.)<br>

<br>
Recently I suggested (on this board, no formal proposal) to forbid a type f=
rom being used to declare a named object. The mechanism is destructor overl=
oading. A named object would be destroyed by an &quot;lvalue&quot; destruct=
or.<br>

<br>
<a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposa=
ls/2tfKrgdKvfo" target=3D"_blank">https://groups.google.com/a/<u></u>isocpp=
..org/forum/#!topic/std-<u></u>proposals/2tfKrgdKvfo</a><br>
<br>
The behavior would be limited to a compile-time error such as a static_asse=
rt, not an automatic fix. As a library author, what do you think of that?<d=
iv class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div>Tha=
t sounds like a good feature to have, even if only because I don&#39;t see =
any particular reason why destructors cannot be ref-qualified (but maybe th=
ere is, I haven&#39;t looked at it in detail).</div>
<div>However, I am not sure it solves the problem you mention of using auto=
 &amp;&amp; or const auto &amp;, because I am not sure how an object whose =
life has been extended because of being bound to a const reference would be=
 destroyed. The object itself is not named, so it should probably still be =
destroyed as an rvalue.</div>
<div>Also, it could prevent auto working in unexpected ways, but it wouldn&=
#39;t allow auto to be used in the right way, which is part of the goal of =
this proposal.</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b10cb1d0f2fda04e8a0d854--

.

--047d7b86f2949a352b04e8a11645
Content-Type: text/plain; charset=ISO-8859-1

Even in a matrix library, which is one of the most obvious cases for
expression templates, move semantics don't completely solve the problem and
I believe that expression templates will also be necessary as long as C++
looks anything like C++:

- Some small (and not so small) matrices can be implemented in the stack,
thus making move behave exactly like copy.
- If you're doing something like a+b+c, it is usually faster to run a
single loop than to first do a+b and then add c, even if there is no copy
involved.
- Some expressions might have completely different implementations
depending on how they are combined. For example, in my matrix library, I
use the syntax a.I() to represent the inverse of a matrix. Of course, to
compute b*a.I(), there are better ways to do it than to compute the inverse
and then multiply, so I only want to actually compute the inverse if it is
not involved on a product, so I need an expression template until I know
what happens to it. Then, if I do auto b=a.I(), I actually want to compute
the inverse and b should be a matrix, not the expression template, which
might contain references to temporaries.

It's just ugly to force users to use eval() constantly, and sometimes
redundantly, because in many cases to know whether eval is necessary or not
requires knowing too many about the implementation.

So I believe that even if this functionality will only be used by
implementors of a particular type of library, it will benefit all the users
of these libraries, and it will isolate them from expression templates,
which are just implementation details.


2013/10/13 Joel Falcou <joel.falcou@gmail.com>

> Did you look at http://www.open-std.org/jtc1/**sc22/wg21/docs/papers/2013/
> **n3748.pdf<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3748.pdf>?
>
>  Thanks for the link! I hadn't seen it.
I especially like the using syntax, which is almost identical to the
typedef I proposed, but it looks a bit more C++11.
I don't think the explicit notation is necessary at all. I would propose
that the overridden conversion works only for auto (and maybe const auto&
and similar when they extend the lifetime of a temporary) but they don't
apply to things like decltype(a+b) or even decltype(auto), making it easy
to obtain the real type of the expression.
Also, I don't think that they have to apply to template argument deduction
(as suggested in section 5), because the main argument for this proposal is
that it would prevent having dangling references to dead temporaries, and
this wouldn't be a problem when passing the expression templates to other
functions. Also, that would make the implementation of the library dealing
with the expression templates much more cumbersome, since in there you
actually want the deduced types to be the expression templates themselves.
Finally, I don't share the compatibility concerns expressed in section 4,
since it wouldn't change the meaning of any currently valid program.

>
> --
>
> --- 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<std-proposals%2Bunsubscribe@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/ <http://groups.google.com/a/isocpp.org/group/std-proposals/>.
>

--

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

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

<div dir=3D"ltr">Even in a matrix library, which is one of the most obvious=
 cases for expression templates, move semantics don&#39;t completely solve =
the problem and I believe that expression templates will also be necessary =
as long as C++ looks anything like C++:<div>
<br></div><div>- Some small (and not so small) matrices can be implemented =
in the stack, thus making move behave exactly like copy.</div><div>- If you=
&#39;re doing something like a+b+c, it is usually faster to run a single lo=
op than to first do a+b and then add c, even if there is no copy involved.<=
/div>
<div>- Some expressions might have completely different implementations dep=
ending on how they are combined. For example, in my matrix library, I use t=
he syntax a.I() to represent the inverse of a matrix. Of course, to compute=
 b*a.I(), there are better ways to do it than to compute the inverse and th=
en multiply, so I only want to actually compute the inverse if it is not in=
volved on a product, so I need an expression template until I know what hap=
pens to it. Then, if I do auto b=3Da.I(), I actually want to compute the in=
verse and b should be a matrix, not the expression template, which might co=
ntain references to temporaries.</div>
<div><br></div><div>It&#39;s just ugly to force users to use eval() constan=
tly, and sometimes redundantly, because in many cases to know whether eval =
is necessary or not requires knowing too many about the implementation.</di=
v>
<div><br></div><div>So I believe that even if this functionality will only =
be used by implementors of a particular type of library, it will benefit al=
l the users of these libraries, and it will isolate them from expression te=
mplates, which are just implementation details.<br>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/10/13 Jo=
el Falcou <span dir=3D"ltr">&lt;<a href=3D"mailto:joel.falcou@gmail.com" ta=
rget=3D"_blank">joel.falcou@gmail.com</a>&gt;</span><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
Did you look at <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pape=
rs/2013/n3748.pdf" target=3D"_blank">http://www.open-std.org/jtc1/<u></u>sc=
22/wg21/docs/papers/2013/<u></u>n3748.pdf</a> ?<div class=3D"HOEnZb"><div c=
lass=3D"h5">
<br></div></div></blockquote><div>=A0Thanks for the link! I hadn&#39;t seen=
 it.=A0</div><div>I especially like the using syntax, which is almost ident=
ical to the typedef I proposed, but it looks a bit more C++11.=A0</div><div=
>I don&#39;t think the explicit notation is necessary at all. I would propo=
se that the overridden conversion works only for auto (and maybe const auto=
&amp; and similar when they extend the lifetime of a temporary) but they do=
n&#39;t apply to things like decltype(a+b) or even decltype(auto), making i=
t easy to obtain the real type of the expression.</div>
<div>Also, I don&#39;t think that they have to apply to template argument d=
eduction (as suggested in section 5), because the main argument for this pr=
oposal is that it would prevent having dangling references to dead temporar=
ies, and this wouldn&#39;t be a problem when passing the expression templat=
es to other functions. Also, that would make the implementation of the libr=
ary dealing with the expression templates much more cumbersome, since in th=
ere you actually want the deduced types to be the expression templates them=
selves.</div>
<div>Finally, I don&#39;t share the compatibility concerns expressed in sec=
tion 4, since it wouldn&#39;t change the meaning of any currently valid pro=
gram.</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b86f2949a352b04e8a11645--

.

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

On 13/10/2013 17:34, xavi wrote:
> - Some expressions might have completely different implementations
> depending on how they are combined. For example, in my matrix library,
> I use the syntax a.I() to represent the inverse of a matrix. Of
> course, to compute b*a.I(), there are better ways to do it than to
> compute the inverse and then multiply, so I only want to actually
> compute the inverse if it is not involved on a product, so I need an
> expression template until I know what happens to it. Then, if I do
> auto b=a.I(), I actually want to compute the inverse and b should be a
> matrix, not the expression template, which might contain references to
> temporaries.

Ditto here. In NT2, the HPC matlab like EDSL C++library my laboratory
tram and company co-author, we have a generalized pass to retype large
part of EDSL AST if they match domain specific algortihm. This is
somethign move semantic can do. EDSL usign expression templates still
are useful for AST rewriting as you say.

>
> It's just ugly to force users to use eval() constantly, and sometimes
> redundantly, because in many cases to know whether eval is necessary
> or not requires knowing too many about the implementation.

It also breaks the intuitive API EDSL brings to the table.
>
>
> 2013/10/13 Joel Falcou <joel.falcou@gmail.com
> <mailto:joel.falcou@gmail.com>>
>
>     Did you look at
>     http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3748.pdf ?
>
>  Thanks for the link! I hadn't seen it.
> I especially like the using syntax, which is almost identical to the
> typedef I proposed, but it looks a bit more C++11.
> I don't think the explicit notation is necessary at all. I would
> propose that the overridden conversion works only for auto (and maybe
> const auto& and similar when they extend the lifetime of a temporary)
> but they don't apply to things like decltype(a+b) or even
> decltype(auto), making it easy to obtain the real type of the expression.
> Also, I don't think that they have to apply to template argument
> deduction (as suggested in section 5), because the main argument for
> this proposal is that it would prevent having dangling references to
> dead temporaries, and this wouldn't be a problem when passing the
> expression templates to other functions. Also, that would make the
> implementation of the library dealing with the expression templates
> much more cumbersome, since in there you actually want the deduced
> types to be the expression templates themselves.
> Finally, I don't share the compatibility concerns expressed in section
> 4, since it wouldn't change the meaning of any currently valid program.

We'll probably have to revise this document so thanks for your insight.

--

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

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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 13/10/2013 17:34, xavi wrote:<br>
    </div>
    <blockquote
cite="mid:CAOUeGfvVYP-+TbJX44r7yku3MqGi+DG8EZRR61kAsB5mrQWPyg@mail.gmail.com"
      type="cite">
      <div dir="ltr">- Some expressions might have completely different
        implementations depending on how they are combined. For example,
        in my matrix library, I use the syntax a.I() to represent the
        inverse of a matrix. Of course, to compute b*a.I(), there are
        better ways to do it than to compute the inverse and then
        multiply, so I only want to actually compute the inverse if it
        is not involved on a product, so I need an expression template
        until I know what happens to it. Then, if I do auto b=a.I(), I
        actually want to compute the inverse and b should be a matrix,
        not the expression template, which might contain references to
        temporaries.</div>
    </blockquote>
    <br>
    Ditto here. In NT2, the HPC matlab like EDSL C++library my
    laboratory tram and company co-author, we have a generalized pass to
    retype large part of EDSL AST if they match domain specific
    algortihm. This is somethign move semantic can do. EDSL usign
    expression templates still are useful for AST rewriting as you say.<br>
    &nbsp;<br>
    <blockquote
cite="mid:CAOUeGfvVYP-+TbJX44r7yku3MqGi+DG8EZRR61kAsB5mrQWPyg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>It's just ugly to force users to use eval() constantly, and
          sometimes redundantly, because in many cases to know whether
          eval is necessary or not requires knowing too many about the
          implementation.</div>
      </div>
    </blockquote>
    <br>
    It also breaks the intuitive API EDSL brings to the table.<br>
    <blockquote
cite="mid:CAOUeGfvVYP-+TbJX44r7yku3MqGi+DG8EZRR61kAsB5mrQWPyg@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div>
          <div class="gmail_extra"><br>
            <div class="gmail_quote">2013/10/13 Joel Falcou <span
                dir="ltr">&lt;<a moz-do-not-send="true"
                  href="mailto:joel.falcou@gmail.com" target="_blank">joel.falcou@gmail.com</a>&gt;</span><br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                Did you look at <a moz-do-not-send="true"
                  href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3748.pdf"
                  target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3748.pdf</a>
                ?
                <div class="HOEnZb">
                  <div class="h5">
                    <br>
                  </div>
                </div>
              </blockquote>
              <div>&nbsp;Thanks for the link! I hadn't seen it.&nbsp;</div>
              <div>I especially like the using syntax, which is almost
                identical to the typedef I proposed, but it looks a bit
                more C++11.&nbsp;</div>
              <div>I don't think the explicit notation is necessary at
                all. I would propose that the overridden conversion
                works only for auto (and maybe const auto&amp; and
                similar when they extend the lifetime of a temporary)
                but they don't apply to things like decltype(a+b) or
                even decltype(auto), making it easy to obtain the real
                type of the expression.</div>
              <div>Also, I don't think that they have to apply to
                template argument deduction (as suggested in section 5),
                because the main argument for this proposal is that it
                would prevent having dangling references to dead
                temporaries, and this wouldn't be a problem when passing
                the expression templates to other functions. Also, that
                would make the implementation of the library dealing
                with the expression templates much more cumbersome,
                since in there you actually want the deduced types to be
                the expression templates themselves.</div>
              <div>Finally, I don't share the compatibility concerns
                expressed in section 4, since it wouldn't change the
                meaning of any currently valid program.</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    We'll probably have to revise this document so thanks for your
    insight.<br>
    <br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--------------000207070100090307080502--

.

------=_Part_108_21589863.1381738343962
Content-Type: text/plain; charset=ISO-8859-1

Il giorno domenica 13 ottobre 2013 17:34:33 UTC+2, Xavi Gratal ha scritto:

> So I believe that even if this functionality will only be used by
> implementors of a particular type of library, it will benefit all the users
> of these libraries, and it will isolate them from expression templates,
> which are just implementation details.
>

sorry for the intrusion, but

as a user of these libraries, I'd say that expression templates are not
implementation details. I mean, <knowing> that some expression will be
evaluated lazily, exploiting every possible bit of compile-time information
available ( eventually extending the library on my own as well ), is the
very reason I'd use such a library in the first place.
So, instead of hijacking the auto deduction rules, why not trying to make
expression templates safer to use as non-temporaries instead ( a feature
I'd find useful on its own BTW ) ?
For example, by marking a constructor as, say, "persist MyClass( ... )"
then, given an initializing expression of an &&/const& reference R,
temporaries of type MyClass ( whereever they appear ) could be
automatically life-extended to the scope of R.

--

---
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_108_21589863.1381738343962
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Il giorno domenica 13 ottobre 2013 17:34:33 UTC+2, Xavi Gr=
atal ha scritto:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>So I believe that even if this functionality will only be use=
d by implementors of a particular type of library, it will benefit all the =
users of these libraries, and it will isolate them from expression template=
s, which are just implementation details.<br></div></div></blockquote><div>=
<br>sorry for the intrusion, but<br><br>as a user of these libraries, I'd s=
ay that expression templates are not implementation details. I mean, &lt;kn=
owing&gt; that some expression will be evaluated lazily, exploiting every p=
ossible bit of compile-time information available ( eventually extending th=
e library on my own as well ), is the very reason I'd use such a library in=
 the first place.<br>So, instead of hijacking the auto deduction rules, why=
 not trying to make expression templates safer to use as non-temporaries in=
stead ( a feature I'd find useful on its own BTW ) ?<br>For example, by mar=
king a constructor as, say, "persist MyClass( ... )" then, given an initial=
izing expression of an &amp;&amp;/const&amp; reference R, temporaries of ty=
pe MyClass ( whereever they appear ) could be automatically life-extended t=
o the scope of R. <br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_108_21589863.1381738343962--

.

--e89a8ff1ccd2fc31cc04e8b042f1
Content-Type: text/plain; charset=ISO-8859-1

2013/10/14 MJanes <max.jns@gmail.com>

> Il giorno domenica 13 ottobre 2013 17:34:33 UTC+2, Xavi Gratal ha scritto:
>
> So I believe that even if this functionality will only be used by
>> implementors of a particular type of library, it will benefit all the users
>> of these libraries, and it will isolate them from expression templates,
>> which are just implementation details.
>>
>
> sorry for the intrusion, but
>
Any comment is appreciated!

>
> as a user of these libraries, I'd say that expression templates are not
> implementation details. I mean, <knowing> that some expression will be
> evaluated lazily, exploiting every possible bit of compile-time information
> available ( eventually extending the library on my own as well ), is the
> very reason I'd use such a library in the first place.
>
I'd say there are two different things here. Whether an expression will be
evaluated lazily is something the author should provide in the
documentation and/or the description of the interfaces. How this is
actually achieved internally, that's an implementation detail users should
not care about, because the author should be able to change it in order to
improve the library, as long as it doesn't modify the API (interface
description included). If you want to modify the library, or extend it in
ways that are not supported through the provided interfaces, that's
perfectly ok, but that doesn't mean they are not implementation details, it
means that you want to look at the implementation details.


> So, instead of hijacking the auto deduction rules, why not trying to make
> expression templates safer to use as non-temporaries instead ( a feature
> I'd find useful on its own BTW ) ?
> For example, by marking a constructor as, say, "persist MyClass( ... )"
> then, given an initializing expression of an &&/const& reference R,
> temporaries of type MyClass ( whereever they appear ) could be
> automatically life-extended to the scope of R.
>
I don't know how hard it would be to implement this (my guess is not easy).
Also, that should be an attribute of the reference, not the class, because
sometimes you want to store references to types that are not even part of
the library. It would also only work for header-only implementations, since
the compiler should need to track all temporaries to see which ones are
assigned to the variables.
It also only solves the problem with real temporaries, not with objects
which are destroyed or assigned to. Consider the example:

auto c=a+b; //b is an expression template containing references to a and b
a=b; //a changed value!! that's certainly not what users of the library
would expect

Finally, dangling references is not the only reason why someone would want
to hide expression templates. Most expression templates, for example one
that refers to a matrix product are supposed to be consumed only once, for
efficiency reasons. If the user had a reference to an expression template,
they could use it in several expressions, causing the same product to be
computed multiple times.

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

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quo=
te">2013/10/14 MJanes <span dir=3D"ltr">&lt;<a href=3D"mailto:max.jns@gmail=
..com" target=3D"_blank">max.jns@gmail.com</a>&gt;</span><br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<div dir=3D"ltr">Il giorno domenica 13 ottobre 2013 17:34:33 UTC+2, Xavi Gr=
atal ha scritto:<div class=3D"im"><br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">
<div>So I believe that even if this functionality will only be used by impl=
ementors of a particular type of library, it will benefit all the users of =
these libraries, and it will isolate them from expression templates, which =
are just implementation details.<br>
</div></div></blockquote></div><div><br>sorry for the intrusion, but<br></d=
iv></div></blockquote><div>Any comment is appreciated!=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
<div dir=3D"ltr"><div><br>as a user of these libraries, I&#39;d say that ex=
pression templates are not implementation details. I mean, &lt;knowing&gt; =
that some expression will be evaluated lazily, exploiting every possible bi=
t of compile-time information available ( eventually extending the library =
on my own as well ), is the very reason I&#39;d use such a library in the f=
irst place.<br>
</div></div></blockquote><div>I&#39;d say there are two different things he=
re. Whether an expression will be evaluated lazily is something the author =
should provide in the documentation and/or the description of the interface=
s. How this is actually achieved internally, that&#39;s an implementation d=
etail users should not care about, because the author should be able to cha=
nge it in order to improve the library, as long as it doesn&#39;t modify th=
e API (interface description included). If you want to modify the library, =
or extend it in ways that are not supported through the provided interfaces=
, that&#39;s perfectly ok, but that doesn&#39;t mean they are not implement=
ation details, it means that you want to look at the implementation details=
..</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>So, inst=
ead of hijacking the auto deduction rules, why not trying to make expressio=
n templates safer to use as non-temporaries instead ( a feature I&#39;d fin=
d useful on its own BTW ) ?<br>
For example, by marking a constructor as, say, &quot;persist MyClass( ... )=
&quot; then, given an initializing expression of an &amp;&amp;/const&amp; r=
eference R, temporaries of type MyClass ( whereever they appear ) could be =
automatically life-extended to the scope of R.=A0</div>
</div></blockquote><div>I don&#39;t know how hard it would be to implement =
this (my guess is not easy). Also, that should be an attribute of the refer=
ence, not the class, because sometimes you want to store references to type=
s that are not even part of the library. It would also only work for header=
-only implementations, since the compiler should need to track all temporar=
ies to see which ones are assigned to the variables.</div>
<div>It also only solves the problem with real temporaries, not with object=
s which are destroyed or assigned to. Consider the example:</div><div><br><=
/div><div>auto c=3Da+b; //b is an expression template containing references=
 to a and b</div>
<div>a=3Db; //a changed value!! that&#39;s certainly not what users of the =
library would expect</div><div><br></div><div>Finally, dangling references =
is not the only reason why someone would want to hide expression templates.=
 Most expression templates, for example one that refers to a matrix product=
 are supposed to be consumed only once, for efficiency reasons. If the user=
 had a reference to an expression template, they could use it in several ex=
pressions, causing the same product to be computed multiple times.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div cl=
ass=3D"h5">-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--e89a8ff1ccd2fc31cc04e8b042f1--

.

------=_Part_2872_33536669.1381744585982
Content-Type: text/plain; charset=ISO-8859-1

Not to mention the issue of stuff like (a + b).c_str();. If you use the
persist idea, then you have to re-implement the entire interface of your
class. An automatic conversion would not require this.

--

---
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_2872_33536669.1381744585982
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">Not to mention the issue of stuff like (a + b).c_str();. If you use the persist idea, then you have to re-implement the entire interface of your class. An automatic conversion would not require this.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_2872_33536669.1381744585982--

.

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

Il giorno luned=EC 14 ottobre 2013 11:40:42 UTC+2, Xavi Gratal ha scritto:

> I'd say there are two different things here. Whether an expression will b=
e=20
> evaluated lazily is something the author should provide in the=20
> documentation and/or the description of the interfaces. How this is=20
> actually achieved internally, that's an implementation detail users shoul=
d=20
> not care about, because the author should be able to change it in order t=
o=20
> improve the library, as long as it doesn't modify the API (interface=20
> description included). If you want to modify the library, or extend it in=
=20
> ways that are not supported through the provided interfaces, that's=20
> perfectly ok, but that doesn't mean they are not implementation details, =
it=20
> means that you want to look at the implementation details.
>
>
ok, but put in another way, IMO I <expect> from an expression template=20
library to allow me adding my own functionality ( say, if I come up with an=
=20
algorithm optimizing the product of matrices of certain kind, say,=20
belonging to specific algebras ) and hence I expect that the types involved=
=20
in an expression template at least are models of a prescribed concept or,=
=20
in other words, they are not "internal" to the library to some degree, and=
=20
hence are accessible by the user. For this reason, I don't consider immoral=
=20
for me to say "auto expr =3D ..." meaning "give to this <unevaluated=20
expression> the name expr".
=20

>  Also, that should be an attribute of the reference, not the class,=20
> because sometimes you want to store references to types that are not even=
=20
> part of the library.
>

yeah, that's a problem; may I ask you to make an example of such a use case=
=20
( having no reasonable workaround ) ?
=20

> a=3Db; //a changed value!! that's certainly not what users of the library=
=20
> would expect
>

why ? ideally, in my mind a lazy-expression is exactly a reference-like=20
object, so if I write "auto c=3Da+b; do_something_with(c); a =3D foo();=20
do_something_with(c);" I would expect the behavior of do_something_with to=
=20
change accordingly after the "a" assignment.
=20

> Finally, dangling references is not the only reason why someone would wan=
t=20
> to hide expression templates. Most expression templates, for example one=
=20
> that refers to a matrix product are supposed to be consumed only once, fo=
r=20
> efficiency reasons. If the user had a reference to an expression template=
,=20
> they could use it in several expressions, causing the same product to be=
=20
> computed multiple times.
>

the library author could give two flavors of multiplications, allowing=20
single and multiple invocations, respectively. For the single invocation=20
case, it would be said in the documentation what happens when multiple=20
invocations occur ( including UB ). The library author and/or the user will=
=20
decide which one should be the default multiplication and which one should=
=20
be explicitly requested instead ( say, auto expr =3D multicallable( ... ); =
).

so, I understand that the persist idea cannot solve these problems <given=
=20
the way expression templates libraries are currrently designed>. But, the=
=20
problem is, could a slightly different design/semantics + better temporary=
=20
lifetime management do it ? ( I'm also thinking at alternative solutions=20
like the Ref-qualified destructors idea ).=20

@DeadMG

> Not to mention the issue of stuff like (a + b).c_str();.
>

could you elaborate ? to clarify, the hypothetical persist constructor=20
would trigger lifetime extension only in those initialization where a=20
temporary gets bound to a reference ( say, "T&& t =3D T(V());", here, if V(=
)=20
is persist, than its lifetime gets bound to t ... ).=20

--=20

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

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

<div dir=3D"ltr">Il giorno luned=EC 14 ottobre 2013 11:40:42 UTC+2, Xavi Gr=
atal ha scritto:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div>I'd say there are two differe=
nt things here. Whether an expression will be evaluated lazily is something=
 the author should provide in the documentation and/or the description of t=
he interfaces. How this is actually achieved internally, that's an implemen=
tation detail users should not care about, because the author should be abl=
e to change it in order to improve the library, as long as it doesn't modif=
y the API (interface description included). If you want to modify the libra=
ry, or extend it in ways that are not supported through the provided interf=
aces, that's perfectly ok, but that doesn't mean they are not implementatio=
n details, it means that you want to look at the implementation details.</d=
iv><br><div></div></div></div></div></blockquote><div><br>ok, but put in an=
other way, IMO I &lt;expect&gt; from an expression template library to allo=
w me adding my own functionality ( say, if I come up with an algorithm opti=
mizing the product of matrices of certain kind, say, belonging to specific =
algebras ) and hence I expect that the types involved in an expression temp=
late at least are models of a prescribed concept or, in other words, they a=
re not "internal" to the library to some degree, and hence are accessible b=
y the user. For this reason, I don't consider immoral for me to say "auto e=
xpr =3D ..." meaning "give to this &lt;unevaluated expression&gt; the name =
expr".<br>&nbsp;</div><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"><div><div class=3D"gmail_quote"><div>&nbsp;Also, that should be an=
 attribute of the reference, not the class, because sometimes you want to s=
tore references to types that are not even part of the library.</div></div>=
</div></div></blockquote><div><br>yeah, that's a problem; may I ask you to =
make an example of such a use case ( having no reasonable workaround ) ?<br=
>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div>a=3Db; //a changed value!! that's cert=
ainly not what users of the library would expect</div></div></div></div></b=
lockquote><div><br>why ? ideally, in my mind a lazy-expression is exactly a=
 reference-like object, so if I write "auto c=3Da+b; do_something_with(c); =
a =3D foo(); do_something_with(c);" I would expect the behavior of do_somet=
hing_with to change accordingly after the "a" assignment.<br>&nbsp;<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div c=
lass=3D"gmail_quote"><div>Finally, dangling references is not the only reas=
on why someone would want to hide expression templates. Most expression tem=
plates, for example one that refers to a matrix product are supposed to be =
consumed only once, for efficiency reasons. If the user had a reference to =
an expression template, they could use it in several expressions, causing t=
he same product to be computed multiple times.</div></div></div></div></blo=
ckquote><div><br>the library author could give two flavors of multiplicatio=
ns, allowing single and multiple invocations, respectively. For the single =
invocation case, it would be said in the documentation what happens when mu=
ltiple invocations occur ( including UB ). The library author and/or the us=
er will decide which one should be the default multiplication and which one=
 should be explicitly requested instead ( say, auto expr =3D multicallable(=
 ... ); ).<br><br>so, I understand that the persist idea cannot solve these=
 problems &lt;given the way expression templates libraries are currrently d=
esigned&gt;. But, the problem is, could a slightly different design/semanti=
cs + better temporary lifetime management do it ? ( I'm also thinking at al=
ternative solutions like the Ref-qualified destructors idea ). <br><br>@Dea=
dMG<br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px sol=
id rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">Not to men=
tion the issue of stuff like (a + b).c_str();.<br></blockquote><div><br>cou=
ld you elaborate ? to clarify, the hypothetical persist constructor would t=
rigger lifetime extension only in those initialization where a temporary ge=
ts bound to a reference ( say, "T&amp;&amp; t =3D T(V());", here, if V() is=
 persist, than its lifetime gets bound to t ... ). <br></div></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_72_32293896.1381747852077--

.

On 14/10/2013 12:50, MJanes wrote:
> The library author could give two flavors of multiplications, allowing
> single and multiple invocations, respectively. For the single
> invocation case, it would be said in the documentation what happens
> when multiple invocations occur ( including UB ). The library author
> and/or the user will decide which one should be the default
> multiplication and which one should be explicitly requested instead (
> say, auto expr = multicallable( ... ); ).
>

Boost.Proto (an EDSL toolkit from boost) has a deep_copy function that
turns a lazy stuff into a copy of all its contents, eliminating the
issue of lifetime at the cost of more copies. Is it somethign akin to
what you have in mind ?

--

---
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_3197_8366872.1381767533231
Content-Type: text/plain; charset=ISO-8859-1



On Saturday, October 12, 2013 6:40:21 PM UTC+1, Xavi Gratal wrote:
>
> I know it's been a while, but has this gotten anywhere near an actual
> proposal?
>

It seems to me that this is n3748:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3748.pdf

HTH,
Cassio.

--

---
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_3197_8366872.1381767533231
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, October 12, 2013 6:40:21 PM UTC+1, Xa=
vi Gratal wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">I know it's been a while, but has this gotten anywhere near an actual pr=
oposal?</div></blockquote><div><br>It seems to me that this is n3748:<br>ht=
tp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3748.pdf<br><br>HTH,=
<br>Cassio.<br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_3197_8366872.1381767533231--

.