Topic: optional<string> os = "foo"; // char * to string
Author: Tony V E <tvaneerd@gmail.com>
Date: Sun, 1 Sep 2013 12:05:20 -0400
Raw View
--001a1133aa865e13b404e5549fd0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Is this suppose to work:
optional<string> os =3D "foo";
template <class U> optional<T>& optional<T>::operator=3D(U&& v);
Requires:
is_constructible<T, U>::value is true and is_assignable<U, T>::value is tru=
e
..
Remarks:
The function shall not participate in overload resolution unless
is_same<typename
remove_reference<U>::type, T>::value is true.
[*Note:* The reason to provide such generic assignment and then
constraining it so that effectively T =3D=3D U is to guarantee that assignm=
ent
of the form o =3D {} is unambiguous. =97*end note*]
Is it constrained such that T =3D=3D U, or just that T =3D=3D U for this ca=
se
specifically:
optional<string> os =3D {};
I read the Requires clause as saying os =3D "foo" should work, but the Note
as saying it won't.
And the Remarks I'm not sure, as I am unsure whether "overload resolution"
is just for the {} case.
If it really means T =3D=3D U must always be true, why not just put the
is_same<> into the Requires clause instead of the Remarks?
Tony
--=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/.
--001a1133aa865e13b404e5549fd0
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Is this suppose to work:<br><br></div>optional<str=
ing> os =3D "foo";<br><br><div><p class=3D"">
<code>template <class U> optional<T>& optional<T>::=
operator=3D(U&& <var>v</var>);</code>
</p>
=20
<dl class=3D""><dt>Requires:</dt><dd><p><code>is_constructible<T, U>=
;::value</code> is <code>true</code> and <code>is_assignable<U, T>::v=
alue</code> is <code>true</code>.</p></dd><dt>Remarks:</dt><dd><p>The funct=
ion shall not participate in overload resolution unless <code>is_same<t=
ypename remove_reference<U>::type, T>::value</code> is <code>true=
</code>.
</p></dd></dl>
<p>[<i>Note:</i> The reason to provide such generic assignment and then c=
onstraining it so that effectively <code>T</code> =3D=3D <code>U</code> is =
to guarantee that assignment of the form <code>o =3D {}</code> is unambiguo=
us. =97<i>end note</i>]</p>
<br><br></div><div>Is it constrained such that T =3D=3D U, or just that T =
=3D=3D U for this case specifically:<br><br>optional<string> os =3D {=
};<br><br></div><div>I read the Requires clause as saying os =3D "foo&=
quot; should work, but the Note as saying it won't.<br>
</div><div>And the Remarks I'm not sure, as I am unsure whether "o=
verload resolution"=A0 is just for the {} case.<br><br></div><div>If i=
t really means T =3D=3D U must always be true, why not just put the is_same=
<> into the Requires clause instead of the Remarks?<br>
<br></div><div>Tony<br></div><div><br><br></div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a1133aa865e13b404e5549fd0--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Sun, 1 Sep 2013 21:38:23 +0200
Raw View
2013/9/1 Tony V E <tvaneerd@gmail.com>:
> Is this suppose to work:
>
> optional<string> os =3D "foo";
I would say "no" at the moment (being consistent with
std::tuple<std::string>) based on the specified member functions. This
seems also consistent with the implementation of boost::optional.
> template <class U> optional<T>& optional<T>::operator=3D(U&& v);
>
> Requires:
>
> is_constructible<T, U>::value is true and is_assignable<U, T>::value is
> true.
For the sake of this discussion I assume the acceptance of the P/R proposed=
in
http://cplusplus.github.io/LWG/lwg-active.html#2282
which is IMO an obvious oversight.
In *either* case, a requirement is a contract imposed by the
provider/caller, but given that this is a constrained template
(constraints specified by the Remarks element which is normative), the
requirement cannot apply *before* the constrained holds, since it
refers to the actually selected entity. See below for details.
> Remarks:
>
> The function shall not participate in overload resolution unless
> is_same<typename remove_reference<U>::type, T>::value is true.
>
> [Note: The reason to provide such generic assignment and then constrainin=
g
> it so that effectively T =3D=3D U is to guarantee that assignment of the =
form o
> =3D {} is unambiguous. =97end note]
>
> Is it constrained such that T =3D=3D U, or just that T =3D=3D U for this =
case
> specifically:
>
> optional<string> os =3D {};
I assume you mean:
optional<string> os =3D ...;
os =3D {};
because the above mentioned initialization should select the default
constructor of optional<string> instead (it is an a non-explicit one).
Now looking a second time at this assignment expression, it seems to
me that the core language (5.17 [expr.ass] p9) already says that the
effects are equal to
os =3D optional<string>{};
But ignoring that "detail" I don't see any other reasonable
interpretation than the former.
> I read the Requires clause as saying os =3D "foo" should work, but the No=
te as
> saying it won't.
I don't think that you can conclude this from the requirements. They
are imposed upon the instantiated template, but that can only be
valid, after overload resolution has succeeded (There are rare
situations where the definition of a function template can be
instantiated before that success, but that must be caught by an
implementation, I think). Conversion from expressions that have a type
different from T (in this case different from string) will not be
performed by the here discussed assignment template. Note that most
other - but not your original "converting" example - should still be
valid, because given the existing constructor
constexpr optional(const T& v);
the conversion the argument to T will just happen implicitly and after
that invoke the copy assignment operator. This was one of the reasons
why pair and tuple do provide additional non-template constructors
from the element types. This ensures that e.g.
std::tuple<int*> ti =3D 0;
ti =3D 0;
is valid. The same should IMO hold for optional:
std::optional<int*> oi =3D 0; // OK, selects constexpr optional(const T&);
oi =3D 0; // Also OK
It does not apply to the conversion from a string literal to a
std::optional<std::string> value, because that would require two
user-defined conversions.
> And the Remarks I'm not sure, as I am unsure whether "overload resolution=
"
> is just for the {} case.
The Remarks element does not refer to any *specific* case, it just
says that for the sake of overload resolution the above constraints
have to be applied by an implementation.
> If it really means T =3D=3D U must always be true, why not just put the
> is_same<> into the Requires clause instead of the Remarks?
I'm pretty sure that this assumption holds, but your alternative would
not realize that. Note that a violation of a requirement is UB, it
could allow an implementation to give a compile error or not, It might
give a runtime assertions or not. We do have the "shall not
participate in overload resolution" wording as a substitute for real
language constraints to prevent cases to enter compile-errors or
undefined behaviour where we consider that the costs of sfinae-like
constraints are worth it. We really want here to say when this
constructor template definition might be instantiated.
- Daniel
--=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/.
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Sun, 1 Sep 2013 21:50:03 +0200
Raw View
2013/9/1 Daniel Kr=FCgler <daniel.kruegler@gmail.com>:
> 2013/9/1 Tony V E <tvaneerd@gmail.com>:
>> Is this suppose to work:
>>
>> optional<string> os =3D "foo";
>
> I would say "no" at the moment (being consistent with
> std::tuple<std::string>) based on the specified member functions.
I should add that the comparison with std::tuple<std::string> is a bad
one, and will be fixed if (the revision of)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3680.html
would be accepted, because tuple provides additional converting
constructors. At the moment this one is explicit, but with the
suggested change following N3680 is would become well-formed.
- Daniel
--=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/.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 2 Sep 2013 01:35:11 -0700 (PDT)
Raw View
------=_Part_2653_23270302.1378110911670
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu niedziela, 1 wrze=B6nia 2013 18:05:20 UTC+2 u=BFytkownik Tony V E=20
napisa=B3:
>
> Is this suppose to work:
>
> optional<string> os =3D "foo";
>
Our intention was that the above example does not work. One would have to=
=20
use other constructs:
optional<string> os{"foo"};
optional<string> os =3D "foo"s;
Regards,
&rzej
=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_2653_23270302.1378110911670
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu niedziela, 1 wrze=B6nia 2013 18:05:20 UTC+2=
u=BFytkownik Tony V E napisa=B3:<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>Is this suppose to work:<br><br></div>optional<=
string> os =3D "foo";<br></div></blockquote><div dir=3D"ltr"><br>Our int=
ention was that the above example does not work. One would have to use othe=
r constructs:<br><div class=3D"prettyprint" style=3D"background-color: rgb(=
250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bord=
er-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">optional</span><span style=3D"color: #080;" class=3D"styled-by-prettif=
y"><string></span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> os</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"foo"</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br>optional</span><sp=
an style=3D"color: #080;" class=3D"styled-by-prettify"><string></span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> os </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">"foo"</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">s</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span></div></code></div>Regards,<br>&rzej<br> =
;<br><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_2653_23270302.1378110911670--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 2 Sep 2013 01:51:44 -0700 (PDT)
Raw View
------=_Part_2491_15624847.1378111904730
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
On Monday, September 2, 2013 4:35:11 PM UTC+8, Andrzej Krzemie=F1ski wrote:
>
>
> W dniu niedziela, 1 wrze=B6nia 2013 18:05:20 UTC+2 u=BFytkownik Tony V E=
=20
> napisa=B3:
>>
>> Is this suppose to work:
>>
>> optional<string> os =3D "foo";
>>
>
> Our intention was that the above example does not work. One would have to=
=20
> use other constructs:
>
There seems to be a lot of noise and confusion about what proxies should=20
do. More is not necessarily better. Is there any resource from Boost or=20
elsewhere which might help categorize applications of proxy classes and=20
provide interface guidelines? It could help streamline the proposal process=
=20
and provide a handy reference for this forum.
--=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_2491_15624847.1378111904730
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Monday, September 2, 2013 4:35:11 PM UTC+8, Andrzej=
Krzemie=F1ski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br>W dniu niedziela, 1 wrze=B6nia 2013 18:05:20 UTC+2 u=BFytkowni=
k Tony V E napisa=B3:<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"lt=
r"><div>Is this suppose to work:<br><br></div>optional<string> os =3D=
"foo";<br></div></blockquote><div dir=3D"ltr"><br>Our intention was that t=
he above example does not work. One would have to use other constructs:<br>=
</div></div></blockquote><div><br>There seems to be a lot of noise and conf=
usion about what proxies should do. More is not necessarily better. Is ther=
e any resource from Boost or elsewhere which might help categorize applicat=
ions of proxy classes and provide interface guidelines? It could help strea=
mline the proposal process and provide a handy reference for this forum.<br=
></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_2491_15624847.1378111904730--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Mon, 2 Sep 2013 03:51:19 -0700 (PDT)
Raw View
------=_Part_1012_29170264.1378119079721
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu poniedzia=B3ek, 2 wrze=B6nia 2013 10:51:44 UTC+2 u=BFytkownik David =
Krauss=20
napisa=B3:
>
>
> On Monday, September 2, 2013 4:35:11 PM UTC+8, Andrzej Krzemie=F1ski wrot=
e:
>>
>>
>> W dniu niedziela, 1 wrze=B6nia 2013 18:05:20 UTC+2 u=BFytkownik Tony V E=
=20
>> napisa=B3:
>>>
>>> Is this suppose to work:
>>>
>>> optional<string> os =3D "foo";
>>>
>>
>> Our intention was that the above example does not work. One would have t=
o=20
>> use other constructs:
>>
>
> There seems to be a lot of noise and confusion about what proxies should=
=20
> do. More is not necessarily better. Is there any resource from Boost or=
=20
> elsewhere which might help categorize applications of proxy classes and=
=20
> provide interface guidelines? It could help streamline the proposal proce=
ss=20
> and provide a handy reference for this forum.
>
Term "proxy" appears to be ambiguous, so it is difficult to answer your=20
question. I am not sure if it helps, but while working on the proposal we=
=20
formed a type requirements "NullableProxy" that generalizes the way the=20
value is accessed in such objects: search for section "Type requirement=20
NullableProxy" in=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3527.html. But=20
these requirements are concerned with accessing the value rather than=20
creating one. The interface for std::optional was discussed as a unique=20
being rather than a special case of a general "proxy" class of types.
--=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_1012_29170264.1378119079721
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu poniedzia=B3ek, 2 wrze=B6nia 2013 10:51:44 =
UTC+2 u=BFytkownik David Krauss napisa=B3:<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"><br>On Monday, September 2, 2013 4:35:11 PM UT=
C+8, Andrzej Krzemie=F1ski wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><br>W dniu niedziela, 1 wrze=B6nia 2013 18:05:20 UTC+2 u=BFy=
tkownik Tony V E napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>Is this suppose to work:<br><br></div>optional<string> =
os =3D "foo";<br></div></blockquote><div dir=3D"ltr"><br>Our intention was =
that the above example does not work. One would have to use other construct=
s:<br></div></div></blockquote><div><br>There seems to be a lot of noise an=
d confusion about what proxies should do. More is not necessarily better. I=
s there any resource from Boost or elsewhere which might help categorize ap=
plications of proxy classes and provide interface guidelines? It could help=
streamline the proposal process and provide a handy reference for this for=
um.<br></div></div></blockquote><div><br>Term "proxy" appears to be ambiguo=
us, so it is difficult to answer your question. I am not sure if it helps, =
but while working on the proposal we formed a type requirements "NullablePr=
oxy" that generalizes the way the value is accessed in such objects: search=
for section "Type requirement NullableProxy" in <a href=3D"http://www.open=
-std.org/jtc1/sc22/wg21/docs/papers/2013/n3527.html">http://www.open-std.or=
g/jtc1/sc22/wg21/docs/papers/2013/n3527.html</a>. But these requirements ar=
e concerned with accessing the value rather than creating one. The interfac=
e for std::optional was discussed as a unique being rather than a special c=
ase of a general "proxy" class of types.<br><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_1012_29170264.1378119079721--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 2 Sep 2013 12:10:49 -0400
Raw View
--001a1133659cc9d7d204e568d02c
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
On Mon, Sep 2, 2013 at 4:51 AM, David Krauss <potswa@gmail.com> wrote:
>
> On Monday, September 2, 2013 4:35:11 PM UTC+8, Andrzej Krzemie=F1ski wrot=
e:
>>
>>
>> W dniu niedziela, 1 wrze=B6nia 2013 18:05:20 UTC+2 u=BFytkownik Tony V E
>> napisa=B3:
>>>
>>> Is this suppose to work:
>>>
>>> optional<string> os =3D "foo";
>>>
>>
>> Our intention was that the above example does not work. One would have t=
o
>> use other constructs:
>>
>
> There seems to be a lot of noise and confusion about what proxies should
> do. More is not necessarily better. Is there any resource from Boost or
> elsewhere which might help categorize applications of proxy classes and
> provide interface guidelines? It could help streamline the proposal proce=
ss
> and provide a handy reference for this forum.
>
>
>
>
I think, by the nature of the term 'proxy', a proxy is expected to act much
like the thing it is a proxy for. But obviously the proxy is somehow
different (else why use it at all), so it will also have its own interface.
So an ideal proxy would probably be a strict superset of the thing it
proxies - does every it does, plus the proxy interface itself.
Of course we typically can't reach that ideal (can't override dot operator
for one), so we make design tradeoffs.
For optional, it does, in many ways, act like the underlying class, but,
for example, it doesn't implicitly convert back to T, as that is dangerous
when the optional is disengaged. So it was felt that an explicit
dereference was better.
I ask about optional<string> os =3D "foo" because others have also been
asking about optional<string> os =3D=3D "foo" (comparison, not assign).
And if we were to allow optional<T> relop U and/or optional<T> relop
optional<U> then I'd wonder about assignment and construction as well.
Tony
On Mon, Sep 2, 2013 at 4:51 AM, David Krauss <potswa@gmail.com> wrote:
>
> On Monday, September 2, 2013 4:35:11 PM UTC+8, Andrzej Krzemie=F1ski wrot=
e:
>>
>>
>> W dniu niedziela, 1 wrze=B6nia 2013 18:05:20 UTC+2 u=BFytkownik Tony V E
>> napisa=B3:
>>>
>>> Is this suppose to work:
>>>
>>> optional<string> os =3D "foo";
>>>
>>
>> Our intention was that the above example does not work. One would have t=
o
>> use other constructs:
>>
>
> There seems to be a lot of noise and confusion about what proxies should
> do. More is not necessarily better. Is there any resource from Boost or
> elsewhere which might help categorize applications of proxy classes and
> provide interface guidelines? It could help streamline the proposal proce=
ss
> and provide a handy reference for this forum.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a1133659cc9d7d204e568d02c
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Mon, Sep 2, 2013 at 4:51 AM, David Krauss <span dir=3D"ltr"><=
<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"im"><br>On Monday, September 2, 2013 4:35:11 PM UTC+8, Andrzej Krzemi=
e=F1ski wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><br>W dniu niedziela, 1 wrze=B6nia 2013 18:05:20 UTC+2 u=
=BFytkownik Tony V E napisa=B3:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr">
<div>Is this suppose to work:<br><br></div>optional<string> os =3D &q=
uot;foo";<br></div></blockquote><div dir=3D"ltr"><br>Our intention was=
that the above example does not work. One would have to use other construc=
ts:<br>
</div></div></blockquote></div><div><br>There seems to be a lot of noise an=
d confusion about what proxies should do. More is not necessarily better. I=
s there any resource from Boost or elsewhere which might help categorize ap=
plications of proxy classes and provide interface guidelines? It could help=
streamline the proposal process and provide a handy reference for this for=
um.<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>I think, by the nature=
of the term 'proxy', a proxy is expected to act much like the thin=
g it is a proxy for.=A0 But obviously the proxy is somehow different (else =
why use it at all), so it will also have its own interface.<br>
<br></div><div>So an ideal proxy would probably be a strict superset of the=
thing it proxies - does every it does, plus the proxy interface itself.<br=
><br></div><div>Of course we typically can't reach that ideal (can'=
t override dot operator for one), so we make design tradeoffs.<br>
<br></div><div>For optional, it does, in many ways, act like the underlying=
class, but, for example, it doesn't implicitly convert back to T, as t=
hat is dangerous when the optional is disengaged.=A0 So it was felt that an=
explicit dereference was better.<br>
<br></div><div>I ask about optional<string> os =3D "foo" be=
cause others have also been asking about optional<string> os =3D=3D &=
quot;foo" (comparison, not assign).<br>And if we were to allow optiona=
l<T> relop U and/or optional<T> relop optional<U> then I&=
#39;d wonder about assignment and construction as well.<br>
<br></div><div>Tony<br>=A0<br></div></div><br></div></div><div class=3D"gma=
il_extra"><br><br><div class=3D"gmail_quote">On Mon, Sep 2, 2013 at 4:51 AM=
, David Krauss <span dir=3D"ltr"><<a href=3D"mailto:potswa@gmail.com" ta=
rget=3D"_blank">potswa@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><br>On Mo=
nday, September 2, 2013 4:35:11 PM UTC+8, Andrzej Krzemie=F1ski wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><br>W dniu niedziela, 1 wrze=B6nia 2013 18:05:20 UTC+2 u=
=BFytkownik Tony V E napisa=B3:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr">
<div>Is this suppose to work:<br><br></div>optional<string> os =3D &q=
uot;foo";<br></div></blockquote><div dir=3D"ltr"><br>Our intention was=
that the above example does not work. One would have to use other construc=
ts:<br>
</div></div></blockquote></div><div><br>There seems to be a lot of noise an=
d confusion about what proxies should do. More is not necessarily better. I=
s there any resource from Boost or elsewhere which might help categorize ap=
plications of proxy classes and provide interface guidelines? It could help=
streamline the proposal process and provide a handy reference for this for=
um.<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a1133659cc9d7d204e568d02c--
.