------=_Part_560_22344095.1359413897982
Content-Type: text/plain; charset=ISO-8859-1

Hi Everyone,
I needed to say this in a new thread as the other one was getting too
crowded.

I might get convinced otherwise later (I am such a flip-flop) but at the
> moment I suspect so. Because (as I see it now) mixed relops compare
> "apples" (from the available T range) with "apples + orange". The "orange"
> being NaN-T -- disengaged optional<T>... And the comparison with the
> "orange" is invalid.
>

I get what you are saying. On the other hand, perhaps less-than comparison
is primarily about order, and nothing else. Consider std::string's
operator<, strings "cat" and "dog" are not smaller or greater than one
another. It is just about the ordering. And more, comparison

bool is_less_than_dog(std::string s)
{
  return s < "dog";
}

also works, even though the two types differ, and it is not necessarily
wrong, if you know, it is all about the order. Similarly, you could define
(or is it already defined?) operator< for boost::variant<std::string, int>,
where all strings are ordered before any int. And this is also fine if you
think only about the order. Even in mathematics, the purpose of less-than
comparison is about ordering the magnitudes. (I may be wrong about this
last statement, though. I am not that familiar with mathematics.)

In this context, the concern about comparing apples to oranges sounds more
aesthetic than practical. On the other hand, we haven't seen in this
discussion a practical use case for mixed relops. We have seen examples
where poisoning them would affect the efficiency in cases where they are
needed. But what are the cases? Why did you ever needed to compare
optional<T> to T in the first place?

If this is needed, but rarely, why not provide an explicit function instead:

bool less_than_x(std::optional<int> const& o, const& x)
{
  return o.less(x);
  // or:
  return std::optional_less(x);
}



?

--

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



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

Hi Everyone,<br>I needed to say this in a new thread as the other one was g=
etting too crowded.<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; =
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gma=
il_quote">I might get convinced otherwise later (I am such a flip-flop) but=
 at the moment I suspect so. Because (as I see it now) mixed relops compare=
 "apples" (from the available T range) with "apples + orange". The "orange"=
 being NaN-T -- disengaged optional&lt;T&gt;... And the comparison with the=
 "orange" is invalid. <br></blockquote><div><br>I get what you are saying. =
On the other hand, perhaps less-than comparison is primarily about order, a=
nd nothing else. Consider std::string's operator&lt;, strings "cat" and "do=
g" are not smaller or greater than one another. It is just about the orderi=
ng. And more, comparison <br><br><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> is_less_than_dog</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
string</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> s </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">"dog"</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"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>also works, even though the two types differ, and it is=
 not necessarily wrong, if you know, it is all about the order. Similarly, =
you could define (or is it already defined?) operator&lt; for <span style=
=3D"font-family: courier new,monospace;">boost::variant&lt;std::string, int=
&gt;</span>, where all strings are ordered before any int. And this is also=
 fine if you think only about the order. Even in mathematics, the purpose o=
f less-than comparison is about ordering the magnitudes. (I may be wrong ab=
out this last statement, though. I am not that familiar with mathematics.) =
<br><br>In this context, the concern about comparing apples to oranges soun=
ds more aesthetic than practical. On the other hand, we haven't seen in thi=
s discussion a practical use case for mixed relops. We have seen examples w=
here poisoning them would affect the efficiency in cases where they are nee=
ded. But what are the cases? Why did you ever needed to compare optional&lt=
;T&gt; to T in the first place?<br><br>If this is needed, but rarely, why n=
ot provide an explicit function instead:<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"subprettyprint"><span style=3D"color: =
#008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> less_than_x</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">optional</span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify">&lt;int&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">c=
onst</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> o</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">ret=
urn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> o</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">less</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// or:</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">optional_less</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br><=
br><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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_560_22344095.1359413897982--

.

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

On Tuesday, January 29, 2013 9:58:17 AM UTC+11, Andrzej Krzemie=C5=84ski wr=
ote:
>
> Hi Everyone,
> I needed to say this in a new thread as the other one was getting too=20
> crowded.
>
> I might get convinced otherwise later (I am such a flip-flop) but at the=
=20
>> moment I suspect so. Because (as I see it now) mixed relops compare=20
>> "apples" (from the available T range) with "apples + orange". The "orang=
e"=20
>> being NaN-T -- disengaged optional<T>... And the comparison with the=20
>> "orange" is invalid.=20
>>
>
> I get what you are saying. On the other hand, perhaps less-than compariso=
n=20
> is primarily about order, and nothing else. Consider std::string's=20
> operator<, strings "cat" and "dog" are not smaller or greater than one=20
> another. It is just about the ordering. And more, comparison=20
>
> bool is_less_than_dog(std::string s)
> {
>   return s < "dog";
> }
>
> also works, even though the two types differ, and it is not necessarily=
=20
> wrong, if you know, it is all about the order.=20
>

Hmm, not sure it's a convincing example as here we compare apples to=20
apples. Maybe old apples to new apples but still.
=20

> Similarly, you could define (or is it already defined?) operator< for boo=
st::variant<std::string,=20
> int>, where all strings are ordered before any int.=20
>

It's legit IMO as long as we compare the same (variant in this case) types.
=20

> And this is also fine if you think only about the order. Even in=20
> mathematics, the purpose of less-than comparison is about ordering the=20
> magnitudes. (I may be wrong about this last statement, though. I am not=
=20
> that familiar with mathematics.)=20
>

The problem is that one can only order, compare, compute the same types,=20
like "4 apples + 5 apples", "4 apples < 5 apples", etc. Computations with=
=20
different types are possible with obvious limitations (like char* converted=
=20
to std::string, etc.). The problem (as I see it) with optional<T> is that=
=20
too much like 'T' so naturally attempts are made to treat it as such (lie=
=20
"op < 5").=20
=20

> In this context, the concern about comparing apples to oranges sounds mor=
e=20
> aesthetic than practical.=20
>

I have to disagree. T and optional<T> are conceptually different. The=20
added/new optional's behavior might be subtle and not in-your-face but it's=
=20
there.
=20

> On the other hand, we haven't seen in this discussion a practical use cas=
e=20
> for mixed relops. We have seen examples where poisoning them would affect=
=20
> the efficiency in cases where they are needed. But what are the cases? Wh=
y=20
> did you ever needed to compare optional<T> to T in the first place?
>

As I understood the reason was notational convenience. However, I now feel=
=20
that this convenience comes at the expense of correctness and code=20
ambiguity. Too much a price I am prepared to pay.=20
=20

> If this is needed, but rarely, why not provide an explicit function=20
> instead:
>
> bool less_than_x(std::optional<int> const& o, const& x)
> {
>   return o.less(x);
>   // or:
>   return std::optional_less(x);
> }
>

I do not believe the function is complete as it does not seem to handle the=
=20
disengaged state. To me that disengaged state is pretty much identical to=
=20
NaN (where it's used to indicate no-value) and NaN does not compare for a=
=20
reason -- because it's an "orange". :-)=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/?hl=3Den.



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

On Tuesday, January 29, 2013 9:58:17 AM UTC+11, Andrzej Krzemie=C5=84ski wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">Hi Everyone,<br>I needed t=
o say this in a new thread as the other one was getting too crowded.<br><br=
><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex" class=3D"gmail_quote">I might get convinced ot=
herwise later (I am such a flip-flop) but at the moment I suspect so. Becau=
se (as I see it now) mixed relops compare "apples" (from the available T ra=
nge) with "apples + orange". The "orange" being NaN-T -- disengaged optiona=
l&lt;T&gt;... And the comparison with the "orange" is invalid. <br></blockq=
uote><div><br>I get what you are saying. On the other hand, perhaps less-th=
an comparison is primarily about order, and nothing else. Consider std::str=
ing's operator&lt;, strings "cat" and "dog" are not smaller or greater than=
 one another. It is just about the ordering. And more, comparison <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><spa=
n style=3D"color:#008">bool</span><span style=3D"color:#000"> is_less_than_=
dog</span><span style=3D"color:#660">(</span><span style=3D"color:#000">std=
</span><span style=3D"color:#660">::</span><span style=3D"color:#008">strin=
g</span><span style=3D"color:#000"> s</span><span style=3D"color:#660">)</s=
pan><span style=3D"color:#000"><br></span><span style=3D"color:#660">{</spa=
n><span style=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">r=
eturn</span><span style=3D"color:#000"> s </span><span style=3D"color:#660"=
>&lt;</span><span style=3D"color:#000"> </span><span style=3D"color:#080">"=
dog"</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><b=
r></span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br>=
</span></div></code></div><br>also works, even though the two types differ,=
 and it is not necessarily wrong, if you know, it is all about the order. <=
/div></blockquote><div><br>Hmm, not sure it's a convincing example as here =
we compare apples to apples. Maybe old apples to new apples but still.<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>Similarly, you=
 could define (or is it already defined?) operator&lt; for <span style=3D"f=
ont-family:courier new,monospace">boost::variant&lt;std::string, int&gt;</s=
pan>, where all strings are ordered before any int. </div></blockquote><div=
><br>It's legit IMO as long as we compare the same (variant in this case) t=
ypes.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>And =
this is also fine if you think only about the order. Even in mathematics, t=
he purpose of less-than comparison is about ordering the magnitudes. (I may=
 be wrong about this last statement, though. I am not that familiar with ma=
thematics.) <br></div></blockquote><div><br>The problem is that one can onl=
y order, compare, compute the same types, like "4 apples + 5 apples", "4 ap=
ples &lt; 5 apples", etc. Computations with different types are possible wi=
th obvious limitations (like char* converted to std::string, etc.). The pro=
blem (as I see it) with optional&lt;T&gt; is that too much like 'T' so natu=
rally attempts are made to treat it as such (lie "op &lt; 5"). <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>In this context, the =
concern about comparing apples to oranges sounds more aesthetic than practi=
cal. </div></blockquote><div><br>I have to disagree. T and optional&lt;T&gt=
; are conceptually different. The added/new optional's behavior might be su=
btle and not in-your-face but it's there.<br>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div>On the other hand, we haven't seen in this=
 discussion a practical use case for mixed relops. We have seen examples wh=
ere poisoning them would affect the efficiency in cases where they are need=
ed. But what are the cases? Why did you ever needed to compare optional&lt;=
T&gt; to T in the first place?<br></div></blockquote><div><br>As I understo=
od the reason was notational convenience. However, I now feel that this con=
venience comes at the expense of correctness and code ambiguity. Too much a=
 price I am prepared to pay. <br>&nbsp;</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div>If this is needed, but rarely, why not provide an expli=
cit function instead:<br><br><div style=3D"background-color:rgb(250,250,250=
);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wr=
ap:break-word"><code><div><span style=3D"color:#008">bool</span><span style=
=3D"color:#000"> less_than_x</span><span style=3D"color:#660">(</span><span=
 style=3D"color:#000">std</span><span style=3D"color:#660">::</span><span s=
tyle=3D"color:#000">optional</span><span style=3D"color:#080">&lt;int&gt;</=
span><span style=3D"color:#000"> </span><span style=3D"color:#008">const</s=
pan><span style=3D"color:#660">&amp;</span><span style=3D"color:#000"> o</s=
pan><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><=
span style=3D"color:#008">const</span><span style=3D"color:#660">&amp;</spa=
n><span style=3D"color:#000"> x</span><span style=3D"color:#660">)</span><s=
pan style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><spa=
n style=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">return<=
/span><span style=3D"color:#000"> o</span><span style=3D"color:#660">.</spa=
n><span style=3D"color:#000">less</span><span style=3D"color:#660">(</span>=
<span style=3D"color:#000">x</span><span style=3D"color:#660">);</span><spa=
n style=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#800">// or:<=
/span><span style=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#00=
8">return</span><span style=3D"color:#000"> std</span><span style=3D"color:=
#660">::</span><span style=3D"color:#000">optional_less</span><span style=
=3D"color:#660">(</span><span style=3D"color:#000">x</span><span style=3D"c=
olor:#660">);</span><span style=3D"color:#000"><br></span><span style=3D"co=
lor:#660">}</span><span style=3D"color:#000"><br></span></div></code></div>=
</div></blockquote><br>I do not believe the function is complete as it does=
 not seem to handle the disengaged state. To me that disengaged state is pr=
etty much identical to NaN (where it's used to indicate no-value) and NaN d=
oes not compare for a reason -- because it's an "orange". :-) <br>

<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_208_3597421.1359416117562--

.

On Mon, Jan 28, 2013 at 3:35 PM, Vladimir Batov <vb.mail.247@gmail.com> wro=
te:
> On Tuesday, January 29, 2013 9:58:17 AM UTC+11, Andrzej Krzemie=C5=84ski =
wrote:
>>
>> Hi Everyone,
>> I needed to say this in a new thread as the other one was getting too
>> crowded.
>>
>>> I might get convinced otherwise later (I am such a flip-flop) but at th=
e
>>> moment I suspect so. Because (as I see it now) mixed relops compare "ap=
ples"
>>> (from the available T range) with "apples + orange". The "orange" being
>>> NaN-T -- disengaged optional<T>... And the comparison with the "orange"=
 is
>>> invalid.
>>
>>
>> I get what you are saying. On the other hand, perhaps less-than comparis=
on
>> is primarily about order, and nothing else. Consider std::string's
>> operator<, strings "cat" and "dog" are not smaller or greater than one
>> another. It is just about the ordering. And more, comparison
>>
>> bool is_less_than_dog(std::string s)
>> {
>>   return s < "dog";
>> }
>>
>> also works, even though the two types differ, and it is not necessarily
>> wrong, if you know, it is all about the order.
>
>
> Hmm, not sure it's a convincing example as here we compare apples to appl=
es.
> Maybe old apples to new apples but still.
>
>>
>> Similarly, you could define (or is it already defined?) operator< for
>> boost::variant<std::string, int>, where all strings are ordered before a=
ny
>> int.
>
>
> It's legit IMO as long as we compare the same (variant in this case) type=
s.
>
>>
>> And this is also fine if you think only about the order. Even in
>> mathematics, the purpose of less-than comparison is about ordering the
>> magnitudes. (I may be wrong about this last statement, though. I am not =
that
>> familiar with mathematics.)
>
>
> The problem is that one can only order, compare, compute the same types,
> like "4 apples + 5 apples", "4 apples < 5 apples", etc. Computations with
> different types are possible with obvious limitations (like char* convert=
ed
> to std::string, etc.). The problem (as I see it) with optional<T> is that
> too much like 'T' so naturally attempts are made to treat it as such (lie
> "op < 5").
>
>>
>> In this context, the concern about comparing apples to oranges sounds mo=
re
>> aesthetic than practical.
>
>
> I have to disagree. T and optional<T> are conceptually different. The
> added/new optional's behavior might be subtle and not in-your-face but it=
's
> there.
>
>>
>> On the other hand, we haven't seen in this discussion a practical use ca=
se
>> for mixed relops. We have seen examples where poisoning them would affec=
t
>> the efficiency in cases where they are needed. But what are the cases? W=
hy
>> did you ever needed to compare optional<T> to T in the first place?
>
>
> As I understood the reason was notational convenience. However, I now fee=
l
> that this convenience comes at the expense of correctness and code
> ambiguity. Too much a price I am prepared to pay.
>
>>
>> If this is needed, but rarely, why not provide an explicit function
>> instead:
>>
>> bool less_than_x(std::optional<int> const& o, const& x)
>> {
>>   return o.less(x);
>>   // or:
>>   return std::optional_less(x);
>> }
>
>
> I do not believe the function is complete as it does not seem to handle t=
he
> disengaged state. To me that disengaged state is pretty much identical to
> NaN (where it's used to indicate no-value) and NaN does not compare for a
> reason -- because it's an "orange". :-)
>

2=C2=A2: NaN is just a bad design for programmers. Maybe it's good for
numerical analysts, but I've seen way too many programmers write bugs
because of how NaN behaves (yay for undefined sort() behavior). If
there's a way to make nullopt behave like NaN, we should do the
opposite.

Jeffrey

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

On 29 January 2013 01:35, Vladimir Batov <vb.mail.247@gmail.com> wrote:
>> If this is needed, but rarely, why not provide an explicit function
>> instead:
>> bool less_than_x(std::optional<int> const& o, const& x)
>> {
>>   return o.less(x);
>>   // or:
>>   return std::optional_less(x);
>> }
> I do not believe the function is complete as it does not seem to handle the
> disengaged state. To me that disengaged state is pretty much identical to
> NaN (where it's used to indicate no-value) and NaN does not compare for a
> reason -- because it's an "orange". :-)

But it does handle disengaged state. o.less(x) is true if o is disengaged.
Whether you like/deem-correct that way of handling disengaged state is
the whole issue in
this discussion.

How do these oranges become apples just by constructing an optional out of them,
but can't be compared to apples otherwise?

--

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



.

On Tue, Jan 29, 2013 at 10:39 AM, Jeffrey Yasskin <jyasskin@googlers.com> w=
rote:
> On Mon, Jan 28, 2013 at 3:35 PM, Vladimir Batov <vb.mail.247@gmail.com> w=
rote:
>> On Tuesday, January 29, 2013 9:58:17 AM UTC+11, Andrzej Krzemie=C5=84ski=
 wrote:
> ...
> 2=C2=A2: NaN is just a bad design for programmers. Maybe it's good for
> numerical analysts, but I've seen way too many programmers write bugs
> because of how NaN behaves (yay for undefined sort() behavior). If
> there's a way to make nullopt behave like NaN, we should do the
> opposite.

When referring to NaN I mean the NaN concept not its implementation.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

On Mon, Jan 28, 2013 at 3:54 PM, Vladimir Batov <vb.mail.247@gmail.com> wro=
te:
> On Tue, Jan 29, 2013 at 10:39 AM, Jeffrey Yasskin <jyasskin@googlers.com>=
 wrote:
>> On Mon, Jan 28, 2013 at 3:35 PM, Vladimir Batov <vb.mail.247@gmail.com> =
wrote:
>>> On Tuesday, January 29, 2013 9:58:17 AM UTC+11, Andrzej Krzemie=C5=84sk=
i wrote:
>> ...
>> 2=C2=A2: NaN is just a bad design for programmers. Maybe it's good for
>> numerical analysts, but I've seen way too many programmers write bugs
>> because of how NaN behaves (yay for undefined sort() behavior). If
>> there's a way to make nullopt behave like NaN, we should do the
>> opposite.
>
> When referring to NaN I mean the NaN concept not its implementation.

If you mean some other NaN than the one defined by IEEE 754, then
you'll need to be more precise for me to understand you. And at that
point, you may as well just write the behavior you want rather than
relying on an analogy.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

On Tue, Jan 29, 2013 at 10:44 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 29 January 2013 01:35, Vladimir Batov <vb.mail.247@gmail.com> wrote:
>>> If this is needed, but rarely, why not provide an explicit function
>>> instead:
>>> bool less_than_x(std::optional<int> const& o, const& x)
>>> {
>>>   return o.less(x);
>>>   // or:
>>>   return std::optional_less(x);
>>> }
>> I do not believe the function is complete as it does not seem to handle the
>> disengaged state. To me that disengaged state is pretty much identical to
>> NaN (where it's used to indicate no-value) and NaN does not compare for a
>> reason -- because it's an "orange". :-)
>
> But it does handle disengaged state. o.less(x) is true if o is disengaged.
> Whether you like/deem-correct that way of handling disengaged state is
> the whole issue in this discussion.

Indeed, it does... iff "no-value < any-value" and in all honesty it
feels quite natural to me. However, from the computational angle it
does not seem kosher as there is nothing to compare against. Still, we
can mandate that behavior *inside* an extended class where no-value is
part of the type, i.e. no-value, value1, value2, etc. and that's
'optional' not 'int'. IMO of course.

> How do these oranges become apples just by constructing an optional out of them,
> but can't be compared to apples otherwise?

T and optional<T> are different classes. Not just implementation-wise
(like char* and std::string) but conceptually as well. Conceptually,
char* and std::string are the same. Namely, one can get char* from
std::string and vice versa. It's not the same with T and optional<T>
-- no-value is the little extra that 'int' does not handle/understand.
Consequently, when I look at "opt < 5", I am thinking "is 5 upgraded
to optional or opt is downgraded to int?". It is certainly the former
-- 5->optional -- as optional->int cannot be safely done. However, I
find that really subtle and quite a few people will probably interpret
"opt < 5" the other way around, consequently, missing no-value
handling. Say, "opt && *opt < 5" spells it out plain and simple to me.

So, if it's somehow made lucidly clear that "opt < 5" applies
5->optional upgrade (not physically with, say, implicit constructor
but conceptually), then I guess I've sleep much better at night. :-)

--

---
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/?hl=en.



.

On Mon, Jan 28, 2013 at 6:39 PM, Jeffrey Yasskin <jyasskin@googlers.com> wr=
ote:
> On Mon, Jan 28, 2013 at 3:35 PM, Vladimir Batov <vb.mail.247@gmail.com> w=
rote:
>>
>> I do not believe the function is complete as it does not seem to handle =
the
>> disengaged state. To me that disengaged state is pretty much identical t=
o
>> NaN (where it's used to indicate no-value) and NaN does not compare for =
a
>> reason -- because it's an "orange". :-)
>>
>
> 2=A2: NaN is just a bad design for programmers. Maybe it's good for
> numerical analysts, but I've seen way too many programmers write bugs
> because of how NaN behaves (yay for undefined sort() behavior). If
> there's a way to make nullopt behave like NaN, we should do the
> opposite.
>
> Jeffrey
>

We (if we so choose) could have some of NaN's "philosophy" without the
arguably bad parts:

NaN says they are not comparable, thus return false.
We could say they are not comparable, thus don't compile.

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/?hl=3Den.



.

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



W dniu wtorek, 29 stycznia 2013 00:58:51 UTC+1 u=C5=BCytkownik Jeffrey Yass=
kin=20
napisa=C5=82:
>
> On Mon, Jan 28, 2013 at 3:54 PM, Vladimir Batov <vb.ma...@gmail.com<javas=
cript:>>=20
> wrote:=20
> > On Tue, Jan 29, 2013 at 10:39 AM, Jeffrey Yasskin <jyas...@googlers.com=
<javascript:>>=20
> wrote:=20
> >> On Mon, Jan 28, 2013 at 3:35 PM, Vladimir Batov <vb.ma...@gmail.com<ja=
vascript:>>=20
> wrote:=20
> >>> On Tuesday, January 29, 2013 9:58:17 AM UTC+11, Andrzej Krzemie=C5=84=
ski=20
> wrote:=20
> >> ...=20
> >> 2=C2=A2: NaN is just a bad design for programmers. Maybe it's good for=
=20
> >> numerical analysts, but I've seen way too many programmers write bugs=
=20
> >> because of how NaN behaves (yay for undefined sort() behavior). If=20
> >> there's a way to make nullopt behave like NaN, we should do the=20
> >> opposite.=20
> >=20
> > When referring to NaN I mean the NaN concept not its implementation.=20
>
> If you mean some other NaN than the one defined by IEEE 754, then=20
> you'll need to be more precise for me to understand you. And at that=20
> point, you may as well just write the behavior you want rather than=20
> relying on an analogy.=20
>

I agree wit Jeffrey here. I was also under the impression that you are=20
talking about IEEE 754 NaN's. And these NAN's do compare with floats, and=
=20
the results are, well, surprising. To me it always looked like NaN is a=20
child that took umbrage at the user and just replies "no" to any request.

In "some" sense optional's null-state is like a NaN, but if you do not=20
agree with the "least of all Ts" behavior, what behavior do you have in=20
mind? "NaN" (in a more abstract sense" is just another value of its=20
underlying type. It is a special value among normal values, so comparison=
=20
cannot compile fore any value of T except one.

--=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/?hl=3Den.



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

<br><br>W dniu wtorek, 29 stycznia 2013 00:58:51 UTC+1 u=C5=BCytkownik Jeff=
rey Yasskin napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Mo=
n, Jan 28, 2013 at 3:54 PM, Vladimir Batov &lt;<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"CAkWOkBeZYoJ">vb.ma...@gmail.com</a>=
&gt; wrote:
<br>&gt; On Tue, Jan 29, 2013 at 10:39 AM, Jeffrey Yasskin &lt;<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"CAkWOkBeZYoJ">jyas..=
..@googlers.com</a>&gt; wrote:
<br>&gt;&gt; On Mon, Jan 28, 2013 at 3:35 PM, Vladimir Batov &lt;<a href=3D=
"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"CAkWOkBeZYoJ">vb.m=
a...@gmail.com</a>&gt; wrote:
<br>&gt;&gt;&gt; On Tuesday, January 29, 2013 9:58:17 AM UTC+11, Andrzej Kr=
zemie=C5=84ski wrote:
<br>&gt;&gt; ...
<br>&gt;&gt; 2=C2=A2: NaN is just a bad design for programmers. Maybe it's =
good for
<br>&gt;&gt; numerical analysts, but I've seen way too many programmers wri=
te bugs
<br>&gt;&gt; because of how NaN behaves (yay for undefined sort() behavior)=
.. If
<br>&gt;&gt; there's a way to make nullopt behave like NaN, we should do th=
e
<br>&gt;&gt; opposite.
<br>&gt;
<br>&gt; When referring to NaN I mean the NaN concept not its implementatio=
n.
<br>
<br>If you mean some other NaN than the one defined by IEEE 754, then
<br>you'll need to be more precise for me to understand you. And at that
<br>point, you may as well just write the behavior you want rather than
<br>relying on an analogy.
<br></blockquote><div><br>I agree wit Jeffrey here. I was also under the im=
pression that you are talking about IEEE 754 NaN's. And these NAN's do comp=
are with floats, and the results are, well, surprising. To me it always loo=
ked like NaN is a child that took umbrage at the user and just replies "no"=
 to any request.<br><br>In "some" sense optional's null-state is like a NaN=
, but if you do not agree with the "least of all Ts" behavior, what behavio=
r do you have in mind? "NaN" (in a more abstract sense" is just another val=
ue of its underlying type. It is a special value among normal values, so co=
mparison cannot compile fore any value of T except one.<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1729_4871213.1359448705703--

.

------=_Part_1737_28753171.1359449328542
Content-Type: text/plain; charset=ISO-8859-1


>
> On the other hand, we haven't seen in this discussion a practical use case
>> for mixed relops. We have seen examples where poisoning them would affect
>> the efficiency in cases where they are needed. But what are the cases? Why
>> did you ever needed to compare optional<T> to T in the first place?
>>
>
> As I understood the reason was notational convenience. However, I now feel
> that this convenience comes at the expense of correctness and code
> ambiguity. Too much a price I am prepared to pay.
>
>
>> If this is needed, but rarely, why not provide an explicit function
>> instead:
>>
>> bool less_than_x(std::optional<int> const& o, const& x)
>> {
>>   return o.less(x);
>>   // or:
>>   return std::optional_less(x);
>> }
>>
>
> I do not believe the function is complete as it does not seem to handle
> the disengaged state. To me that disengaged state is pretty much identical
> to NaN (where it's used to indicate no-value) and NaN does not compare for
> a reason -- because it's an "orange". :-)
>

Perhaps my example was too short. I am considering the following solution.
We poison mixed relops but offer the following function in exchange:

template <typename T>
bool std::optional_less( std::optional<T> const& o, T const& v )
// nullopt < any T
{
  return !o ? true : *o < v;
}

This way, we do not have the confusing mixed relops, and the people who --
for efficiency reasons -- need to compare optional<T> with T have a tool to
do that efficiently. The syntax is more verbose, but:

   1. It is a fair trade-off to have a verbose syntax for rare use cases
   2. It is a good practice to have long names for potentially dangerous
   operations


> In this context, the concern about comparing apples to oranges sounds more
>> aesthetic than practical.
>>
>
> I have to disagree. T and optional<T> are conceptually different. The
> added/new optional's behavior might be subtle and not in-your-face but it's
> there.


I think we are stuck with this "branch" of the discussion at this point.
Neither I or you (am I right?) ever needed to use mixed relops in practice.
I hoped that the advocates of the feature (Fernando or Daniel) would give
us an example of a use case, and assess if the optional_less alternative
would work for them.

--

---
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/?hl=en.



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

&nbsp;<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div>On the other hand, we haven't seen in this discussion =
a practical use case for mixed relops. We have seen examples where poisonin=
g them would affect the efficiency in cases where they are needed. But what=
 are the cases? Why did you ever needed to compare optional&lt;T&gt; to T i=
n the first place?<br></div></blockquote><div><br>As I understood the reaso=
n was notational convenience. However, I now feel that this convenience com=
es at the expense of correctness and code ambiguity. Too much a price I am =
prepared to pay. <br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv>If this is needed, but rarely, why not provide an explicit function inst=
ead:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rg=
b(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><c=
ode><div><span style=3D"color:#008">bool</span><span style=3D"color:#000"> =
less_than_x</span><span style=3D"color:#660">(</span><span style=3D"color:#=
000">std</span><span style=3D"color:#660">::</span><span style=3D"color:#00=
0">optional</span><span style=3D"color:#080">&lt;int&gt;</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">const</span><span style=
=3D"color:#660">&amp;</span><span style=3D"color:#000"> o</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">const</span><span style=3D"color:#660">&amp;</span><span style=
=3D"color:#000"> x</span><span style=3D"color:#660">)</span><span style=3D"=
color:#000"><br></span><span style=3D"color:#660">{</span><span style=3D"co=
lor:#000"><br>&nbsp; </span><span style=3D"color:#008">return</span><span s=
tyle=3D"color:#000"> o</span><span style=3D"color:#660">.</span><span style=
=3D"color:#000">less</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">x</span><span style=3D"color:#660">);</span><span style=3D"=
color:#000"><br>&nbsp; </span><span style=3D"color:#800">// or:</span><span=
 style=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">return</=
span><span style=3D"color:#000"> std</span><span style=3D"color:#660">::</s=
pan><span style=3D"color:#000">optional_less</span><span style=3D"color:#66=
0">(</span><span style=3D"color:#000">x</span><span style=3D"color:#660">);=
</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</=
span><span style=3D"color:#000"><br></span></div></code></div></div></block=
quote><br>I do not believe the function is complete as it does not seem to =
handle the disengaged state. To me that disengaged state is pretty much ide=
ntical to NaN (where it's used to indicate no-value) and NaN does not compa=
re for a reason -- because it's an "orange". :-) <br></blockquote><div><br>=
Perhaps my example was too short. I am considering the following solution. =
We poison mixed relops but offer the following function in exchange:<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; w=
ord-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><span style=3D"color: #008;" class=3D"styled-by-prettify">template</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">optional_less</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">optional</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">const</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> o</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> T </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
const</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #800;" class=3D"styled-by-prettify">// nullopt &lt; any T</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">!</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">o </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">?</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">true</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">o </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> v</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> <br></span></div></c=
ode></div><br>This way, we do not have the confusing mixed relops, and the =
people who -- for efficiency reasons -- need to compare optional&lt;T&gt; w=
ith T have a tool to do that efficiently. The syntax is more verbose, but:<=
br><ol><li>It is a fair trade-off to have a verbose syntax for rare use cas=
es</li><li>It is a good practice to have long names for potentially dangero=
us operations</li></ol><blockquote style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_q=
uote"><br><div class=3D"GAK2G4EDL5"><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div>In this context, the concern about comparing apples to oranges sounds=
 more aesthetic than practical. </div></blockquote></div><br>I
 have to disagree. T and optional&lt;T&gt; are conceptually different.=20
The added/new optional's behavior might be subtle and not in-your-face=20
but it's there.</blockquote><div><br>I think we are stuck with this "branch=
" of the discussion at this point. Neither I or you (am I right?) ever need=
ed to use mixed relops in practice. I hoped that the advocates of the featu=
re (Fernando or Daniel) would give us an example of a use case, and assess =
if the <span style=3D"font-family: courier new,monospace;">optional_less</s=
pan> alternative would work for them. <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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1737_28753171.1359449328542--

.

On Tue, Jan 29, 2013 at 9:48 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
> Perhaps my example was too short. I am considering the following solution=
..
> We poison mixed relops but offer the following function in exchange:
>
> template <typename T>
> bool std::optional_less( std::optional<T> const& o, T const& v )
> // nullopt < any T
> {
>   return !o ? true : *o < v;
> }
>
> This way, we do not have the confusing mixed relops, and the people who -=
-
> for efficiency reasons -- need to compare optional<T> with T have a tool =
to
> do that efficiently. The syntax is more verbose, but:
>
> It is a fair trade-off to have a verbose syntax for rare use cases
> It is a good practice to have long names for potentially dangerous
> operations

I think if you go this way and add a free function, you may directly
extend it to support both possible scenarios as I proposed in the
other thread:

template <typename T>
bool std::less_or( std::optional<T> const& o, T const& v, bool or_result )
// nullopt < any T
{
   return o ? *o < v : or_result ;
}

Even if we end up with mixed rel ops in the standard, I think that
this will be useful since it lets you get both possible outcomes with
no lost of performance and with clear code.

if( less_or(o,v, false) ) { // Skip branch enter if o is nullopt
  ...
}

if( less_or(o,v, true) ) { // Enter branch if o is nullopt ( same as o < v =
)
  ...
}

Best regards
Matias

--=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/?hl=3Den.



.

------=_Part_48_5086167.1359450920136
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu wtorek, 29 stycznia 2013 10:07:18 UTC+1 u=BFytkownik Matias Capelett=
o=20
napisa=B3:
>
> On Tue, Jan 29, 2013 at 9:48 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:=20
> > Perhaps my example was too short. I am considering the following=20
> solution.=20
> > We poison mixed relops but offer the following function in exchange:=20
> >=20
> > template <typename T>=20
> > bool std::optional_less( std::optional<T> const& o, T const& v )=20
> > // nullopt < any T=20
> > {=20
> >   return !o ? true : *o < v;=20
> > }=20
> >=20
> > This way, we do not have the confusing mixed relops, and the people who=
=20
> --=20
> > for efficiency reasons -- need to compare optional<T> with T have a too=
l=20
> to=20
> > do that efficiently. The syntax is more verbose, but:=20
> >=20
> > It is a fair trade-off to have a verbose syntax for rare use cases=20
> > It is a good practice to have long names for potentially dangerous=20
> > operations=20
>
> I think if you go this way and add a free function, you may directly=20
> extend it to support both possible scenarios as I proposed in the=20
> other thread:=20
>
> template <typename T>=20
> bool std::less_or( std::optional<T> const& o, T const& v, bool or_result =
)=20
> // nullopt < any T=20
> {=20
>    return o ? *o < v : or_result ;=20
> }=20
>
> Even if we end up with mixed rel ops in the standard, I think that=20
> this will be useful since it lets you get both possible outcomes with=20
> no lost of performance and with clear code.=20
>
> if( less_or(o,v, false) ) { // Skip branch enter if o is nullopt=20
>   ...=20
> }=20
>
> if( less_or(o,v, true) ) { // Enter branch if o is nullopt ( same as o < =
v=20
> )=20
>   ...=20
> }=20
>

Yes, you did propose this already. I guess I needed this discussion to=20
appreciate your solution. I am just not sure if having three arguments=20
would not affect the performance compared to:

template <typename T>
bool std::less_with_nullopt( std::optional<T> const& o, T const& v )
// nullopt < any T
{
  return !o ? true : *o < v;
}=20

Or (a bit more verbose):

template <typename T>
bool std::less_with_nullopt_least( std::optional<T> const& o, T const& v )
// nullopt < any T
{
  return !o ? true : *o < v;
}=20

template <typename T>
bool std::less_with_nullopt_greatest( std::optional<T> const& o, T const& v=
=20
)
// nullopt < any T
{
  return !o ? false : *o < v;
}=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/?hl=3Den.



------=_Part_48_5086167.1359450920136
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu wtorek, 29 stycznia 2013 10:07:18 UTC+1 u=BFytkownik Matias =
Capeletto napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Ja=
n 29, 2013 at 9:48 AM, Andrzej Krzemie=F1ski &lt;<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"1LountyGHfYJ">akrz...@gmail.com</a=
>&gt; wrote:
<br>&gt; Perhaps my example was too short. I am considering the following s=
olution.
<br>&gt; We poison mixed relops but offer the following function in exchang=
e:
<br>&gt;
<br>&gt; template &lt;typename T&gt;
<br>&gt; bool std::optional_less( std::optional&lt;T&gt; const&amp; o, T co=
nst&amp; v )
<br>&gt; // nullopt &lt; any T
<br>&gt; {
<br>&gt; &nbsp; return !o ? true : *o &lt; v;
<br>&gt; }
<br>&gt;
<br>&gt; This way, we do not have the confusing mixed relops, and the peopl=
e who --
<br>&gt; for efficiency reasons -- need to compare optional&lt;T&gt; with T=
 have a tool to
<br>&gt; do that efficiently. The syntax is more verbose, but:
<br>&gt;
<br>&gt; It is a fair trade-off to have a verbose syntax for rare use cases
<br>&gt; It is a good practice to have long names for potentially dangerous
<br>&gt; operations
<br>
<br>I think if you go this way and add a free function, you may directly
<br>extend it to support both possible scenarios as I proposed in the
<br>other thread:
<br>
<br>template &lt;typename T&gt;
<br>bool std::less_or( std::optional&lt;T&gt; const&amp; o, T const&amp; v,=
 bool or_result )
<br>// nullopt &lt; any T
<br>{
<br>&nbsp; &nbsp;return o ? *o &lt; v : or_result ;
<br>}
<br>
<br>Even if we end up with mixed rel ops in the standard, I think that
<br>this will be useful since it lets you get both possible outcomes with
<br>no lost of performance and with clear code.
<br>
<br>if( less_or(o,v, false) ) { // Skip branch enter if o is nullopt
<br>&nbsp; ...
<br>}
<br>
<br>if( less_or(o,v, true) ) { // Enter branch if o is nullopt ( same as o =
&lt; v )
<br>&nbsp; ...
<br>}
<br></blockquote><div><br>Yes, you did propose this already. I guess I need=
ed this discussion to appreciate your solution. I am just not sure if havin=
g three arguments would not affect the performance compared to:<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">template</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
less_with_nullopt</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">optional</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">const</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> o</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> T </span><span style=3D"color: #008;" class=3D"styled-by-prettify">const=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> v </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">// nullopt &lt; any T</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>&nbsp; </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: #000;" class=3D"style=
d-by-prettify">o </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">?</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">true</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">o </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> v</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> <br></span></div></co=
de></div><br>Or (a bit more verbose):<br><br><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">template</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">bool=
</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 s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">less_with_nullopt_least<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">optional</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">const</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
o</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> T </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> v </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"=
styled-by-prettify">// nullopt &lt; any T</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">return</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: #000;" class=3D"styled-by-prettify">o </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">?</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">true</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">o </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> <br><br></span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">template</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">less_with_nullopt_greatest</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">optional</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">const</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
o</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> T </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> v </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"=
styled-by-prettify">// nullopt &lt; any T</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">return</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: #000;" class=3D"styled-by-prettify">o </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">?</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">false</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">o </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br><br><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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_48_5086167.1359450920136--

.

On Tue, Jan 29, 2013 at 10:15 AM, Andrzej Krzemie=F1ski
<akrzemi1@gmail.com> wrote:
> W dniu wtorek, 29 stycznia 2013 10:07:18 UTC+1 u=BFytkownik Matias Capele=
tto
>> I think if you go this way and add a free function, you may directly
>> extend it to support both possible scenarios as I proposed in the
>> other thread:
>>
>> template <typename T>
>> bool std::less_or( std::optional<T> const& o, T const& v, bool or_result=
 )
>> // nullopt < any T
>> {
>>    return o ? *o < v : or_result ;
>> }
>>
>> Even if we end up with mixed rel ops in the standard, I think that
>> this will be useful since it lets you get both possible outcomes with
>> no lost of performance and with clear code.
>
> Yes, you did propose this already. I guess I needed this discussion to
> appreciate your solution. I am just not sure if having three arguments wo=
uld
> not affect the performance compared to:
>
> template <typename T>
> bool std::less_with_nullopt( std::optional<T> const& o, T const& v )
>
> // nullopt < any T
> {
>   return !o ? true : *o < v;
> }

The less_or function should be inlined by the compiler so I do not see
that you will get any performance hit at all.

--=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/?hl=3Den.



.

------=_Part_189_24424368.1359452366379
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu wtorek, 29 stycznia 2013 10:07:18 UTC+1 u=BFytkownik Matias Capelett=
o=20
napisa=B3:
>
> On Tue, Jan 29, 2013 at 9:48 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:=20
> > Perhaps my example was too short. I am considering the following=20
> solution.=20
> > We poison mixed relops but offer the following function in exchange:=20
> >=20
> > template <typename T>=20
> > bool std::optional_less( std::optional<T> const& o, T const& v )=20
> > // nullopt < any T=20
> > {=20
> >   return !o ? true : *o < v;=20
> > }=20
> >=20
> > This way, we do not have the confusing mixed relops, and the people who=
=20
> --=20
> > for efficiency reasons -- need to compare optional<T> with T have a too=
l=20
> to=20
> > do that efficiently. The syntax is more verbose, but:=20
> >=20
> > It is a fair trade-off to have a verbose syntax for rare use cases=20
> > It is a good practice to have long names for potentially dangerous=20
> > operations=20
>
> I think if you go this way and add a free function, you may directly=20
> extend it to support both possible scenarios as I proposed in the=20
> other thread:=20
>
> template <typename T>=20
> bool std::less_or( std::optional<T> const& o, T const& v, bool or_result =
)=20
> // nullopt < any T=20
> {=20
>    return o ? *o < v : or_result ;=20
> }=20
>
> Even if we end up with mixed rel ops in the standard, I think that=20
> this will be useful since it lets you get both possible outcomes with=20
> no lost of performance and with clear code.=20
>
> if( less_or(o,v, false) ) { // Skip branch enter if o is nullopt=20
>   ...=20
> }=20
>
> if( less_or(o,v, true) ) { // Enter branch if o is nullopt ( same as o < =
v=20
> )=20
>   ...=20
> }=20
>

And just one other concern -- regarding the signature of the function. From=
:
less_or(o, v, true)

It is not immediately clear whether we want to consider nullopt as the=20
least of all Ts or the greatest of all Ts. For some it may be important.=20
For others, on the other hand, explicit true or false may be more desired.
=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/?hl=3Den.



------=_Part_189_24424368.1359452366379
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu wtorek, 29 stycznia 2013 10:07:18 UTC+1 u=BFytkownik Matias =
Capeletto napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Ja=
n 29, 2013 at 9:48 AM, Andrzej Krzemie=F1ski &lt;<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"1LountyGHfYJ">akrz...@gmail.com</a=
>&gt; wrote:
<br>&gt; Perhaps my example was too short. I am considering the following s=
olution.
<br>&gt; We poison mixed relops but offer the following function in exchang=
e:
<br>&gt;
<br>&gt; template &lt;typename T&gt;
<br>&gt; bool std::optional_less( std::optional&lt;T&gt; const&amp; o, T co=
nst&amp; v )
<br>&gt; // nullopt &lt; any T
<br>&gt; {
<br>&gt; &nbsp; return !o ? true : *o &lt; v;
<br>&gt; }
<br>&gt;
<br>&gt; This way, we do not have the confusing mixed relops, and the peopl=
e who --
<br>&gt; for efficiency reasons -- need to compare optional&lt;T&gt; with T=
 have a tool to
<br>&gt; do that efficiently. The syntax is more verbose, but:
<br>&gt;
<br>&gt; It is a fair trade-off to have a verbose syntax for rare use cases
<br>&gt; It is a good practice to have long names for potentially dangerous
<br>&gt; operations
<br>
<br>I think if you go this way and add a free function, you may directly
<br>extend it to support both possible scenarios as I proposed in the
<br>other thread:
<br>
<br>template &lt;typename T&gt;
<br>bool std::less_or( std::optional&lt;T&gt; const&amp; o, T const&amp; v,=
 bool or_result )
<br>// nullopt &lt; any T
<br>{
<br>&nbsp; &nbsp;return o ? *o &lt; v : or_result ;
<br>}
<br>
<br>Even if we end up with mixed rel ops in the standard, I think that
<br>this will be useful since it lets you get both possible outcomes with
<br>no lost of performance and with clear code.
<br>
<br>if( less_or(o,v, false) ) { // Skip branch enter if o is nullopt
<br>&nbsp; ...
<br>}
<br>
<br>if( less_or(o,v, true) ) { // Enter branch if o is nullopt ( same as o =
&lt; v )
<br>&nbsp; ...
<br>}
<br></blockquote><div><br>And just one other concern -- regarding the signa=
ture of the function. From:<br><div class=3D"prettyprint" style=3D"backgrou=
nd-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-styl=
e: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">less_or</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">o</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">true</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>It is not immedia=
tely clear whether we want to consider nullopt as the least of all Ts or th=
e greatest of all Ts. For some it may be important. For others, on the othe=
r hand, explicit true or false may be more desired.<br>&nbsp;<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_189_24424368.1359452366379--

.

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



W dniu wtorek, 29 stycznia 2013 05:46:05 UTC+1 u=C5=BCytkownik Tony V E nap=
isa=C5=82:
>
> On Mon, Jan 28, 2013 at 6:39 PM, Jeffrey Yasskin <jyas...@googlers.com<ja=
vascript:>>=20
> wrote:=20
> > On Mon, Jan 28, 2013 at 3:35 PM, Vladimir Batov <vb.ma...@gmail.com<jav=
ascript:>>=20
> wrote:=20
> >>=20
> >> I do not believe the function is complete as it does not seem to handl=
e=20
> the=20
> >> disengaged state. To me that disengaged state is pretty much identical=
=20
> to=20
> >> NaN (where it's used to indicate no-value) and NaN does not compare fo=
r=20
> a=20
> >> reason -- because it's an "orange". :-)=20
> >>=20
> >=20
> > 2=C2=A2: NaN is just a bad design for programmers. Maybe it's good for=
=20
> > numerical analysts, but I've seen way too many programmers write bugs=
=20
> > because of how NaN behaves (yay for undefined sort() behavior). If=20
> > there's a way to make nullopt behave like NaN, we should do the=20
> > opposite.=20
> >=20
> > Jeffrey=20
> >=20
>
> We (if we so choose) could have some of NaN's "philosophy" without the=20
> arguably bad parts:=20
>
> NaN says they are not comparable, thus return false.=20
> We could say they are not comparable, thus don't compile.=20
>

Ok, now I start to understand where you and Vladimir are getting to:

optional<int> computation(); // where the result may be non-existent

auto result =3D computation();

if (result < 17) {} // error: did you consider nullopt?

if (less_with_nullopt(result, 17)) {} // ok: you know what you are doing

if (*result < 17) {} // ok, although risky.

Did i get it right?

--=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/?hl=3Den.



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

<br><br>W dniu wtorek, 29 stycznia 2013 05:46:05 UTC+1 u=C5=BCytkownik Tony=
 V E napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Jan =
28, 2013 at 6:39 PM, Jeffrey Yasskin &lt;<a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"EoG0tF6xZWUJ">jyas...@googlers.com</a>&gt;=
 wrote:
<br>&gt; On Mon, Jan 28, 2013 at 3:35 PM, Vladimir Batov &lt;<a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"EoG0tF6xZWUJ">vb.ma...=
@gmail.com</a>&gt; wrote:
<br>&gt;&gt;
<br>&gt;&gt; I do not believe the function is complete as it does not seem =
to handle the
<br>&gt;&gt; disengaged state. To me that disengaged state is pretty much i=
dentical to
<br>&gt;&gt; NaN (where it's used to indicate no-value) and NaN does not co=
mpare for a
<br>&gt;&gt; reason -- because it's an "orange". :-)
<br>&gt;&gt;
<br>&gt;
<br>&gt; 2=C2=A2: NaN is just a bad design for programmers. Maybe it's good=
 for
<br>&gt; numerical analysts, but I've seen way too many programmers write b=
ugs
<br>&gt; because of how NaN behaves (yay for undefined sort() behavior). If
<br>&gt; there's a way to make nullopt behave like NaN, we should do the
<br>&gt; opposite.
<br>&gt;
<br>&gt; Jeffrey
<br>&gt;
<br>
<br>We (if we so choose) could have some of NaN's "philosophy" without the
<br>arguably bad parts:
<br>
<br>NaN says they are not comparable, thus return false.
<br>We could say they are not comparable, thus don't compile.
<br></blockquote><div><br>Ok, now I start to understand where you and Vladi=
mir are getting to:<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"><d=
iv class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>optional</span><span style=3D"color: #080;" class=3D"styled-=
by-prettify">&lt;int&gt;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> computation</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">=
// where the result may be non-existent</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> result </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> computation</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">if</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">result </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">17</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-pretti=
fy"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// er=
ror: did you consider nullopt?</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">if</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">less_wit=
h_nullopt</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">result</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #066;" class=3D"styled-by-prettify">17</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">))</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{}</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>// ok: you know what you are doing</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">if</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">r=
esult </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #066;" class=3D"styled-by-prettify">17</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">{}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">// ok, although risky.</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span></div></code></div><br>Did i get it r=
ight?<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1788_13730416.1359452653288--

.

On Tue, Jan 29, 2013 at 10:39 AM, Andrzej Krzemie=C5=84ski
<akrzemi1@gmail.com> wrote:
> And just one other concern -- regarding the signature of the function. Fr=
om:
> less_or(o, v, true)
>
> It is not immediately clear whether we want to consider nullopt as the le=
ast
> of all Ts or the greatest of all Ts. For some it may be important. For
> others, on the other hand, explicit true or false may be more desired.

I do not if I understand your concern. When you will use less_or, you
will be forced to choose the outcome in the case of a nullopt.
I thought about making the or_result default to true but it looks very stra=
nge:

  if( less_or(o,v) ) { ... } // ?

And actually this has the same problems about clarity in case of
nullopt as the mixed rel ops o<v.

I do not think that is that much typing to write what is your desired
result in case of nullopt (skip or enter branch) when using the
function, and I like the idea of being forced to choose the correct
outcome.

Again, I am not particulary against having mixed relops, but in my
production code I will create all the { less_or, greater_or, etc }
functions so I know exactly what is going on and I let a direct
documentation about how nullopts should be treated for others that
will review it later.

Best regards
Matias

--=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/?hl=3Den.



.

------=_Part_478_8380504.1359453847988
Content-Type: text/plain; charset=ISO-8859-1



> I do not if I understand your concern.


Let me explain (I reorderd your reply a bit)

I do not think that is that much typing to write what is your desired
> result in case of nullopt (skip or enter branch) when using the
> function, and I like the idea of being forced to choose the correct
> outcome.
>
> Again, I am not particulary against having mixed relops, but in my
> production code I will create all the { less_or, greater_or, etc }
> functions so I know exactly what is going on and I let a direct
> documentation about how nullopts should be treated for others that
> will review it later.
>

I believe that here we are on the same side. I am now considering poisoning
the mixed  relops and providing an alternative, where you are very explicit
what you want to do.

When you will use less_or, you
> will be forced to choose the outcome in the case of a nullopt.
> I thought about making the or_result default to true but it looks very
> strange:
>
>   if( less_or(o,v) ) { ... } // ?
>
> And actually this has the same problems about clarity in case of
> nullopt as the mixed rel ops o<v.
>

My "problem: is somewhat different. There are two ways of being very
explicit.

// Version 1:
return less_or(o, v, true);
return less_or(o, v, false);

// Version 2:
return less_with_nullopt_least(o, v);
return less_with_nullopt_greatest(o, v);

They are equally "explicit", but there is a significant difference. In
Version 1, I am clear what Boolean value to return in case I have a
nullopt, but it is less clear what mathematical ordering it implies. In
Version 2, the ordering is very explicit, but it is less clear what Boolean
value we will get. This has the potential risk that I intend semantics
"least of all Ts" but I incorrectly type "false" as the third argument. In
other words, I anticipate bugs in boolean expressions. This is similar to
mistyping:

!cond1 && cond2
instead of
!cond1 || cond2

--

---
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/?hl=en.



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

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">I do not if I understand y=
our concern. </blockquote><div><br>Let me explain (I reorderd your reply a =
bit) <br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1=
px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">I do=
 not think that is that much typing to write what is your desired
<br>result in case of nullopt (skip or enter branch) when using the
<br>function, and I like the idea of being forced to choose the correct
<br>outcome.
<br><br>Again, I am not particulary against having mixed relops, but in my
<br>production code I will create all the { less_or, greater_or, etc }
<br>functions so I know exactly what is going on and I let a direct
<br>documentation about how nullopts should be treated for others that
<br>will review it later.
<br></blockquote><div><br>I believe that here we are on the same side. I am=
 now considering poisoning the mixed&nbsp; relops and providing an alternat=
ive, where you are very explicit what you want to do.<br></div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">When you will use less_or, you
<br>will be forced to choose the outcome in the case of a nullopt.
<br>I thought about making the or_result default to true but it looks very =
strange:
<br>
<br>&nbsp; if( less_or(o,v) ) { ... } // ?
<br>
<br>And actually this has the same problems about clarity in case of
<br>nullopt as the mixed rel ops o&lt;v.
<br></blockquote><div><br>My "problem: is somewhat different. There are two=
 ways of being very explicit. <br><br><div class=3D"prettyprint" style=3D"b=
ackground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bord=
er-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"=
prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">// Version 1:</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> less_or</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">o</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">true</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> less_or</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">o</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> v</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">false</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> <br></span></div></code></div><br><div class=3D"p=
rettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// Version 2:</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> less_with_nullopt_least</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">o</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> v</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> less_with_nullopt_greatest</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">o</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> <br></span></div><=
/code></div><br>They are equally "explicit", but there is a significant dif=
ference. In Version 1, I am clear what Boolean value to return in case I ha=
ve a nullopt, but it is less clear what mathematical ordering it implies. I=
n Version 2, the ordering is very explicit, but it is less clear what Boole=
an value we will get. This has the potential risk that I intend semantics "=
least of all Ts" but I incorrectly type "false" as the third argument. In o=
ther words, I anticipate bugs in boolean expressions. This is similar to mi=
styping:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(2=
50, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; borde=
r-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">!</span><span style=3D"color: #000;" class=3D"styled-by-prettify">cond1=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> cond2<br=
></span></div></code></div>instead of <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 clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #660;=
" class=3D"styled-by-prettify">!</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">cond1 </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">||</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> cond2<br></span></div></code></div><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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_478_8380504.1359453847988--

.

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

On Tue, Jan 29, 2013 at 12:20 PM, Vladimir Batov <vb.mail.247@gmail.com>wrote:

> On Tue, Jan 29, 2013 at 10:44 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
> > On 29 January 2013 01:35, Vladimir Batov <vb.mail.247@gmail.com> wrote:
> >>> If this is needed, but rarely, why not provide an explicit function
> >>> instead:
> >>> bool less_than_x(std::optional<int> const& o, const& x)
> >>> {
> >>>   return o.less(x);
> >>>   // or:
> >>>   return std::optional_less(x);
> >>> }
> >> I do not believe the function is complete as it does not seem to handle
> the
> >> disengaged state. To me that disengaged state is pretty much identical
> to
> >> NaN (where it's used to indicate no-value) and NaN does not compare for
> a
> >> reason -- because it's an "orange". :-)
> >
> > But it does handle disengaged state. o.less(x) is true if o is
> disengaged.
> > Whether you like/deem-correct that way of handling disengaged state is
> > the whole issue in this discussion.
>
> Indeed, it does... iff "no-value < any-value" and in all honesty it
> feels quite natural to me. However, from the computational angle it
> does not seem kosher as there is nothing to compare against. Still, we
> can mandate that behavior *inside* an extended class where no-value is
> part of the type, i.e. no-value, value1, value2, etc. and that's
> 'optional' not 'int'. IMO of course.
>
> > How do these oranges become apples just by constructing an optional out
> of them,
> > but can't be compared to apples otherwise?
>
> T and optional<T> are different classes. Not just implementation-wise
> (like char* and std::string) but conceptually as well. Conceptually,
> char* and std::string are the same. Namely, one can get char* from
> std::string and vice versa. It's not the same with T and optional<T>
> -- no-value is the little extra that 'int' does not handle/understand.
> Consequently, when I look at "opt < 5", I am thinking "is 5 upgraded
> to optional or opt is downgraded to int?". It is certainly the former
> -- 5->optional -- as optional->int cannot be safely done. However, I
> find that really subtle and quite a few people will probably interpret
> "opt < 5" the other way around, consequently, missing no-value
> handling. Say, "opt && *opt < 5" spells it out plain and simple to me.
>
> So, if it's somehow made lucidly clear that "opt < 5" applies
> 5->optional upgrade (not physically with, say, implicit constructor
> but conceptually), then I guess I'll sleep much better at night. :-)
>

Now I think I've come the full circle. I started supporting mixed relops,
then flipped to the other side arguing that "opt < 5" was ambiguous and now
I am ready to accept that mixed relops have their place... with a caveat.

I started with "homogeneous" (as Andrzej called them) relops. I feel they
are necessary from the practical point of view (at the very least for an
easy integration with ass. containers) and they are IMO legit conceptually.
Having accepted the validity and the need of "opt1 < opt2" there was a
really small step from "opt < optional<int>(5)" to "opt < 5" which can be
justified by notational convenience and performance reasons. Therefore, IFF
"opt < 5" stands to mean and is an optimized version of  "opt <
optional<int>(5)", then I really have no ammunition to argue against that.
And I feel that power users will and do want that. I still think that
deciphering "opt < 5" takes quite an effort for uninitiated and I feel that
allowing that syntax *will* lead to bugs. However, if mixed relops make it
in, they won't be the only subtle place in the std library. So, as long as
the behavior is clearly described in the documentation, the onus is on the
user to deploy "opt < 5" correctly.

--

---
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/?hl=en.



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

<div class=3D"gmail_quote">On Tue, Jan 29, 2013 at 12:20 PM, Vladimir Batov=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:vb.mail.247@gmail.com" target=3D"_=
blank">vb.mail.247@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
<div class=3D"im">On Tue, Jan 29, 2013 at 10:44 AM, Ville Voutilainen<br>
&lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.=
com</a>&gt; wrote:<br>
&gt; On 29 January 2013 01:35, Vladimir Batov &lt;<a href=3D"mailto:vb.mail=
..247@gmail.com">vb.mail.247@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt; If this is needed, but rarely, why not provide an explicit fun=
ction<br>
&gt;&gt;&gt; instead:<br>
&gt;&gt;&gt; bool less_than_x(std::optional&lt;int&gt; const&amp; o, const&=
amp; x)<br>
&gt;&gt;&gt; {<br>
&gt;&gt;&gt; =A0 return o.less(x);<br>
&gt;&gt;&gt; =A0 // or:<br>
&gt;&gt;&gt; =A0 return std::optional_less(x);<br>
&gt;&gt;&gt; }<br>
&gt;&gt; I do not believe the function is complete as it does not seem to h=
andle the<br>
&gt;&gt; disengaged state. To me that disengaged state is pretty much ident=
ical to<br>
&gt;&gt; NaN (where it&#39;s used to indicate no-value) and NaN does not co=
mpare for a<br>
&gt;&gt; reason -- because it&#39;s an &quot;orange&quot;. :-)<br>
&gt;<br>
&gt; But it does handle disengaged state. o.less(x) is true if o is disenga=
ged.<br>
&gt; Whether you like/deem-correct that way of handling disengaged state is=
<br>
&gt; the whole issue in this discussion.<br>
<br>
</div>Indeed, it does... iff &quot;no-value &lt; any-value&quot; and in all=
 honesty it<br>
feels quite natural to me. However, from the computational angle it<br>
does not seem kosher as there is nothing to compare against. Still, we<br>
can mandate that behavior *inside* an extended class where no-value is<br>
part of the type, i.e. no-value, value1, value2, etc. and that&#39;s<br>
&#39;optional&#39; not &#39;int&#39;. IMO of course.<br>
<div class=3D"im"><br>
&gt; How do these oranges become apples just by constructing an optional ou=
t of them,<br>
&gt; but can&#39;t be compared to apples otherwise?<br>
<br>
</div>T and optional&lt;T&gt; are different classes. Not just implementatio=
n-wise<br>
(like char* and std::string) but conceptually as well. Conceptually,<br>
char* and std::string are the same. Namely, one can get char* from<br>
std::string and vice versa. It&#39;s not the same with T and optional&lt;T&=
gt;<br>
-- no-value is the little extra that &#39;int&#39; does not handle/understa=
nd.<br>
Consequently, when I look at &quot;opt &lt; 5&quot;, I am thinking &quot;is=
 5 upgraded<br>
to optional or opt is downgraded to int?&quot;. It is certainly the former<=
br>
-- 5-&gt;optional -- as optional-&gt;int cannot be safely done. However, I<=
br>
find that really subtle and quite a few people will probably interpret<br>
&quot;opt &lt; 5&quot; the other way around, consequently, missing no-value=
<br>
handling. Say, &quot;opt &amp;&amp; *opt &lt; 5&quot; spells it out plain a=
nd simple to me.<br>
<br>
So, if it&#39;s somehow made lucidly clear that &quot;opt &lt; 5&quot; appl=
ies<br>
5-&gt;optional upgrade (not physically with, say, implicit constructor<br>
but conceptually), then I guess I&#39;ll sleep much better at night. :-)<br=
>
</blockquote></div><br>Now I think I&#39;ve come the full circle. I started=
 supporting mixed relops, then flipped to the other side arguing that &quot=
;opt &lt; 5&quot; was ambiguous and now I am ready to accept that mixed rel=
ops have their place... with a caveat. <br>
<br>I started with &quot;homogeneous&quot; (as Andrzej called them) relops.=
 I feel they are necessary from the practical point of view (at the very le=
ast for an easy integration with ass. containers) and they are IMO legit co=
nceptually. Having accepted the validity and the need of &quot;opt1 &lt; op=
t2&quot; there was a really small step from &quot;opt &lt; optional&lt;int&=
gt;(5)&quot; to &quot;opt &lt; 5&quot; which can be justified by notational=
 convenience and performance reasons. Therefore, IFF &quot;opt &lt; 5&quot;=
 stands to mean and is an optimized version of=A0 &quot;opt &lt; optional&l=
t;int&gt;(5)&quot;, then I really have no ammunition to argue against that.=
 And I feel that power users will and do want that. I still think that deci=
phering &quot;opt &lt; 5&quot; takes quite an effort for uninitiated and I =
feel that allowing that syntax *will* lead to bugs. However, if mixed relop=
s make it in, they won&#39;t be the only subtle place in the std library. S=
o, as long as the behavior is clearly described in the documentation, the o=
nus is on the user to deploy &quot;opt &lt; 5&quot; correctly.=A0 <br>
<br><br>

<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--14dae934034711edaa04d46b2996--

.

On Tue, Jan 29, 2013 at 11:04 AM, Andrzej Krzemie=C5=84ski
<akrzemi1@gmail.com> wrote:
> My "problem: is somewhat different. There are two ways of being very
> explicit.
>
> // Version 1:
> return less_or(o, v, true);
> return less_or(o, v, false);
>
> // Version 2:
> return less_with_nullopt_least(o, v);
> return less_with_nullopt_greatest(o, v);
>
> They are equally "explicit", but there is a significant difference. In
> Version 1, I am clear what Boolean value to return in case I have a nullo=
pt,
> but it is less clear what mathematical ordering it implies. In Version 2,
> the ordering is very explicit, but it is less clear what Boolean value we
> will get. This has the potential risk that I intend semantics "least of a=
ll
> Ts" but I incorrectly type "false" as the third argument. In other words,=
 I
> anticipate bugs in boolean expressions. This is similar to mistyping:
>
> !cond1 && cond2
> instead of
> !cond1 || cond2

Ok, I understand you now.

IMO, both things are useful for different scenarios. less_or will be
used in branching code or logic in the same way that the intended
value_or use.
The other options does not looks clear to me, compare:

  if( less_or(o,v,false) ) {...}   -vs-   if(
less_with_nullopt_greatest(o, v) ) {...}

So, less_or is not intended to provide an ordering for the set
{nullopt,values}, it is directly giving you the tools to manage your
code logic when dealing with optional types. I think this is what all
the xxx_or kind of facilities gains you. The important thing is that I
do not want to impose an ordering of {nullopt,values}, in my function
logic, I just want to react differently in the case of nullopt (this
is closer to what was proposed about nullopt being well behaved NaN).

Where the less_with_nullopt_xxx version are better suit is when you
actually want to invent an ordering for the set {nullopt,values}. Two
examples (if we actually made them as functors) are using std::sort
and as the key_compare of a std ordered container.
So I think they have value in the context of this discussion, but I do
not see them as opposing the xxx_or family of functions.

Best regards
Matias

--=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/?hl=3Den.



.

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

On Monday, January 28, 2013 11:58:17 PM UTC+1, Andrzej Krzemie=C5=84ski wro=
te:

> I needed to say this in a new thread as the other one was getting too=20
> crowded.
>

What are the use cases for normal relops? Containers and sorting?

Normal relops compare apples + oranges to apples + oranges which seems=20
kinda unsound too.

Who has real-world code other than containers and sorting?

--=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/?hl=3Den.



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

On Monday, January 28, 2013 11:58:17 PM UTC+1, Andrzej Krzemie=C5=84ski wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I needed to say this in=
 a new thread as the other one was getting too crowded.<br></blockquote><di=
v><br></div><div>What are the use cases for normal relops? Containers and s=
orting?</div><div><br></div><div>Normal relops compare apples + oranges to =
apples + oranges which seems kinda unsound too.</div><div><br></div><div>Wh=
o has real-world code other than containers and sorting?</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1749_13657175.1359457780344--

.

------=_Part_1829_9397875.1359459372962
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu wtorek, 29 stycznia 2013 12:09:40 UTC+1 u=BFytkownik Olaf van der Sp=
ek=20
napisa=B3:
>
> On Monday, January 28, 2013 11:58:17 PM UTC+1, Andrzej Krzemie=F1ski wrot=
e:
>
>> I needed to say this in a new thread as the other one was getting too=20
>> crowded.
>>
>
> What are the use cases for normal relops? Containers and sorting?
>
> Normal relops compare apples + oranges to apples + oranges which seems=20
> kinda unsound too.
>
> Who has real-world code other than containers and sorting?
>

The only rationale I have for (homogenous) relops is associative=20
containers. I do not even need sorting for purposes other than storage in=
=20
associative containers.

This is for operator<. For operator=3D=3D, this is to make the type regular=
..

--=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/?hl=3Den.



------=_Part_1829_9397875.1359459372962
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu wtorek, 29 stycznia 2013 12:09:40 UTC+1 u=BFytkownik Olaf va=
n der Spek napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday=
, January 28, 2013 11:58:17 PM UTC+1, Andrzej Krzemie=F1ski wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">I needed to say this in a new thread as =
the other one was getting too crowded.<br></blockquote><div><br></div><div>=
What are the use cases for normal relops? Containers and sorting?</div><div=
><br></div><div>Normal relops compare apples + oranges to apples + oranges =
which seems kinda unsound too.</div><div><br></div><div>Who has real-world =
code other than containers and sorting?</div></blockquote><div><br>The only=
 rationale I have for (homogenous) relops is associative containers. I do n=
ot even need sorting for purposes other than storage in associative contain=
ers.<br><br>This is for operator&lt;. For operator=3D=3D, this is to make t=
he type regular.<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1829_9397875.1359459372962--

.

------=_Part_126_22303808.1359459574233
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu wtorek, 29 stycznia 2013 12:03:28 UTC+1 u=BFytkownik Matias Capelett=
o=20
napisa=B3:
>
> On Tue, Jan 29, 2013 at 11:04 AM, Andrzej Krzemie=F1ski=20
> <akrz...@gmail.com <javascript:>> wrote:=20
> > My "problem: is somewhat different. There are two ways of being very=20
> > explicit.=20
> >=20
> > // Version 1:=20
> > return less_or(o, v, true);=20
> > return less_or(o, v, false);=20
> >=20
> > // Version 2:=20
> > return less_with_nullopt_least(o, v);=20
> > return less_with_nullopt_greatest(o, v);=20
> >=20
> > They are equally "explicit", but there is a significant difference. In=
=20
> > Version 1, I am clear what Boolean value to return in case I have a=20
> nullopt,=20
> > but it is less clear what mathematical ordering it implies. In Version=
=20
> 2,=20
> > the ordering is very explicit, but it is less clear what Boolean value=
=20
> we=20
> > will get. This has the potential risk that I intend semantics "least of=
=20
> all=20
> > Ts" but I incorrectly type "false" as the third argument. In other=20
> words, I=20
> > anticipate bugs in boolean expressions. This is similar to mistyping:=
=20
> >=20
> > !cond1 && cond2=20
> > instead of=20
> > !cond1 || cond2=20
>
> Ok, I understand you now.=20
>
> IMO, both things are useful for different scenarios. less_or will be=20
> used in branching code or logic in the same way that the intended=20
> value_or use.=20
> The other options does not looks clear to me, compare:=20
>
>   if( less_or(o,v,false) ) {...}   -vs-   if(=20
> less_with_nullopt_greatest(o, v) ) {...}=20
>
> So, less_or is not intended to provide an ordering for the set=20
> {nullopt,values}, it is directly giving you the tools to manage your=20
> code logic when dealing with optional types. I think this is what all=20
> the xxx_or kind of facilities gains you. The important thing is that I=20
> do not want to impose an ordering of {nullopt,values}, in my function=20
> logic, I just want to react differently in the case of nullopt (this=20
> is closer to what was proposed about nullopt being well behaved NaN).=20
>
> Where the less_with_nullopt_xxx version are better suit is when you=20
> actually want to invent an ordering for the set {nullopt,values}. Two=20
> examples (if we actually made them as functors) are using std::sort=20
> and as the key_compare of a std ordered container.=20
> So I think they have value in the context of this discussion, but I do=20
> not see them as opposing the xxx_or family of functions.=20
>

I agree. On the other han,d proposing both sets may make the interface too=
=20
big. I would really like to see real-life examples of using=20
boost::optional's mixed relops. This would really help make my mind.

--=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/?hl=3Den.



------=_Part_126_22303808.1359459574233
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu wtorek, 29 stycznia 2013 12:03:28 UTC+1 u=BFytkownik Matias =
Capeletto napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Ja=
n 29, 2013 at 11:04 AM, Andrzej Krzemie=F1ski
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
X8JQQk6OsigJ">akrz...@gmail.com</a>&gt; wrote:
<br>&gt; My "problem: is somewhat different. There are two ways of being ve=
ry
<br>&gt; explicit.
<br>&gt;
<br>&gt; // Version 1:
<br>&gt; return less_or(o, v, true);
<br>&gt; return less_or(o, v, false);
<br>&gt;
<br>&gt; // Version 2:
<br>&gt; return less_with_nullopt_least(o, v);
<br>&gt; return less_with_nullopt_greatest(o, v);
<br>&gt;
<br>&gt; They are equally "explicit", but there is a significant difference=
.. In
<br>&gt; Version 1, I am clear what Boolean value to return in case I have =
a nullopt,
<br>&gt; but it is less clear what mathematical ordering it implies. In Ver=
sion 2,
<br>&gt; the ordering is very explicit, but it is less clear what Boolean v=
alue we
<br>&gt; will get. This has the potential risk that I intend semantics "lea=
st of all
<br>&gt; Ts" but I incorrectly type "false" as the third argument. In other=
 words, I
<br>&gt; anticipate bugs in boolean expressions. This is similar to mistypi=
ng:
<br>&gt;
<br>&gt; !cond1 &amp;&amp; cond2
<br>&gt; instead of
<br>&gt; !cond1 || cond2
<br>
<br>Ok, I understand you now.
<br>
<br>IMO, both things are useful for different scenarios. less_or will be
<br>used in branching code or logic in the same way that the intended
<br>value_or use.
<br>The other options does not looks clear to me, compare:
<br>
<br>&nbsp; if( less_or(o,v,false) ) {...} &nbsp; -vs- &nbsp; if(
<br>less_with_nullopt_greatest(o, v) ) {...}
<br>
<br>So, less_or is not intended to provide an ordering for the set
<br>{nullopt,values}, it is directly giving you the tools to manage your
<br>code logic when dealing with optional types. I think this is what all
<br>the xxx_or kind of facilities gains you. The important thing is that I
<br>do not want to impose an ordering of {nullopt,values}, in my function
<br>logic, I just want to react differently in the case of nullopt (this
<br>is closer to what was proposed about nullopt being well behaved NaN).
<br>
<br>Where the less_with_nullopt_xxx version are better suit is when you
<br>actually want to invent an ordering for the set {nullopt,values}. Two
<br>examples (if we actually made them as functors) are using std::sort
<br>and as the key_compare of a std ordered container.
<br>So I think they have value in the context of this discussion, but I do
<br>not see them as opposing the xxx_or family of functions.
<br></blockquote><div><br>I agree. On the other han,d proposing both sets m=
ay make the interface too big. I would really like to see real-life example=
s of using boost::optional's mixed relops. This would really help make my m=
ind.<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_126_22303808.1359459574233--

.

On Tue, Jan 29, 2013 at 12:36 PM, Andrzej Krzemie=C5=84ski
<akrzemi1@gmail.com> wrote:
> The only rationale I have for (homogenous) relops is associative containe=
rs.
> I do not even need sorting for purposes other than storage in associative
> containers.

You could define std::less but not operator< for that.

> This is for operator<. For operator=3D=3D, this is to make the type regul=
ar.

What's the use case for that?

--=20
Olaf

--=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/?hl=3Den.



.

------=_Part_154_31915195.1359461289680
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu wtorek, 29 stycznia 2013 12:44:27 UTC+1 u=BFytkownik Olaf van der Sp=
ek=20
napisa=B3:
>
> On Tue, Jan 29, 2013 at 12:36 PM, Andrzej Krzemie=F1ski=20
> <akrz...@gmail.com <javascript:>> wrote:=20
> > The only rationale I have for (homogenous) relops is associative=20
> containers.=20
> > I do not even need sorting for purposes other than storage in=20
> associative=20
> > containers.=20
>
> You could define std::less but not operator< for that.=20
>

You are proposing this because you think std::less is about ordering and=20
operator< is for something else than ordering. Am I right? But is operator<=
=20
about anything else than ordering?

> This is for operator<. For operator=3D=3D, this is to make the type regul=
ar.=20
>
> What's the use case for that?=20
>

Good question. I take making all value-semantic types regular for granted.=
=20
I never gave it much thought, if it is really needed for optional. I am not=
=20
saying it is not needed though.

For value semantic types operator=3D=3D provides the definition of the valu=
e=20
for a given type. You can use it to verify if copy constructor/assignment=
=20
works correctly. You can use it in testing.

Do you ever need operator=3D=3D for vectors? If you do, you would also prob=
ably=20
want one for vector<optional<T>>.

--=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/?hl=3Den.



------=_Part_154_31915195.1359461289680
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu wtorek, 29 stycznia 2013 12:44:27 UTC+1 u=BFytkownik Olaf va=
n der Spek napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, J=
an 29, 2013 at 12:36 PM, Andrzej Krzemie=F1ski
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
3t8ISogKCDIJ">akrz...@gmail.com</a>&gt; wrote:
<br>&gt; The only rationale I have for (homogenous) relops is associative c=
ontainers.
<br>&gt; I do not even need sorting for purposes other than storage in asso=
ciative
<br>&gt; containers.
<br>
<br>You could define std::less but not operator&lt; for that.
<br></blockquote><div><br>You are proposing this because you think std::les=
s is about ordering and operator&lt; is for something else than ordering. A=
m I right? But is operator&lt; about anything else than ordering?<br><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; This is for operator&=
lt;. For operator=3D=3D, this is to make the type regular.
<br>
<br>What's the use case for that?
<br></blockquote><div><br>Good question. I take making all value-semantic t=
ypes regular for granted. I never gave it much thought, if it is really nee=
ded for optional. I am not saying it is not needed though.<br><br>For value=
 semantic types operator=3D=3D provides the definition of the value for a g=
iven type. You can use it to verify if copy constructor/assignment works co=
rrectly. You can use it in testing.<br><br>Do you ever need operator=3D=3D =
for vectors? If you do, you would also probably want one for vector&lt;opti=
onal&lt;T&gt;&gt;.<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_154_31915195.1359461289680--

.

On Tue, Jan 29, 2013 at 1:08 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>> You could define std::less but not operator< for that.
>
>
> You are proposing this because you think std::less is about ordering and
> operator< is for something else than ordering. Am I right? But is operato=
r<
> about anything else than ordering?

No, I'm proposing it because std::map uses std::less (by default).
Maybe you should go a step further and call it optional_less (or so)
such that the user is required to explicitly select it.

To me, an (unordered) map isn't really about ordering, it's about
mapping / associating. Ordering is kind of an implementation detail.

>> > This is for operator<. For operator=3D=3D, this is to make the type re=
gular.
>>
>> What's the use case for that?
>
>
> Good question. I take making all value-semantic types regular for granted=
.. I
> never gave it much thought, if it is really needed for optional. I am not
> saying it is not needed though.
>
> For value semantic types operator=3D=3D provides the definition of the va=
lue for
> a given type. You can use it to verify if copy constructor/assignment wor=
ks
> correctly. You can use it in testing.
>
> Do you ever need operator=3D=3D for vectors? If you do, you would also pr=
obably
> want one for vector<optional<T>>.

I don't recall ever using it. I'm not even sure whether it was
available before C++11. Was it added in C++11?


--=20
Olaf

--=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/?hl=3Den.



.

On Tue, Jan 29, 2013 at 12:39 PM, Andrzej Krzemie=F1ski
<akrzemi1@gmail.com> wrote:
> W dniu wtorek, 29 stycznia 2013 12:03:28 UTC+1 u=BFytkownik Matias Capele=
tto
> napisa=B3:
>> IMO, both things are useful for different scenarios. less_or will be
>> used in branching code or logic in the same way that the intended
>> value_or use.
>> ...
>>
>> Where the less_with_nullopt_xxx version are better suit is when you
>> actually want to invent an ordering for the set {nullopt,values}. Two
>> examples (if we actually made them as functors) are using std::sort
>> and as the key_compare of a std ordered container.
>> So I think they have value in the context of this discussion, but I do
>> not see them as opposing the xxx_or family of functions.
>
> I agree. On the other han,d proposing both sets may make the interface to=
o
> big. I would really like to see real-life examples of using
> boost::optional's mixed relops. This would really help make my mind.

Thinking more about it, I am starting to believe that the
less_with_nullopt_xxx variant are not that useful.
In the two examples that I included before for it (when you really
need to define an ordering for {nullopt,values}) you are not really
dealing with mixed optionals and Ts... you are generally sorting a
list of optionals, or defining the key_compare for a container that
holds optionals (there are no bare T here).

For these scenarios, I do not think that having both behaviors is
really important. It just should be clear for the user where all the
nullopt values are going to end up. So you can write code like:

  set<optional<T>> opt_set { ... } ;

  // Iterate over non-nullopt values
  for_each( make_indirect_iterator( opt_set.upper_bound(nullopt) )
              , make_indirect_iterator( opt_set.end() )
              , [](T& t){ ... } );

Best regards
Matias

--=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/?hl=3Den.



.

------=_Part_648_25390415.1359464049497
Content-Type: text/plain; charset=ISO-8859-1



> >
> > Do you ever need operator== for vectors? If you do, you would also
> probably
> > want one for vector<optional<T>>.
>
> I don't recall ever using it. I'm not even sure whether it was
> available before C++11. Was it added in C++11?
>

I am not sure when they were added precisely, but I can see a draft from
2004 (N1638) that already requires operator== for vectors.

--

---
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/?hl=en.



------=_Part_648_25390415.1359464049497
Content-Type: text/html; charset=ISO-8859-1

<br><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt;
<br>&gt; Do you ever need operator== for vectors? If you do, you would also probably
<br>&gt; want one for vector&lt;optional&lt;T&gt;&gt;.
<br>
<br>I don't recall ever using it. I'm not even sure whether it was
<br>available before C++11. Was it added in C++11?
<br></blockquote><div><br>I am not sure when they were added precisely, but I can see a draft from 2004 (N1638) that already requires operator== for vectors.</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/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_648_25390415.1359464049497--

.

------=_Part_387_21244216.1359468844880
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu wtorek, 29 stycznia 2013 13:26:58 UTC+1 u=BFytkownik Matias Capelett=
o=20
napisa=B3:
>
> On Tue, Jan 29, 2013 at 12:39 PM, Andrzej Krzemie=F1ski=20
> <akrz...@gmail.com <javascript:>> wrote:=20
> > W dniu wtorek, 29 stycznia 2013 12:03:28 UTC+1 u=BFytkownik Matias=20
> Capeletto=20
> > napisa=B3:=20
> >> IMO, both things are useful for different scenarios. less_or will be=
=20
> >> used in branching code or logic in the same way that the intended=20
> >> value_or use.=20
> >> ...=20
> >>=20
> >> Where the less_with_nullopt_xxx version are better suit is when you=20
> >> actually want to invent an ordering for the set {nullopt,values}. Two=
=20
> >> examples (if we actually made them as functors) are using std::sort=20
> >> and as the key_compare of a std ordered container.=20
> >> So I think they have value in the context of this discussion, but I do=
=20
> >> not see them as opposing the xxx_or family of functions.=20
> >=20
> > I agree. On the other han,d proposing both sets may make the interface=
=20
> too=20
> > big. I would really like to see real-life examples of using=20
> > boost::optional's mixed relops. This would really help make my mind.=20
>
> Thinking more about it, I am starting to believe that the=20
> less_with_nullopt_xxx variant are not that useful.=20
> In the two examples that I included before for it (when you really=20
> need to define an ordering for {nullopt,values}) you are not really=20
> dealing with mixed optionals and Ts... you are generally sorting a=20
> list of optionals, or defining the key_compare for a container that=20
> holds optionals (there are no bare T here).=20
>
> For these scenarios, I do not think that having both behaviors is=20
> really important. It just should be clear for the user where all the=20
> nullopt values are going to end up. So you can write code like:=20
>
>   set<optional<T>> opt_set { ... } ;=20
>
>   // Iterate over non-nullopt values=20
>   for_each( make_indirect_iterator( opt_set.upper_bound(nullopt) )=20
>               , make_indirect_iterator( opt_set.end() )=20
>               , [](T& t){ ... } );=20
>

This is convincing. Nonetheless, I would be more comfortable making my mind=
=20
if I have seen one or two real-life examples where mixed comparisons with=
=20
boost::optional is used and needed.

--=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/?hl=3Den.



------=_Part_387_21244216.1359468844880
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu wtorek, 29 stycznia 2013 13:26:58 UTC+1 u=BFytkownik Matias =
Capeletto napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Ja=
n 29, 2013 at 12:39 PM, Andrzej Krzemie=F1ski
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
I1httX3-0msJ">akrz...@gmail.com</a>&gt; wrote:
<br>&gt; W dniu wtorek, 29 stycznia 2013 12:03:28 UTC+1 u=BFytkownik Matias=
 Capeletto
<br>&gt; napisa=B3:
<br>&gt;&gt; IMO, both things are useful for different scenarios. less_or w=
ill be
<br>&gt;&gt; used in branching code or logic in the same way that the inten=
ded
<br>&gt;&gt; value_or use.
<br>&gt;&gt; ...
<br>&gt;&gt;
<br>&gt;&gt; Where the less_with_nullopt_xxx version are better suit is whe=
n you
<br>&gt;&gt; actually want to invent an ordering for the set {nullopt,value=
s}. Two
<br>&gt;&gt; examples (if we actually made them as functors) are using std:=
:sort
<br>&gt;&gt; and as the key_compare of a std ordered container.
<br>&gt;&gt; So I think they have value in the context of this discussion, =
but I do
<br>&gt;&gt; not see them as opposing the xxx_or family of functions.
<br>&gt;
<br>&gt; I agree. On the other han,d proposing both sets may make the inter=
face too
<br>&gt; big. I would really like to see real-life examples of using
<br>&gt; boost::optional's mixed relops. This would really help make my min=
d.
<br>
<br>Thinking more about it, I am starting to believe that the
<br>less_with_nullopt_xxx variant are not that useful.
<br>In the two examples that I included before for it (when you really
<br>need to define an ordering for {nullopt,values}) you are not really
<br>dealing with mixed optionals and Ts... you are generally sorting a
<br>list of optionals, or defining the key_compare for a container that
<br>holds optionals (there are no bare T here).
<br>
<br>For these scenarios, I do not think that having both behaviors is
<br>really important. It just should be clear for the user where all the
<br>nullopt values are going to end up. So you can write code like:
<br>
<br>&nbsp; set&lt;optional&lt;T&gt;&gt; opt_set { ... } ;
<br>
<br>&nbsp; // Iterate over non-nullopt values
<br>&nbsp; for_each( make_indirect_iterator( opt_set.upper_bound(nullopt) )
<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; , make_indirect_iterat=
or( opt_set.end() )
<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; , [](T&amp; t){ ... } =
);
<br></blockquote><div><br>This is convincing. Nonetheless, I would be more =
comfortable making my mind if I have seen one or two real-life examples whe=
re mixed comparisons with boost::optional is used and needed.<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_387_21244216.1359468844880--

.

On Tue, Jan 29, 2013 at 3:14 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>> Thinking more about it, I am starting to believe that the
>> less_with_nullopt_xxx variant are not that useful.
>> In the two examples that I included before for it (when you really
>> need to define an ordering for {nullopt,values}) you are not really
>> dealing with mixed optionals and Ts... you are generally sorting a
>> list of optionals, or defining the key_compare for a container that
>> holds optionals (there are no bare T here).
>>
>> For these scenarios, I do not think that having both behaviors is
>> really important. It just should be clear for the user where all the
>> nullopt values are going to end up. So you can write code like:
>>
>>   set<optional<T>> opt_set { ... } ;
>>
>>   // Iterate over non-nullopt values
>>   for_each( make_indirect_iterator( opt_set.upper_bound(nullopt) )
>>               , make_indirect_iterator( opt_set.end() )
>>               , [](T& t){ ... } );
>
>
> This is convincing. Nonetheless, I would be more comfortable making my mi=
nd
> if I have seen one or two real-life examples where mixed comparisons with
> boost::optional is used and needed.

The LibreOffice code base seems to use Boost.Optional all over the
place. Some examples can be extracted from that base, looking at the
things devs needed to do to make their code 'clean'.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
http://code.ohloh.net/file?fid=3Dv91c-L6U0X9bMpoLDfWbZ2jq-80&cid=3Dfu_u3DIn=
rXQ&s=3D%22maRepeats%22&mp=3D1&ml=3D1&me=3D1&md=3D1&browser=3DDefault#L198

The class has an optional<int> called maRepeats, and they are using it like=
:

  // clamp repeats to max permissible value (maRepeats.getValue() - 1.0)
  if( isRepeatCountValid() && nRepeats >=3D getRepeatCount() ) {
    ...
  }

They made two functions: isRepeatCountValid() { return maRepeats; }
and getRepeatCount() { return *maRepeats; }, but the example still
stands.
So here they are using:

    if( maRepeats && nRepeats >=3D *maRepeats )

This could have been written like:

    if( less_or( maRepeats, nRepeats, false ) )

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

And here you can see that they needed the other option:
http://code.ohloh.net/file?fid=3D1rFJOT_JoaH4-Vz107f74opWCW8&cid=3DvRnA3dIX=
_Pw&s=3D%22isRepeatCountValid%22&mp=3D1&ml=3D1&me=3D1&md=3D1&browser=3DDefa=
ult#L148

  if( !isRepeatCountValid() || nCurrRepeat < getRepeatCount() ) { ...

This is the same as:

    if( greater_or( maRepeats, nCurrRepeat, true ) ) { ...
or:
    if( less_or( nCurrRepeat, maRepeats, true ) ) { ...

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

There should be a lot more examples like this around.

Best regards
Matias

--=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/?hl=3Den.



.

------=_Part_943_16973167.1359473362152
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable


On Tuesday, January 29, 2013 4:04:07 AM UTC-6, Andrzej Krzemie=F1ski wrote:
>
>
> // Version 1:
> return less_or(o, v, true);
> return less_or(o, v, false);=20
>
> // Version 2:
> return less_with_nullopt_least(o, v);
> return less_with_nullopt_greatest(o, v);=20
>
> They are equally "explicit", but there is a significant difference. In=20
> Version 1, I am clear what Boolean value to return in case I have a=20
> nullopt, but it is less clear what mathematical ordering it implies. In=
=20
> Version 2, the ordering is very explicit, but it is less clear what Boole=
an=20
> value we will get. This has the potential risk that I intend semantics=20
> "least of all Ts" but I incorrectly type "false" as the third argument.
>

I cannot imagine a use case where a programmer would ever pass a=20
non-literal for the third parameter of less_or(), in which case it may be=
=20
clearer to specify it as :
template <bool NullValue, typename T>
bool less_or(const optional<T>&o, const T& v)
{return o ? *o < v : NullValue; }
so that uses read as "less_or<true>(o, t)" / "less_or<false>(o, t)" which I=
=20
think is more readable.

If you are truly worried about semantic confusion, I think the names=20
less_or_null(o, v) and greater_or_null(o, v) are more explicit and readable=
=20
then less_with_nullopt_XXX despite being more terse.

--=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/?hl=3Den.



------=_Part_943_16973167.1359473362152
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br>On Tuesday, January 29, 2013 4:04:07 AM UTC-6, Andrzej Krzemie=F1ski wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><br><div><div style=3D"bac=
kground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:s=
olid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"color=
:#800">// Version 1:</span><span style=3D"color:#000"><br></span><span styl=
e=3D"color:#008">return</span><span style=3D"color:#000"> less_or</span><sp=
an style=3D"color:#660">(</span><span style=3D"color:#000">o</span><span st=
yle=3D"color:#660">,</span><span style=3D"color:#000"> v</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">true</span><span style=3D"color:#660">);</span><span style=3D"co=
lor:#000"><br></span><span style=3D"color:#008">return</span><span style=3D=
"color:#000"> less_or</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">o</span><span style=3D"color:#660">,</span><span style=3D"c=
olor:#000"> v</span><span style=3D"color:#660">,</span><span style=3D"color=
:#000"> </span><span style=3D"color:#008">false</span><span style=3D"color:=
#660">);</span><span style=3D"color:#000"> <br></span></div></code></div><b=
r><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:#800">// Version 2:</span><span style=3D"color:#000"><b=
r></span><span style=3D"color:#008">return</span><span style=3D"color:#000"=
> less_with_nullopt_least</span><span style=3D"color:#660">(</span><span st=
yle=3D"color:#000">o</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> v</span><span style=3D"color:#660">);</span><span style=3D=
"color:#000"><br></span><span style=3D"color:#008">return</span><span style=
=3D"color:#000"> less_with_nullopt_greatest</span><span style=3D"color:#660=
">(</span><span style=3D"color:#000">o</span><span style=3D"color:#660">,</=
span><span style=3D"color:#000"> v</span><span style=3D"color:#660">);</spa=
n><span style=3D"color:#000"> <br></span></div></code></div><br>They are eq=
ually "explicit", but there is a significant difference. In Version 1, I am=
 clear what Boolean value to return in case I have a nullopt, but it is les=
s clear what mathematical ordering it implies. In Version 2, the ordering i=
s very explicit, but it is less clear what Boolean value we will get. This =
has the potential risk that I intend semantics "least of all Ts" but I inco=
rrectly type "false" as the third argument.<br></div></blockquote><div><br>=
</div><div>I cannot imagine a use case where a programmer would ever pass a=
 non-literal for the third parameter of less_or(), in which case it may be =
clearer to specify it as :</div><div><div style=3D"background-color: rgb(25=
0, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"=
 class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><font color=3D"#660066"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">template</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">bool=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">NullValue</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> less_or</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> opt=
ional</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&gt;&amp;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">o</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> v</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> o </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">?</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">o </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> v </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">NullValue</span><span s=
tyle=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></font></div></code></div>so that =
uses read as "less_or&lt;true&gt;(o, t)" / "less_or&lt;false&gt;(o, t)" whi=
ch I think is more readable.</div><div><br></div><div>If you are truly worr=
ied about semantic confusion, I think the names less_or_null(o, v) and grea=
ter_or_null(o, v) are more explicit and readable then less_with_nullopt_XXX=
 despite being more terse.</div><div><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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_943_16973167.1359473362152--

.

On Tue, Jan 29, 2013 at 4:29 PM,  <cartec69@gmail.com> wrote:
> I cannot imagine a use case where a programmer would ever pass a non-literal
> for the third parameter of less_or(), in which case it may be clearer to
> specify it as :
>
>   template <bool NullValue, typename T>
>   bool less_or(const optional<T>&o, const T& v)
>   {return o ? *o < v : NullValue; }
>
> so that uses read as "less_or<true>(o, t)" / "less_or<false>(o, t)" which I
> think is more readable.

An interesting idea, but I posted an example yesterday in another
thread where I needed an expression. Here it goes again:

  void user_resize( double sx, optional<double> sy ) {
    if( sx < 0 || less_or(sy, 0, sx<0) ) {
      // Handle mirror special case
    }
    lib_resize(sx,sy);
  }

Because the compiler will optimize away the case where you are written
"false" or "true", I think that is better to leave it as a parameter.

--

---
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/?hl=en.



.

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

On 29 January 2013 06:54, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:

>
> >
>> > Do you ever need operator=3D=3D for vectors? If you do, you would also
>> probably
>> > want one for vector<optional<T>>.
>>
>> I don't recall ever using it. I'm not even sure whether it was
>> available before C++11. Was it added in C++11?
>>
>
> I am not sure when they were added precisely, but I can see a draft from
> 2004 (N1638) that already requires operator=3D=3D for vectors.
>

It's been there the whole time, along with the other relops.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=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/?hl=3Den.



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

On 29 January 2013 06:54, Andrzej Krzemie=C5=84ski <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</a=
>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">

<div class=3D"im"><br><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt;
<br>&gt; Do you ever need operator=3D=3D for vectors? If you do, you would =
also probably
<br>&gt; want one for vector&lt;optional&lt;T&gt;&gt;.
<br>
<br>I don&#39;t recall ever using it. I&#39;m not even sure whether it was
<br>available before C++11. Was it added in C++11?
<br></blockquote></div><div><br>I am not sure when they were added precisel=
y, but I can see a draft from 2004 (N1638) that already requires operator=
=3D=3D for vectors.<br></div></blockquote><div><br>It&#39;s been there the =
whole time, along with the other relops. <br>

</div></div>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a hr=
ef=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.c=
om</a>&gt;=C2=A0 (847) 691-1404

<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b6dc3ac22109704d46f46e8--

.

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

On Tue, Jan 29, 2013 at 8:39 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om>wrote:

 I would really like to see real-life examples of using boost::optional's
> mixed relops. This would really help make my mind.
>


I'm not sure how to give you that. I mean, "o < n" is an example of that...
but to make it a real-life example, I need to post all of the relevant code
to put that into context. Without proper context, it won't look like the
example is legit.

Anyway, let me try...

(1) this is something I just found in one of my projects:

optional<int> lFirstColor ;

** code that eventually founds the first color **

if ( lFirstColor =3D=3D aSpecialColor )

aSpecialColor is just an int, and if lFirstColor was not found then is
simply not the special color, thus I don't need to test for that
explicitely.
  ...

(2) Here is another...

There is this member in  class:

  optional<int> mInnerSide ;

And there is a method on the class that does:

  if ( gabs(lULDir*lURDir) < gabs(lDLDir*lDRDir) )
  {
    bool lUIsReflex =3D lUAngle > cPi<HFPolar>() ;
    mInnerSide =3D ( lUIsReflex ? cUp : cDw ) ;
  }
  else
  {
    bool lDIsReflex =3D lDAngle > cPi<HFPolar>() ;
    mInnerSide =3D ( lDIsReflex ? cDw : cUp ) ;
  }

As you can see, in there mInnerSide is neccesarily defined

Then I found another method of the class that does:

  HFCurvePieceIntersecter& lIntersecterI =3D mInnerSide =3D=3D cUp ?
Host()->mUIntersecter

                                                            :
Host()->mDIntersecter ;


Now.. this is 15-year old code, so I took the time to follow the flow and
indeed, it would only go through the second method where it just compares
mInnerSide with cUp (which is a const int) if it passed first through the
method that initialized mInnerSide.

So I think there is use-pattern here: you will want to used mixd relops
when you know, withn absolute certainty, that the optional, at that point,
is engaged.


(3) Another:

There is a function taking "optional<int> from"

and there is loop inside, over a range of x coordinates, and it reads:

if ( x > from )
{
 do something.
}

in this case, the actual x range is dependent on elements that exists
within the function, so, if I the caller wants the loop to do something for
all x in the range, he just passes nullopt. That works because any x is >
nullopt


Best

--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=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/?hl=3Den.



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jan 29, 2013 at 8:39 AM, Andrzej Krzemie=C5=84ski <span dir=3D"ltr">&lt=
;<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com=
</a>&gt;</span> wrote:<br>

<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">=C2=A0I would really =
like to see real-life examples of using boost::optional&#39;s mixed relops.=
 This would really help make my mind.<br>

</blockquote><div><br><br></div><div>I&#39;m not sure how to give you that.=
 I mean, &quot;o &lt; n&quot; is an example of that... but to make it a rea=
l-life example, I need to post all of the relevant code to put that into co=
ntext. Without proper context, it won&#39;t look like the example is legit.=
 <br>

<br></div><div>Anyway, let me try...<br><br>(1) this is something I just fo=
und in one of my projects:<br><br></div><div>optional&lt;int&gt; lFirstColo=
r ;<br><br></div><div>** code that eventually founds the first color **<br>

<br></div><div>if ( lFirstColor =3D=3D aSpecialColor )=C2=A0 <br><br>aSpeci=
alColor is just an int, and if lFirstColor was not found then is simply not=
 the special color, thus I don&#39;t need to test for that explicitely.<br>=
=C2=A0 ...<br>

<br></div><div>(2) Here is another...<br><br></div><div>There is this membe=
r in=C2=A0 class:<br><br></div><div>=C2=A0 optional&lt;int&gt; mInnerSide ;=
<br><br></div><div>And there is a method on the class that does:<br><br>=C2=
=A0 if ( gabs(lULDir*lURDir) &lt; gabs(lDLDir*lDRDir) )<br>

=C2=A0 {<br>=C2=A0=C2=A0=C2=A0 bool lUIsReflex =3D lUAngle &gt; cPi&lt;HFPo=
lar&gt;() ;<br>=C2=A0=C2=A0=C2=A0 mInnerSide =3D ( lUIsReflex ? cUp : cDw )=
 ;<br>=C2=A0 }<br>=C2=A0 else<br>=C2=A0 {<br>=C2=A0=C2=A0=C2=A0 bool lDIsRe=
flex =3D lDAngle &gt; cPi&lt;HFPolar&gt;() ;<br>=C2=A0=C2=A0=C2=A0 mInnerSi=
de =3D ( lDIsReflex ? cDw : cUp ) ;<br>

=C2=A0 }<br><br></div><div>As you can see, in there mInnerSide is neccesari=
ly defined<br></div><div><br></div><div>Then I found another method of the =
class that does:<br><br></div><div>=C2=A0 HFCurvePieceIntersecter&amp; lInt=
ersecterI =3D mInnerSide =3D=3D cUp ? Host()-&gt;mUIntersecter<br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 : Host()-&gt;mDIntersecter ;<br><br></div><div></div><br=
></div><div class=3D"gmail_quote">Now.. this is 15-year old code, so I took=
 the time to follow the flow and indeed, it would only go through the secon=
d method where it just compares mInnerSide with cUp (which is a const int) =
if it passed first through the method that initialized mInnerSide.<br>

<br></div><div class=3D"gmail_quote">So I think there is use-pattern here: =
you will want to used mixd relops when you know, withn absolute certainty, =
that the optional, at that point, is engaged.<br><br><br></div><div class=
=3D"gmail_quote">

(3) Another:<br><br></div><div class=3D"gmail_quote">There is a function ta=
king &quot;optional&lt;int&gt; from&quot;<br><br></div><div class=3D"gmail_=
quote">and there is loop inside, over a range of x coordinates, and it read=
s:<br>

<br></div><div class=3D"gmail_quote">if ( x &gt; from )<br>{<br></div><div =
class=3D"gmail_quote">=C2=A0do something.<br></div><div class=3D"gmail_quot=
e">}<br><br></div><div class=3D"gmail_quote">in this case, the actual x ran=
ge is dependent on elements that exists within the function, so, if I the c=
aller wants the loop to do something for all x in the range, he just passes=
 nullopt. That works because any x is &gt; nullopt<br>

</div><br><br><div class=3D"gmail_quote">Best<br><br></div>-- <br>Fernando =
Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-co=
nsulting.com">http://www.scisoft-consulting.com</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b6222d029a2c604d46ffab1--

.

On Tue, Jan 29, 2013 at 5:34 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> Now.. this is 15-year old code, so I took the time to follow the flow and
> indeed, it would only go through the second method where it just compares
> mInnerSide with cUp (which is a const int) if it passed first through the
> method that initialized mInnerSide.
>
> So I think there is use-pattern here: you will want to used mixd relops when
> you know, withn absolute certainty, that the optional, at that point, is
> engaged.

But then you might just as well dereference the optional and use normal relops.

>
> (3) Another:
>
> There is a function taking "optional<int> from"
>
> and there is loop inside, over a range of x coordinates, and it reads:
>
> if ( x > from )
> {
>  do something.
> }
>
> in this case, the actual x range is dependent on elements that exists within
> the function, so, if I the caller wants the loop to do something for all x
> in the range, he just passes nullopt. That works because any x is > nullopt

Sounds dangerous. What if instead of from you'd use to?
Then if (x < to) with !to the condition would always be false, while
it should've looped over all elements, right?

--
Olaf

--

---
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/?hl=en.



.

On Tue, Jan 29, 2013 at 4:44 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
 wrote:
> W dniu wtorek, 29 stycznia 2013 05:46:05 UTC+1 u=BFytkownik Tony V E napi=
sa=B3:
>>
>> We (if we so choose) could have some of NaN's "philosophy" without the
>> arguably bad parts:
>>
>> NaN says they are not comparable, thus return false.
>> We could say they are not comparable, thus don't compile.
>
>
> Ok, now I start to understand where you and Vladimir are getting to:
>
> optional<int> computation(); // where the result may be non-existent
>
> auto result =3D computation();
>
> if (result < 17) {} // error: did you consider nullopt?
>
> if (less_with_nullopt(result, 17)) {} // ok: you know what you are doing
>
> if (*result < 17) {} // ok, although risky.
>
> Did i get it right?
>
> --

Yes.  Basically, the C language made NaN logically correct the best
way they could with what they had to work with.  We can do better.

--=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/?hl=3Den.



.

On Tue, Jan 29, 2013 at 7:08 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
 wrote:
>
>
> W dniu wtorek, 29 stycznia 2013 12:44:27 UTC+1 u=BFytkownik Olaf van der =
Spek
> napisa=B3:
>>
>> On Tue, Jan 29, 2013 at 12:36 PM, Andrzej Krzemie=F1ski
>> <akrz...@gmail.com> wrote:
>> > The only rationale I have for (homogenous) relops is associative
>> > containers.
>> > I do not even need sorting for purposes other than storage in
>> > associative
>> > containers.
>>
>> You could define std::less but not operator< for that.
>
>
> You are proposing this because you think std::less is about ordering and
> operator< is for something else than ordering. Am I right? But is operato=
r<
> about anything else than ordering?
>
>> > This is for operator<. For operator=3D=3D, this is to make the type re=
gular.
>>
>> What's the use case for that?
>
>
> Good question. I take making all value-semantic types regular for granted=
..

Correct! Keep it up! :-)

--=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/?hl=3Den.



.

On Tue, Jan 29, 2013 at 9:45 AM, Matias Capeletto
<matias.capeletto@gmail.com> wrote:
>
> The LibreOffice code base seems to use Boost.Optional all over the
> place. Some examples can be extracted from that base, looking at the
> things devs needed to do to make their code 'clean'.
>
>
>   // clamp repeats to max permissible value (maRepeats.getValue() - 1.0)
>   if( isRepeatCountValid() && nRepeats >= getRepeatCount() ) {
>     ...
>   }
>
> They made two functions: isRepeatCountValid() { return maRepeats; }
> and getRepeatCount() { return *maRepeats; }, but the example still
> stands.
> So here they are using:
>
>     if( maRepeats && nRepeats >= *maRepeats )
>
> This could have been written like:
>
>     if( less_or( maRepeats, nRepeats, false ) )


Maybe a matter of taste, but I like their versions better than either
of the alternatives.  Clear, easy to understand.

Tony

--

---
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/?hl=en.



.

On Tue, Jan 29, 2013 at 5:04 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>
> My "problem: is somewhat different. There are two ways of being very
> explicit.
>
> // Version 1:
> return less_or(o, v, true);
> return less_or(o, v, false);
>
> // Version 2:
> return less_with_nullopt_least(o, v);
> return less_with_nullopt_greatest(o, v);
>

Also, note how param-order is affected differently:

Imagine original code:
    return less_or(o, v, true);

Then you realize you need to switch the compare, so switch o and v:
    return less_or(v, o, true);
or
    return less_or(v, o, false);

With Version 2 (with slightly different syntax):
Original:
    return opt_less(o, v, nullopt_least);

realize you need to switch the compare:
    return opt_less(o, v, nullopt_least);


It really is about whether you are thinking about a single comparison,
or a proper ordering.

I actually prefer things like

    opt && *opt < val

to any of the above.

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/?hl=3Den.



.

On Tue, Jan 29, 2013 at 6:09 AM, Olaf van der Spek <olafvdspek@gmail.com> w=
rote:
> On Monday, January 28, 2013 11:58:17 PM UTC+1, Andrzej Krzemie=C5=84ski w=
rote:
>>
>> I needed to say this in a new thread as the other one was getting too
>> crowded.
>
>
> What are the use cases for normal relops? Containers and sorting?
>
> Normal relops compare apples + oranges to apples + oranges which seems ki=
nda
> unsound too.
>

Comparing (apples + oranges) to (apples + oranges) is like comparing
apples to apples.  Perfectly fine.

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/?hl=3Den.



.

On Tue, Jan 29, 2013 at 6:05 PM, Tony V E <tvaneerd@gmail.com> wrote:
> On Tue, Jan 29, 2013 at 5:04 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail=
..com> wrote:
>> // Version 1:
>> return less_or(o, v, true);
>> return less_or(o, v, false);
>
> It really is about whether you are thinking about a single comparison,
> or a proper ordering.

Yes, this is very important. And IMO there is no need for a proper
ordering in most of the cases where you use optionals to control your
code logic.

> I actually prefer things like
>
>     opt && *opt < val
>
> to any of the above.

Fair enough. It actually looks good when 'opt' is already defined. But
it is not very composable. If you are getting your optional as the
result of some calculation then you need to write code like:

  auto opt =3D calcOptVal() ;
  if( opt && *opt < val ) {
    ...
  }

instead of

  if( less_or( calcOptVal(), val, false ) ) {
    ...
  }

Best regards
Matias

--=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/?hl=3Den.



.

------=_Part_350_13235825.1359479889673
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, January 29, 2013 9:42:28 AM UTC-6, Matias Capeletto wrote:

> On Tue, Jan 29, 2013 at 4:29 PM,  <cart...@gmail.com <javascript:>>
> wrote:
> > I cannot imagine a use case where a programmer would ever pass a
> non-literal
> > for the third parameter of less_or(), in which case it may be clearer to
> > specify it as :
> >
> >   template <bool NullValue, typename T>
> >   bool less_or(const optional<T>&o, const T& v)
> >   {return o ? *o < v : NullValue; }
> >
> > so that uses read as "less_or<true>(o, t)" / "less_or<false>(o, t)"
> which I
> > think is more readable.
>
> An interesting idea, but I posted an example yesterday in another
> thread where I needed an expression. Here it goes again:
>
>   void user_resize( double sx, optional<double> sy ) {
>     if( sx < 0 || less_or(sy, 0, sx<0) ) {
>       // Handle mirror special case
>     }
>     lib_resize(sx,sy);
>   }
>

That conditional is equivalent to ( sx < 0 || less_or(sy, 0, false) ),
since the second subexpression will only be evaluated when the first
subexpression (sx < 0) is false.

--

---
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/?hl=en.



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

On Tuesday, January 29, 2013 9:42:28 AM UTC-6, Matias Capeletto wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Jan 29, 2013 at 4:29 PM=
, &nbsp;&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"CBWQtir6B90J">cart...@gmail.com</a>&gt; wrote:
<br>&gt; I cannot imagine a use case where a programmer would ever pass a n=
on-literal
<br>&gt; for the third parameter of less_or(), in which case it may be clea=
rer to
<br>&gt; specify it as :
<br>&gt;
<br>&gt; &nbsp; template &lt;bool NullValue, typename T&gt;
<br>&gt; &nbsp; bool less_or(const optional&lt;T&gt;&amp;o, const T&amp; v)
<br>&gt; &nbsp; {return o ? *o &lt; v : NullValue; }
<br>&gt;
<br>&gt; so that uses read as "less_or&lt;true&gt;(o, t)" / "less_or&lt;fal=
se&gt;(o, t)" which I
<br>&gt; think is more readable.
<br>
<br>An interesting idea, but I posted an example yesterday in another
<br>thread where I needed an expression. Here it goes again:
<br>
<br>&nbsp; void user_resize( double sx, optional&lt;double&gt; sy ) {
<br>&nbsp; &nbsp; if( sx &lt; 0 || less_or(sy, 0, sx&lt;0) ) {
<br>&nbsp; &nbsp; &nbsp; // Handle mirror special case
<br>&nbsp; &nbsp; }
<br>&nbsp; &nbsp; lib_resize(sx,sy);
<br>&nbsp; }
<br></blockquote><div><br></div><div>That conditional is equivalent to ( sx=
 &lt; 0 || less_or(sy, 0, false) ), since the second subexpression will onl=
y be evaluated when the first subexpression (sx &lt; 0) is false.</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_350_13235825.1359479889673--

.

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

On Tue, Jan 29, 2013 at 2:41 PM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> On Tue, Jan 29, 2013 at 5:34 PM, Fernando Cacciola
> <fernando.cacciola@gmail.com> wrote:
> > Now.. this is 15-year old code, so I took the time to follow the flow and
> > indeed, it would only go through the second method where it just compares
> > mInnerSide with cUp (which is a const int) if it passed first through the
> > method that initialized mInnerSide.
> >
> > So I think there is use-pattern here: you will want to used mixd relops
> when
> > you know, withn absolute certainty, that the optional, at that point, is
> > engaged.
>
> But then you might just as well dereference the optional and use normal
> relops.
>
> I agree I could.


> >
> > (3) Another:
> >
> > There is a function taking "optional<int> from"
> >
> > and there is loop inside, over a range of x coordinates, and it reads:
> >
> > if ( x > from )
> > {
> >  do something.
> > }
> >
> > in this case, the actual x range is dependent on elements that exists
> within
> > the function, so, if I the caller wants the loop to do something for all
> x
> > in the range, he just passes nullopt. That works because any x is >
> nullopt
>
> Sounds dangerous. What if instead of from you'd use to?
> Then if (x < to) with !to the condition would always be false, while
> it should've looped over all elements, right?
>
>
Yes, but that is not a "problem" with mixed relops. If anything, is a
problem with 'less' applied to optionals, mixed or not.

There is no doubt that operator < might not suit your needs (you might want
nullopt to be the greatest), but that's a different point. I still don't
see why we need to remove a feature that can be legitimately used in code
just because it might be misused.

I've shown real use cases and you could argue that I could have written
that differently, but I think is not our job to force our users to write
their code this or that way. IMHO, that code is legit and I don't see why
will I want to prevent that from ever being written.

>
Best

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jan 29, 2013 at 2:41 PM, Olaf van der Spek <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a=
>&gt;</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 class=3D"im">On Tue, Jan 29, 2013 at 5:=
34 PM, Fernando Cacciola<br>
&lt;<a href=3D"mailto:fernando.cacciola@gmail.com">fernando.cacciola@gmail.=
com</a>&gt; wrote:<br>
&gt; Now.. this is 15-year old code, so I took the time to follow the flow =
and<br>
&gt; indeed, it would only go through the second method where it just compa=
res<br>
&gt; mInnerSide with cUp (which is a const int) if it passed first through =
the<br>
&gt; method that initialized mInnerSide.<br>
&gt;<br>
&gt; So I think there is use-pattern here: you will want to used mixd relop=
s when<br>
&gt; you know, withn absolute certainty, that the optional, at that point, =
is<br>
&gt; engaged.<br>
<br>
</div>But then you might just as well dereference the optional and use norm=
al relops.<br>
<div class=3D"im"><br></div></blockquote><div>I agree I could.<br>=A0<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div class=3D"im">
&gt;<br>
&gt; (3) Another:<br>
&gt;<br>
&gt; There is a function taking &quot;optional&lt;int&gt; from&quot;<br>
&gt;<br>
&gt; and there is loop inside, over a range of x coordinates, and it reads:=
<br>
&gt;<br>
&gt; if ( x &gt; from )<br>
&gt; {<br>
&gt; =A0do something.<br>
&gt; }<br>
&gt;<br>
&gt; in this case, the actual x range is dependent on elements that exists =
within<br>
&gt; the function, so, if I the caller wants the loop to do something for a=
ll x<br>
&gt; in the range, he just passes nullopt. That works because any x is &gt;=
 nullopt<br>
<br>
</div>Sounds dangerous. What if instead of from you&#39;d use to?<br>
Then if (x &lt; to) with !to the condition would always be false, while<br>
it should&#39;ve looped over all elements, right?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div class=3D"h5">Yes, but that is not a &quot;problem&qu=
ot; with mixed relops. If anything, is a problem with &#39;less&#39; applie=
d to optionals, mixed or not.<br>

<br>
</div><div class=3D"h5">There is no doubt that operator &lt; might not suit=
 your needs (you might want nullopt to be the greatest), but that&#39;s a d=
ifferent point. I still don&#39;t see why we need to remove a feature that =
can be legitimately used in code just because it might be misused.<br>

<br></div><div class=3D"h5">I&#39;ve shown real use cases and you could arg=
ue that I could have written that differently, but I think is not our job t=
o force our users to write their code this or that way. IMHO, that code is =
legit and I don&#39;t see why will I want to prevent that from ever being w=
ritten.<br>


</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"></blockquote></div><br></div><div clas=
s=3D"gmail_extra">Best<br clear=3D"all"></div><div class=3D"gmail_extra"><b=
r>-- <br>

Fernando Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.s=
cisoft-consulting.com">http://www.scisoft-consulting.com</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--14dae93999395d68da04d470bb83--

.

On Tue, Jan 29, 2013 at 6:18 PM,  <cartec69@gmail.com> wrote:
> On Tuesday, January 29, 2013 9:42:28 AM UTC-6, Matias Capeletto wrote:
>>     if( sx < 0 || less_or(sy, 0, sx<0) ) {
>
> That conditional is equivalent to ( sx < 0 || less_or(sy, 0, false) ), since
> the second subexpression will only be evaluated when the first subexpression
> (sx < 0) is false.

Good catch. But it is also equivalent to:

  if( less_or( sy, 0, sx<0 ) ) { ... }

:)

--

---
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/?hl=en.



.

On Tue, Jan 29, 2013 at 6:28 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
>> Sounds dangerous. What if instead of from you'd use to?
>> Then if (x < to) with !to the condition would always be false, while
>> it should've looped over all elements, right?
>>
>
> Yes, but that is not a "problem" with mixed relops. If anything, is a
> problem with 'less' applied to optionals, mixed or not.

Hence my suggestion to remove relops. ;)

> There is no doubt that operator < might not suit your needs (you might want
> nullopt to be the greatest), but that's a different point. I still don't see
> why we need to remove a feature that can be legitimately used in code just
> because it might be misused.
>
> I've shown real use cases and you could argue that I could have written that
> differently, but I think is not our job to force our users to write their
> code this or that way. IMHO, that code is legit and I don't see why will I
> want to prevent that from ever being written.

The point is that two of the three use cases you posted are problematic.
And that being explicit (checking both the engaged state and the
value) is not hard and avoids all these issues.


--
Olaf

--

---
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/?hl=en.



.

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

On Tue, Jan 29, 2013 at 2:54 PM, Tony V E <tvaneerd@gmail.com> wrote:

> On Tue, Jan 29, 2013 at 9:45 AM, Matias Capeletto
> <matias.capeletto@gmail.com> wrote:
> >
> > The LibreOffice code base seems to use Boost.Optional all over the
> > place. Some examples can be extracted from that base, looking at the
> > things devs needed to do to make their code 'clean'.
> >
> >
> >   // clamp repeats to max permissible value (maRepeats.getValue() - 1.0)
> >   if( isRepeatCountValid() && nRepeats >= getRepeatCount() ) {
> >     ...
> >   }
> >
> > They made two functions: isRepeatCountValid() { return maRepeats; }
> > and getRepeatCount() { return *maRepeats; }, but the example still
> > stands.
> > So here they are using:
> >
> >     if( maRepeats && nRepeats >= *maRepeats )
> >
> > This could have been written like:
> >
> >     if( less_or( maRepeats, nRepeats, false ) )
>
>
> Maybe a matter of taste, but I like their versions better than either
> of the alternatives.  Clear, easy to understand.
>
>
And perhaps I do as well, but that's not central to the point under
discussion.

Which is, do we allow users to use mixed relops or we forbid that. IMO, in
order to forbid it there must be much more than taste, good style, etc... I
would only forbid it provided there are *significant reasons* to consider
that it will be a source of subtle bugs. I would not forbid it on the
grounds that you can use alternative expressions.

For the case at hand, I don't see anything near significant reasons to
believe it will be a source of bugs
..
Best
<http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en>

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jan 29, 2013 at 2:54 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</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 class=3D"im">On Tue, Jan 29, 2013 at 9:=
45 AM, Matias Capeletto<br>
&lt;<a href=3D"mailto:matias.capeletto@gmail.com">matias.capeletto@gmail.co=
m</a>&gt; wrote:<br>
&gt;<br>
&gt; The LibreOffice code base seems to use Boost.Optional all over the<br>
&gt; place. Some examples can be extracted from that base, looking at the<b=
r>
&gt; things devs needed to do to make their code &#39;clean&#39;.<br>
&gt;<br>
&gt;<br>
</div><div class=3D"im">&gt; =A0 // clamp repeats to max permissible value =
(maRepeats.getValue() - 1.0)<br>
&gt; =A0 if( isRepeatCountValid() &amp;&amp; nRepeats &gt;=3D getRepeatCoun=
t() ) {<br>
&gt; =A0 =A0 ...<br>
&gt; =A0 }<br>
&gt;<br>
&gt; They made two functions: isRepeatCountValid() { return maRepeats; }<br=
>
&gt; and getRepeatCount() { return *maRepeats; }, but the example still<br>
&gt; stands.<br>
&gt; So here they are using:<br>
&gt;<br>
&gt; =A0 =A0 if( maRepeats &amp;&amp; nRepeats &gt;=3D *maRepeats )<br>
&gt;<br>
&gt; This could have been written like:<br>
&gt;<br>
&gt; =A0 =A0 if( less_or( maRepeats, nRepeats, false ) )<br>
<br>
<br>
</div>Maybe a matter of taste, but I like their versions better than either=
<br>
of the alternatives. =A0Clear, easy to understand.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>And perhaps I do as well, but that&#39;s not central=
 to the point under discussion.<br><br></div><div>Which is, do we allow use=
rs to use mixed relops or we forbid that. IMO, in order to forbid it there =
must be much more than taste, good style, etc... I would only forbid it pro=
vided there are *significant reasons* to consider that it will be a source =
of subtle bugs. I would not forbid it on the grounds that you can use alter=
native expressions.<br>

<br></div><div>For the case at hand, I don&#39;t see anything near signific=
ant reasons to believe it will be a source of bugs<br>.<br>Best</div><a hre=
f=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=3Den" ta=
rget=3D"_blank"></a></div>

<br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"h=
ttp://www.scisoft-consulting.com">http://www.scisoft-consulting.com</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--bcaec54d4766c40db804d470cf56--

.

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

On Tue, Jan 29, 2013 at 3:32 PM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> On Tue, Jan 29, 2013 at 6:28 PM, Fernando Cacciola
> <fernando.cacciola@gmail.com> wrote:
> >> Sounds dangerous. What if instead of from you'd use to?
> >> Then if (x < to) with !to the condition would always be false, while
> >> it should've looped over all elements, right?
> >>
> >
> > Yes, but that is not a "problem" with mixed relops. If anything, is a
> > problem with 'less' applied to optionals, mixed or not.
>
> Hence my suggestion to remove relops. ;)
>
> OK, but that's a completely different story.
Perhaps a new thread.


>  > There is no doubt that operator < might not suit your needs (you might
> want
> > nullopt to be the greatest), but that's a different point. I still don't
> see
> > why we need to remove a feature that can be legitimately used in code
> just
> > because it might be misused.
> >
> > I've shown real use cases and you could argue that I could have written
> that
> > differently, but I think is not our job to force our users to write their
> > code this or that way. IMHO, that code is legit and I don't see why will
> I
> > want to prevent that from ever being written.
>
> The point is that two of the three use cases you posted are problematic.
> And that being explicit (checking both the engaged state and the
> value) is not hard and avoids all these issues.
>
> Wait.
The first is not problematic at all. You just shown that I could have
written it differently, but none of the "versions" is more or less
problematic (in fact, it isn't problematic at all)


The second "problem" is about the fixed, implicit ordering imposed by any
given operator or function that forces an arbitrary definition of such
ordering.

But if we are going to go down that road, notice that this is a problem
with < and >, mixed or not, and is not a problem with == and !=

Usages of == and != are *exceedingly* much more common than usages of <. It
would be a design mistake, IMO, if we would to get rid of ==/!= because of
the (real or perceived) problems with < and >

So, at the very least, we should separate the subjects of the discussion.

Best

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jan 29, 2013 at 3:32 PM, Olaf van der Spek <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a=
>&gt;</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 class=3D"im">On Tue, Jan 29, 2013 at 6:=
28 PM, Fernando Cacciola<br>
&lt;<a href=3D"mailto:fernando.cacciola@gmail.com">fernando.cacciola@gmail.=
com</a>&gt; wrote:<br>
&gt;&gt; Sounds dangerous. What if instead of from you&#39;d use to?<br>
&gt;&gt; Then if (x &lt; to) with !to the condition would always be false, =
while<br>
&gt;&gt; it should&#39;ve looped over all elements, right?<br>
&gt;&gt;<br>
&gt;<br>
&gt; Yes, but that is not a &quot;problem&quot; with mixed relops. If anyth=
ing, is a<br>
&gt; problem with &#39;less&#39; applied to optionals, mixed or not.<br>
<br>
</div>Hence my suggestion to remove relops. ;)<br>
<div class=3D"im"><br></div></blockquote><div>OK, but that&#39;s a complete=
ly different story.<br></div><div>Perhaps a new thread.<br>=A0<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">

<div class=3D"im">
&gt; There is no doubt that operator &lt; might not suit your needs (you mi=
ght want<br>
&gt; nullopt to be the greatest), but that&#39;s a different point. I still=
 don&#39;t see<br>
&gt; why we need to remove a feature that can be legitimately used in code =
just<br>
&gt; because it might be misused.<br>
&gt;<br>
&gt; I&#39;ve shown real use cases and you could argue that I could have wr=
itten that<br>
&gt; differently, but I think is not our job to force our users to write th=
eir<br>
&gt; code this or that way. IMHO, that code is legit and I don&#39;t see wh=
y will I<br>
&gt; want to prevent that from ever being written.<br>
<br>
</div>The point is that two of the three use cases you posted are problemat=
ic.<br>
And that being explicit (checking both the engaged state and the<br>
value) is not hard and avoids all these issues.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div>W=
ait.<br></div><div>The first is not problematic at all. You just shown that=
 I could have written it differently, but none of the &quot;versions&quot; =
is more or less problematic (in fact, it isn&#39;t problematic at all)<br>

<br><br></div><div class=3D"h5">The second &quot;problem&quot; is about the=
 fixed, implicit ordering imposed by any given operator or function that fo=
rces an arbitrary definition of such ordering.<br></div><div class=3D"h5">
<br>
But if we are going to go down that road, notice that this is a problem wit=
h &lt; and &gt;, mixed or not, and is not a problem with =3D=3D and !=3D<br=
><br></div><div class=3D"h5">Usages of =3D=3D and !=3D are *exceedingly* mu=
ch more common than usages of &lt;. It would be a design mistake, IMO, if w=
e would to get rid of =3D=3D/!=3D because of the (real or perceived) proble=
ms with &lt; and &gt;<br>

<br></div><div class=3D"h5">So, at the very least, we should separate the s=
ubjects of the discussion.<br></div><br></div>Best<br></div><div class=3D"g=
mail_extra"><br clear=3D"all">-- <br>Fernando Cacciola<br>SciSoft Consultin=
g, Founder<br>

<a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting=
..com</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--f46d0444eb77a1b87004d470f237--

.

On Tue, Jan 29, 2013 at 6:43 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
>> The point is that two of the three use cases you posted are problematic.
>> And that being explicit (checking both the engaged state and the
>> value) is not hard and avoids all these issues.
>>
> Wait.
> The first is not problematic at all. You just shown that I could have
> written it differently, but none of the "versions" is more or less
> problematic (in fact, it isn't problematic at all)

It's problematic because if the optional isn't engaged (for whatever
reason), you silently take the wrong branch.
If operator* would've been used, an assert would've detected that.

>
> The second "problem" is about the fixed, implicit ordering imposed by any
> given operator or function that forces an arbitrary definition of such
> ordering.
>
> But if we are going to go down that road, notice that this is a problem with
> < and >, mixed or not, and is not a problem with == and !=
>
> Usages of == and != are *exceedingly* much more common than usages of <. It
> would be a design mistake, IMO, if we would to get rid of ==/!= because of
> the (real or perceived) problems with < and >

True, maybe :p

== and != might run into your case 2 issue too.

--
Olaf

--

---
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/?hl=en.



.

------=_Part_514_29638713.1359493655650
Content-Type: text/plain; charset=ISO-8859-1



>
>> Maybe a matter of taste, but I like their versions better than either
>> of the alternatives.  Clear, easy to understand.
>>
>>
> And perhaps I do as well, but that's not central to the point under
> discussion.
>
> Which is, do we allow users to use mixed relops or we forbid that. IMO, in
> order to forbid it there must be much more than taste, good style, etc... I
> would only forbid it provided there are *significant reasons* to consider
> that it will be a source of subtle bugs. I would not forbid it on the
> grounds that you can use alternative expressions.
>
> For the case at hand, I don't see anything near significant reasons to
> believe it will be a source of bugs
>

Why do we allow certain features and interfaces and do not allow other? I
believe the criterion for adding a feature is that the feature provides
more benefits than it causes troubles. That is, there are two sides to be
considered not only perils but also benefits. In case of mixed relops, they
may not be particularly harmful, but on the other hand, they do not offer
much value either. This is I guess what Olaf meant. Not being a great peril
is insufficient to remove a feature; but one could state it in a different
way: a feature that is not particularly useful is not worth adding.

Why is optional<T> not implicitly convertible to T? There are obviously
some technical problems (e.g., what would such conversion do for
optional<bool>), but if they were magically overcome would we offer such
conversion or not? I believe not, because it is one of the safety features
of optional, that you have to explicitly ask for the contained value,
otherwise compiler can warn you about the omission. This is already an
implementation of an "improved NaN". The only exception to this safety rule
is mixed relops. This is the only case where we suspend this "improved NaN"
feature. "Improved NaN" is a feature, and by keeping mixed relops, we would
be compromising this feature (by providing a different one). The way I see
it, it is a trade-off between two features. We could try to weigh them
somehow, although this may be too personal.

Can I think of some arguments that are objective? Mixed relops are used
rarely, compared to other parts of the interface. Perhaps using the
not-immediately-obvious operator to handle rare use cases is encouraging
misuses. It is different for operator*, because users have to learn it the
first day. They may never have time to read the entire manual, and when
they see it in the code, they will mistakenly take it for T < T. So the
argument here would be "tricky meaning for rare cases". Perhaps a
descriptive name instead of operators would provide a better trade-off
between safety and usability.

Anyway, I do not expect I can convince anybody with this argument. At least
I am now better able to explain my position. It is not "refactoring safety"
anymore. It is "improved NaN" feature.

Regards,
&rzej

--

---
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/?hl=en.



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

<br><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"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
</div>Maybe a matter of taste, but I like their versions better than either=
<br>
of the alternatives. &nbsp;Clear, easy to understand.<br>
<span><font color=3D"#888888"><br></font></span></blockquote><div><br></div=
><div>And perhaps I do as well, but that's not central to the point under d=
iscussion.<br><br></div><div>Which is, do we allow users to use mixed relop=
s or we forbid that. IMO, in order to forbid it there must be much more tha=
n taste, good style, etc... I would only forbid it provided there are *sign=
ificant reasons* to consider that it will be a source of subtle bugs. I wou=
ld not forbid it on the grounds that you can use alternative expressions.<b=
r>

<br></div><div>For the case at hand, I don't see anything near significant =
reasons to believe it will be a source of bugs</div></div></div></div></blo=
ckquote><div><br>Why do we allow certain features and interfaces and do not=
 allow other? I believe the criterion for adding a feature is that the feat=
ure provides more benefits than it causes troubles. That is, there are two =
sides to be considered not only perils but also benefits. In case of mixed =
relops, they may not be particularly harmful, but on the other hand, they d=
o not offer much value either. This is I guess what Olaf meant. Not being a=
 great peril is insufficient to remove a feature; but one could state it in=
 a different way: a feature that is not particularly useful is not worth ad=
ding. <br><br>Why is optional&lt;T&gt; not implicitly convertible to T? The=
re are obviously some technical problems (e.g., what would such conversion =
do for optional&lt;bool&gt;), but if they were magically overcome would we =
offer such conversion or not? I believe not, because it is one of the safet=
y features of optional, that you have to explicitly ask for the contained v=
alue, otherwise compiler can warn you about the omission. This is already a=
n implementation of an "improved NaN". The only exception to this safety ru=
le is mixed relops. This is the only case where we suspend this  "improved =
NaN" feature.  "Improved NaN" is a feature, and by keeping mixed relops, we=
 would be compromising this feature (by providing a different one). The way=
 I see it, it is a trade-off between two features. We could try to weigh th=
em somehow, although this may be too personal.<br><br>Can I think of some a=
rguments that are objective? Mixed relops are used rarely, compared to othe=
r parts of the interface. Perhaps using the not-immediately-obvious operato=
r to handle rare use cases is encouraging misuses. It is different for oper=
ator*, because users have to learn it the first day. They may never have ti=
me to read the entire manual, and when they see it in the code, they will m=
istakenly take it for T &lt; T. So the argument here would be "tricky meani=
ng for rare cases". Perhaps a descriptive name instead of operators would p=
rovide a better trade-off between safety and usability.<br><br>Anyway, I do=
 not expect I can convince anybody with this argument. At least I am now be=
tter able to explain my position. It is not "refactoring safety" anymore. I=
t is "improved NaN" feature.<br><br>Regards,<br>&amp;rzej<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_514_29638713.1359493655650--

.

On Wed, Jan 30, 2013 at 4:28 AM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Tue, Jan 29, 2013 at 2:41 PM, Olaf van der Spek <olafvdspek@gmail.com>
> wrote:
>> On Tue, Jan 29, 2013 at 5:34 PM, Fernando Cacciola
>> <fernando.cacciola@gmail.com> wrote:
>> ...
>> Sounds dangerous. What if instead of from you'd use to?
>> Then if (x < to) with !to the condition would always be false, while
>> it should've looped over all elements, right?
>
> Yes, but that is not a "problem" with mixed relops. If anything, is a
> problem with 'less' applied to optionals, mixed or not.
> There is no doubt that operator < might not suit your needs (you might want
> nullopt to be the greatest), but that's a different point. I still don't see
> why we need to remove a feature that can be legitimately used in code just
> because it might be misused.

By no stretch this "problem" of 'optional' providing
optional::operator<(optional) (the default ordering) can be a problem.
Many types provide default ordering and ass. containers take full
advantage of those. Optional is an envelope/proxy/extending class. So,
for it *not* to honor ordering provided by the underlying class is IMO
unthinkable. As for 'optional's choice of "no-value < any-value" for
the default ordering, then it is indeed arbitrary but it's entirely
within optional developer's right to make that choice. That ordering
is chosen based on the expectation that that ordering will
satisfy/suit the majority of users. Those who are not happy with the
default ordering are always free to supply their own. The situation is
no different from any other class.

> I've shown real use cases and you could argue that I could have written that
> differently, but I think is not our job to force our users to write their
> code this or that way. IMHO, that code is legit and I don't see why will I
> want to prevent that from ever being written.

Indeed.

--

---
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/?hl=en.



.

On Wed, Jan 30, 2013 at 8:07 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
> ...
> Why do we allow certain features and interfaces and do not allow other? I
> believe the criterion for adding a feature is that the feature provides m=
ore
> benefits than it causes troubles. That is, there are two sides to be
> considered not only perils but also benefits. In case of mixed relops, th=
ey
> may not be particularly harmful, but on the other hand, they do not offer
> much value either. This is I guess what Olaf meant. Not being a great per=
il
> is insufficient to remove a feature; but one could state it in a differen=
t
> way: a feature that is not particularly useful is not worth adding.

I might add "a feature that can be done by conventional/already
available means is not worth adding".

> Why is optional<T> not implicitly convertible to T? There are obviously s=
ome
> technical problems (e.g., what would such conversion do for optional<bool=
>),
> but if they were magically overcome would we offer such conversion or not=
? I
> believe not, because it is one of the safety features of optional, that y=
ou
> have to explicitly ask for the contained value, otherwise compiler can wa=
rn
> you about the omission. This is already an implementation of an "improved
> NaN". The only exception to this safety rule is mixed relops. This is the
> only case where we suspend this "improved NaN" feature. "Improved NaN" is=
 a
> feature, and by keeping mixed relops, we would be compromising this featu=
re
> (by providing a different one). The way I see it, it is a trade-off betwe=
en
> two features. We could try to weigh them somehow, although this may be to=
o
> personal.
>
> Can I think of some arguments that are objective? Mixed relops are used
> rarely, compared to other parts of the interface. Perhaps using the
> not-immediately-obvious operator to handle rare use cases is encouraging
> misuses. It is different for operator*, because users have to learn it th=
e
> first day. They may never have time to read the entire manual, and when t=
hey
> see it in the code, they will mistakenly take it for T < T. So the argume=
nt
> here would be "tricky meaning for rare cases". Perhaps a descriptive name
> instead of operators would provide a better trade-off between safety and
> usability.
>
> Anyway, I do not expect I can convince anybody with this argument. At lea=
st
> I am now better able to explain my position. It is not "refactoring safet=
y"
> anymore. It is "improved NaN" feature.

Overwhelmingly I agree with your position. I see disengaged optional
as an "improved NaN" and I do feel that "opt < 5" can be easily
interpreted as "int < int" rather than "optional < optional". My only
hesitation (again, it's a hesitation rather than a strong objection)
against prohibiting mixed relops is based on the fact that I feel
"homogeneous" relops are essential for 'optional'. Therefore, I feel
that "op < optional<int>(5)" needs to be supported. And from that
there is only a tiny step to "op < 5" (as long as it means the same as
"op < optional<int>(5)") which can probably be supported by the
performance/optimization argument.

Yes, my preference as a *reader* would be the explicit and somewhat
lengthy but unambiguous "opt && *opt < 5" (value comparison) or "op <
optional<int>(5)" (opt comparison). However, as an
efficiency-conscientious user I might want "*opt < 5" (value
comparison) or "opt < 5" (opt comparison) as optional<int>(5)
construction might be expensive. Subtle? Yes. Still, it won't the only
subtle place in C++ and the std library. Surely, as far as C++ goes,
if one is determined to shoot himself in the foot, he'll succeed it no
matter what.

--=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/?hl=3Den.



.

On Tue, Jan 29, 2013 at 10:07 PM, Andrzej Krzemie=F1ski
<akrzemi1@gmail.com> wrote:
> Why is optional<T> not implicitly convertible to T? There are obviously s=
ome
> technical problems (e.g., what would such conversion do for optional<bool=
>),
> but if they were magically overcome would we offer such conversion or not=
? I
> believe not, because it is one of the safety features of optional, that y=
ou
> have to explicitly ask for the contained value, otherwise compiler can wa=
rn
> you about the omission. This is already an implementation of an "improved
> NaN". The only exception to this safety rule is mixed relops. This is the
> only case where we suspend this "improved NaN" feature. "Improved NaN" is=
 a
> feature, and by keeping mixed relops, we would be compromising this featu=
re
> (by providing a different one). The way I see it, it is a trade-off betwe=
en
> two features. We could try to weigh them somehow, although this may be to=
o
> personal.

I think that stating this in these terms is a great progress in the discuss=
ion.

> Anyway, I do not expect I can convince anybody with this argument. At lea=
st
> I am now better able to explain my position. It is not "refactoring safet=
y"
> anymore. It is "improved NaN" feature.

+1, I am also starting to think that mixed rel ops are better left
aside from the proposal. In the case users end up screaming for them
later, we can review the decision.

--=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/?hl=3Den.



.

Le 29/01/13 18:07, Tony V E a =C3=A9crit :
> On Tue, Jan 29, 2013 at 6:09 AM, Olaf van der Spek <olafvdspek@gmail.com>=
 wrote:
>> On Monday, January 28, 2013 11:58:17 PM UTC+1, Andrzej Krzemie=C5=84ski =
wrote:
>>> I needed to say this in a new thread as the other one was getting too
>>> crowded.
>>
>> What are the use cases for normal relops? Containers and sorting?
>>
>> Normal relops compare apples + oranges to apples + oranges which seems k=
inda
>> unsound too.
>>
> Comparing (apples + oranges) to (apples + oranges) is like comparing
> apples to apples.  Perfectly fine.
>
>
Agree, but should I know how apples and oranges compare?

Vicente

--=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/?hl=3Den.



.

On Tue, Jan 29, 2013 at 10:33 PM, Vladimir Batov <vb.mail.247@gmail.com> wrote:
> Overwhelmingly I agree with your position. I see disengaged optional
> as an "improved NaN" and I do feel that "opt < 5" can be easily
> interpreted as "int < int" rather than "optional < optional". My only
> hesitation (again, it's a hesitation rather than a strong objection)
> against prohibiting mixed relops is based on the fact that I feel
> "homogeneous" relops are essential for 'optional'.

Great! Could you present us some use cases?
--
Olaf

--

---
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/?hl=en.



.

On Tue, Jan 29, 2013 at 4:43 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Tue, Jan 29, 2013 at 10:33 PM, Vladimir Batov <vb.mail.247@gmail.com> wrote:
>> Overwhelmingly I agree with your position. I see disengaged optional
>> as an "improved NaN" and I do feel that "opt < 5" can be easily
>> interpreted as "int < int" rather than "optional < optional". My only
>> hesitation (again, it's a hesitation rather than a strong objection)
>> against prohibiting mixed relops is based on the fact that I feel
>> "homogeneous" relops are essential for 'optional'.
>
> Great! Could you present us some use cases?

I think they are almost exclusively for use in map/set.  In which case
an override of std::less<> would be good enough.  Possibly even
better, as it doesn't imply that opt < opt was considered something
standard enough to standardize.

You could offer std::opt_least_less<> and std::opt_most_less<> and
have std::less<optional<T>> be one of those.

Tony

--

---
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/?hl=en.



.

On Tue, Jan 29, 2013 at 4:41 PM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Le 29/01/13 18:07, Tony V E a =E9crit :
>
>> On Tue, Jan 29, 2013 at 6:09 AM, Olaf van der Spek <olafvdspek@gmail.com=
>
>> wrote:
>>>
>>> On Monday, January 28, 2013 11:58:17 PM UTC+1, Andrzej Krzemie=F1ski wr=
ote:
>>>>
>>>> I needed to say this in a new thread as the other one was getting too
>>>> crowded.
>>>
>>>
>>> What are the use cases for normal relops? Containers and sorting?
>>>
>>> Normal relops compare apples + oranges to apples + oranges which seems
>>> kinda
>>> unsound too.
>>>
>> Comparing (apples + oranges) to (apples + oranges) is like comparing
>> apples to apples.  Perfectly fine.
>>
>>
> Agree, but should I know how apples and oranges compare?
>

"warning analogy integrity field weakening..."

If you want to buy those apples and oranges from the seller.  But it
is up to the vendor how they want to package them.

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/?hl=3Den.



.

On Tue, Jan 29, 2013 at 10:33 PM, Vladimir Batov <vb.mail.247@gmail.com> wrote:
> Yes, my preference as a *reader* would be the explicit and somewhat
> lengthy but unambiguous "opt && *opt < 5" (value comparison) or "op <
> optional<int>(5)" (opt comparison). However, as an
> efficiency-conscientious user I might want "*opt < 5" (value
> comparison) or

If you are certain that you have a value, because you checked before
or you just assign it then go for it.

> "opt < 5" (opt comparison) as optional<int>(5)
> construction might be expensive. Subtle? Yes. Still, it won't the only
> subtle place in C++ and the std library. Surely, as far as C++ goes,
> if one is determined to shoot himself in the foot, he'll succeed it no
> matter what.

The performance argument does not work if you compare (op<5) with
(op?*op<5:true).

As others are expressing, given an ordering to optionals seems to be
mainly useful in the context of containers. I also will like to see
examples where you will want to do [ op < optional<int>(5) ].

--

---
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/?hl=en.



.

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

On Tue, Jan 29, 2013 at 7:47 PM, Tony V E <tvaneerd@gmail.com> wrote:

> On Tue, Jan 29, 2013 at 4:43 PM, Olaf van der Spek <olafvdspek@gmail.com>
> wrote:
> > On Tue, Jan 29, 2013 at 10:33 PM, Vladimir Batov <vb.mail.247@gmail.com>
> wrote:
> >> Overwhelmingly I agree with your position. I see disengaged optional
> >> as an "improved NaN" and I do feel that "opt < 5" can be easily
> >> interpreted as "int < int" rather than "optional < optional". My only
> >> hesitation (again, it's a hesitation rather than a strong objection)
> >> against prohibiting mixed relops is based on the fact that I feel
> >> "homogeneous" relops are essential for 'optional'.
> >
> > Great! Could you present us some use cases?
>
> I think they


Please let's make sure to keep it clear that statements like that refer to
< and >
Not to == and !=

Like I recently said, I don't think discussing "relops" as if the 4 (basic)
ops belong to the same class makes sense given the arguments being
considered.

Best




--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jan 29, 2013 at 7:47 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</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 class=3D"im">On Tue, Jan 29, 2013 at 4:=
43 PM, Olaf van der Spek &lt;<a href=3D"mailto:olafvdspek@gmail.com">olafvd=
spek@gmail.com</a>&gt; wrote:<br>


&gt; On Tue, Jan 29, 2013 at 10:33 PM, Vladimir Batov &lt;<a href=3D"mailto=
:vb.mail.247@gmail.com">vb.mail.247@gmail.com</a>&gt; wrote:<br>
&gt;&gt; Overwhelmingly I agree with your position. I see disengaged option=
al<br>
&gt;&gt; as an &quot;improved NaN&quot; and I do feel that &quot;opt &lt; 5=
&quot; can be easily<br>
&gt;&gt; interpreted as &quot;int &lt; int&quot; rather than &quot;optional=
 &lt; optional&quot;. My only<br>
&gt;&gt; hesitation (again, it&#39;s a hesitation rather than a strong obje=
ction)<br>
&gt;&gt; against prohibiting mixed relops is based on the fact that I feel<=
br>
&gt;&gt; &quot;homogeneous&quot; relops are essential for &#39;optional&#39=
;.<br>
&gt;<br>
&gt; Great! Could you present us some use cases?<br>
<br>
</div>I think they </blockquote><div><br></div><div>Please let&#39;s make s=
ure to keep it clear that statements like that refer to &lt; and &gt;<br></=
div><div>Not to =3D=3D and !=3D<br><br></div><div>Like I recently said, I d=
on&#39;t think discussing &quot;relops&quot; as if the 4 (basic) ops belong=
 to the same class makes sense given the arguments being considered.<br>

<br></div><div>Best<br></div><br></div><br><br clear=3D"all"><br>-- <br>Fer=
nando Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scis=
oft-consulting.com">http://www.scisoft-consulting.com</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b66f51534100104d47474fd--

.

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

On Tue, Jan 29, 2013 at 7:07 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om>wrote:

>
>
>>> Maybe a matter of taste, but I like their versions better than either
>>> of the alternatives.  Clear, easy to understand.
>>>
>>>
>> And perhaps I do as well, but that's not central to the point under
>> discussion.
>>
>> Which is, do we allow users to use mixed relops or we forbid that. IMO,
>> in order to forbid it there must be much more than taste, good style,
>> etc... I would only forbid it provided there are *significant reasons* t=
o
>> consider that it will be a source of subtle bugs. I would not forbid it =
on
>> the grounds that you can use alternative expressions.
>>
>> For the case at hand, I don't see anything near significant reasons to
>> believe it will be a source of bugs
>>
>
> Why do we allow certain features and interfaces and do not allow other? I
> believe the criterion for adding a feature is that the feature provides
> more benefits than it causes troubles. That is, there are two sides to be
> considered not only perils but also benefits. In case of mixed relops, th=
ey
> may not be particularly harmful, but on the other hand, they do not offer
> much value either. This is I guess what Olaf meant. Not being a great per=
il
> is insufficient to remove a feature; but one could state it in a differen=
t
> way: a feature that is not particularly useful is not worth adding.
>
> Why is optional<T> not implicitly convertible to T?
>

Indeed the balance is in the actual amounts in the tradeoff.

Perhaps I was not clear but, naturally, some features can be regarded
unsafe and better left out. I'm not arguing that something like that cannot
be the case, I argue that is it, specifically, not the case of mixed relops=
..



> There are obviously some technical problems (e.g., what would such
> conversion do for optional<bool>), but if they were magically overcome
> would we offer such conversion or not? I believe not, because it is one o=
f
> the safety features of optional, that you have to explicitly ask for the
> contained value, otherwise compiler can warn you about the omission. This
> is already an implementation of an "improved NaN". The only exception to
> this safety rule is mixed relops. This is the only case where we suspend
> this "improved NaN" feature. "Improved NaN" is a feature, and by keeping
> mixed relops, we would be compromising this feature (by providing a
> different one). The way I see it, it is a trade-off between two features.
> We could try to weigh them somehow, although this may be too personal.
>
> Can I think of some arguments that are objective? Mixed relops are used
> rarely, compared to other parts of the interface.
>

Let me attempt to branch the discussion here.

*ordering* relops are used rarely.
*equality* relops are used quite often.

Having said that, let me add that IME, the usage of one or other kind of
relops is NOT significantly different in the homogeneous case vs the
heterogeneous case.

That is, *it is not* the case, again IME, that  "opt relop opt" is
significantly more common than "opt relop T"

I know that statement sets an unproven fact, but it is nonetheless a fact
that is totally fundamental for the current discussion.




> Perhaps using the not-immediately-obvious operator to handle rare use
> cases is encouraging misuses. It is different for operator*, because user=
s
> have to learn it the first day. They may never have time to read the enti=
re
> manual, and when they see it in the code, they will mistakenly take it fo=
r
> T < T. So the argument here would be "tricky meaning for rare cases".
> Perhaps a descriptive name instead of operators would provide a better
> trade-off between safety and usability.
>
> Anyway, I do not expect I can convince anybody with this argument. At
> least I am now better able to explain my position. It is not "refactoring
> safety" anymore. It is "improved NaN" feature.
>
>
OK, but, how is the improved NaN feature affected differently by *mixed*
relops as opposed to (homogeneous) relops ?

Still after all that has been said, I remain in the position that,

*provided* opt < opt is OK,  then so is opt < make_optional<t>, and then, I
still fail to see why opt < t would not be exactly equally OK.

The only argument I've got this far is that I might want the compiler to
forbid performing operations against different types. I would totally
subscribe to that, in another language, like in C# where you cannot, for
instance, even pass 1.2 to a function expecting a float, something that is
totally OK in C++.

IMHO, everything else that I've read so far is not *really* (again IMHO)
about mixing opts and T's in a comparison but about the comparisons
themselves. That is a totally valid discussion, but is an entirely
different one.

Best


--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=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/?hl=3Den.



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jan 29, 2013 at 7:07 PM, Andrzej Krzemie=C5=84ski <span dir=3D"ltr">&lt=
;<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com=
</a>&gt;</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 class=3D"im"><br><blockquote class=3D"g=
mail_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"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div>
<br>
</div>Maybe a matter of taste, but I like their versions better than either=
<br>
of the alternatives. =C2=A0Clear, easy to understand.<br>
<span><font color=3D"#888888"><br></font></span></blockquote><div><br></div=
><div>And perhaps I do as well, but that&#39;s not central to the point und=
er discussion.<br><br></div><div>Which is, do we allow users to use mixed r=
elops or we forbid that. IMO, in order to forbid it there must be much more=
 than taste, good style, etc... I would only forbid it provided there are *=
significant reasons* to consider that it will be a source of subtle bugs. I=
 would not forbid it on the grounds that you can use alternative expression=
s.<br>



<br></div><div>For the case at hand, I don&#39;t see anything near signific=
ant reasons to believe it will be a source of bugs</div></div></div></div><=
/blockquote></div><div><br>Why do we allow certain features and interfaces =
and do not allow other? I believe the criterion for adding a feature is tha=
t the feature provides more benefits than it causes troubles. That is, ther=
e are two sides to be considered not only perils but also benefits. In case=
 of mixed relops, they may not be particularly harmful, but on the other ha=
nd, they do not offer much value either. This is I guess what Olaf meant. N=
ot being a great peril is insufficient to remove a feature; but one could s=
tate it in a different way: a feature that is not particularly useful is no=
t worth adding. <br>

<br>Why is optional&lt;T&gt; not implicitly convertible to T? </div></block=
quote><div><br></div><div>Indeed the balance is in the actual amounts in th=
e tradeoff.<br><br></div><div>Perhaps I was not clear but, naturally, some =
features can be regarded unsafe and better left out. I&#39;m not arguing th=
at something like that cannot be the case, I argue that is it, specifically=
, not the case of mixed relops.<br>

<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>There are ob=
viously some technical problems (e.g., what would such conversion do for op=
tional&lt;bool&gt;), but if they were magically overcome would we offer suc=
h conversion or not? I believe not, because it is one of the safety feature=
s of optional, that you have to explicitly ask for the contained value, oth=
erwise compiler can warn you about the omission. This is already an impleme=
ntation of an &quot;improved NaN&quot;. The only exception to this safety r=
ule is mixed relops. This is the only case where we suspend this  &quot;imp=
roved NaN&quot; feature.  &quot;Improved NaN&quot; is a feature, and by kee=
ping mixed relops, we would be compromising this feature (by providing a di=
fferent one). The way I see it, it is a trade-off between two features. We =
could try to weigh them somehow, although this may be too personal.<br>

<br>Can I think of some arguments that are objective? Mixed relops are used=
 rarely, compared to other parts of the interface.</div></blockquote><div><=
br></div><div>Let me attempt to branch the discussion here.<br><br></div>

<div>*ordering* relops are used rarely.<br></div><div>*equality* relops are=
 used quite often.<br><br></div><div>Having said that, let me add that IME,=
 the usage of one or other kind of relops is NOT significantly different in=
 the homogeneous case vs the heterogeneous case.<br>

<br></div><div>That is, *it is not* the case, again IME, that=C2=A0 &quot;o=
pt relop opt&quot; is significantly more common than &quot;opt relop T&quot=
;<br><br>I know that statement sets an unproven fact, but it is nonetheless=
 a fact that is totally fundamental for the current discussion. <br>

</div><div><br></div><div><br>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv> Perhaps using the not-immediately-obvious operator to handle rare use c=
ases is encouraging misuses. It is different for operator*, because users h=
ave to learn it the first day. They may never have time to read the entire =
manual, and when they see it in the code, they will mistakenly take it for =
T &lt; T. So the argument here would be &quot;tricky meaning for rare cases=
&quot;. Perhaps a descriptive name instead of operators would provide a bet=
ter trade-off between safety and usability.<br>

<br>Anyway, I do not expect I can convince anybody with this argument. At l=
east I am now better able to explain my position. It is not &quot;refactori=
ng safety&quot; anymore. It is &quot;improved NaN&quot; feature.<br><br>

</div></blockquote><div><br></div><div>OK, but, how is the improved NaN fea=
ture affected differently by *mixed* relops as opposed to (homogeneous) rel=
ops ?<br></div><br></div><div class=3D"gmail_quote">Still after all that ha=
s been said, I remain in the position that, <br>

<br></div><div class=3D"gmail_quote">*provided* opt &lt; opt is OK,=C2=A0 t=
hen so is opt &lt; make_optional&lt;t&gt;, and then, I still fail to see wh=
y opt &lt; t would not be exactly equally OK.<br><br>The only argument I&#3=
9;ve got this far is that I might want the compiler to forbid performing op=
erations against different types. I would totally subscribe to that, in ano=
ther language, like in C# where you cannot, for instance, even pass 1.2 to =
a function expecting a float, something that is totally OK in C++.<br>

<br></div><div class=3D"gmail_quote">IMHO, everything else that I&#39;ve re=
ad so far is not *really* (again IMHO) about mixing opts and T&#39;s in a c=
omparison but about the comparisons themselves. That is a totally valid dis=
cussion, but is an entirely different one.<br>

</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Best<=
br></div><div class=3D"gmail_quote"><br></div><br>-- <br>Fernando Cacciola<=
br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.=
com">http://www.scisoft-consulting.com</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b34372c60b0b604d474b12c--

.

------=_Part_2230_1624615.1359497567645
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu wtorek, 29 stycznia 2013 22:33:51 UTC+1 u=BFytkownik Vladimir Batov=
=20
napisa=B3:
>
> On Wed, Jan 30, 2013 at 8:07 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:=20
> > ...=20
> > Why do we allow certain features and interfaces and do not allow other?=
=20
> I=20
> > believe the criterion for adding a feature is that the feature provides=
=20
> more=20
> > benefits than it causes troubles. That is, there are two sides to be=20
> > considered not only perils but also benefits. In case of mixed relops,=
=20
> they=20
> > may not be particularly harmful, but on the other hand, they do not=20
> offer=20
> > much value either. This is I guess what Olaf meant. Not being a great=
=20
> peril=20
> > is insufficient to remove a feature; but one could state it in a=20
> different=20
> > way: a feature that is not particularly useful is not worth adding.=20
>
> I might add "a feature that can be done by conventional/already=20
> available means is not worth adding".=20
>
> > Why is optional<T> not implicitly convertible to T? There are obviously=
=20
> some=20
> > technical problems (e.g., what would such conversion do for=20
> optional<bool>),=20
> > but if they were magically overcome would we offer such conversion or=
=20
> not? I=20
> > believe not, because it is one of the safety features of optional, that=
=20
> you=20
> > have to explicitly ask for the contained value, otherwise compiler can=
=20
> warn=20
> > you about the omission. This is already an implementation of an=20
> "improved=20
> > NaN". The only exception to this safety rule is mixed relops. This is=
=20
> the=20
> > only case where we suspend this "improved NaN" feature. "Improved NaN"=
=20
> is a=20
> > feature, and by keeping mixed relops, we would be compromising this=20
> feature=20
> > (by providing a different one). The way I see it, it is a trade-off=20
> between=20
> > two features. We could try to weigh them somehow, although this may be=
=20
> too=20
> > personal.=20
> >=20
> > Can I think of some arguments that are objective? Mixed relops are used=
=20
> > rarely, compared to other parts of the interface. Perhaps using the=20
> > not-immediately-obvious operator to handle rare use cases is encouragin=
g=20
> > misuses. It is different for operator*, because users have to learn it=
=20
> the=20
> > first day. They may never have time to read the entire manual, and when=
=20
> they=20
> > see it in the code, they will mistakenly take it for T < T. So the=20
> argument=20
> > here would be "tricky meaning for rare cases". Perhaps a descriptive=20
> name=20
> > instead of operators would provide a better trade-off between safety an=
d=20
> > usability.=20
> >=20
> > Anyway, I do not expect I can convince anybody with this argument. At=
=20
> least=20
> > I am now better able to explain my position. It is not "refactoring=20
> safety"=20
> > anymore. It is "improved NaN" feature.=20
>
> Overwhelmingly I agree with your position. I see disengaged optional=20
> as an "improved NaN" and I do feel that "opt < 5" can be easily=20
> interpreted as "int < int" rather than "optional < optional". My only=20
> hesitation (again, it's a hesitation rather than a strong objection)=20
> against prohibiting mixed relops is based on the fact that I feel=20
> "homogeneous" relops are essential for 'optional'. Therefore, I feel=20
> that "op < optional<int>(5)" needs to be supported. And from that=20
> there is only a tiny step to "op < 5" (as long as it means the same as=20
> "op < optional<int>(5)") which can probably be supported by the=20
> performance/optimization argument.=20
>
> Yes, my preference as a *reader* would be the explicit and somewhat=20
> lengthy but unambiguous "opt && *opt < 5" (value comparison) or "op <=20
> optional<int>(5)" (opt comparison).=20


Or we could give you an alternative option:

less_with_nullopt(opt, 5);

It is longer to type, but (1) it is as efficient as a mixed relop can be=20
and (2) you will not mess with the Boolean expression.

However, as an=20
> efficiency-conscientious user I might want "*opt < 5" (value=20
> comparison) or "opt < 5" (opt comparison) as optional<int>(5)=20
> construction might be expensive. Subtle? Yes. Still, it won't the only=20
> subtle place in C++ and the std library. Surely, as far as C++ goes,=20
> if one is determined to shoot himself in the foot, he'll succeed it no=20
> matter what.=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/?hl=3Den.



------=_Part_2230_1624615.1359497567645
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu wtorek, 29 stycznia 2013 22:33:51 UTC+1 u=BFytkownik Vladimi=
r Batov napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jan =
30, 2013 at 8:07 AM, Andrzej Krzemie=F1ski &lt;<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"l9KJO_x-5-AJ">akrz...@gmail.com</a>&=
gt; wrote:
<br>&gt; ...
<br>&gt; Why do we allow certain features and interfaces and do not allow o=
ther? I
<br>&gt; believe the criterion for adding a feature is that the feature pro=
vides more
<br>&gt; benefits than it causes troubles. That is, there are two sides to =
be
<br>&gt; considered not only perils but also benefits. In case of mixed rel=
ops, they
<br>&gt; may not be particularly harmful, but on the other hand, they do no=
t offer
<br>&gt; much value either. This is I guess what Olaf meant. Not being a gr=
eat peril
<br>&gt; is insufficient to remove a feature; but one could state it in a d=
ifferent
<br>&gt; way: a feature that is not particularly useful is not worth adding=
..
<br>
<br>I might add "a feature that can be done by conventional/already
<br>available means is not worth adding".
<br>
<br>&gt; Why is optional&lt;T&gt; not implicitly convertible to T? There ar=
e obviously some
<br>&gt; technical problems (e.g., what would such conversion do for option=
al&lt;bool&gt;),
<br>&gt; but if they were magically overcome would we offer such conversion=
 or not? I
<br>&gt; believe not, because it is one of the safety features of optional,=
 that you
<br>&gt; have to explicitly ask for the contained value, otherwise compiler=
 can warn
<br>&gt; you about the omission. This is already an implementation of an "i=
mproved
<br>&gt; NaN". The only exception to this safety rule is mixed relops. This=
 is the
<br>&gt; only case where we suspend this "improved NaN" feature. "Improved =
NaN" is a
<br>&gt; feature, and by keeping mixed relops, we would be compromising thi=
s feature
<br>&gt; (by providing a different one). The way I see it, it is a trade-of=
f between
<br>&gt; two features. We could try to weigh them somehow, although this ma=
y be too
<br>&gt; personal.
<br>&gt;
<br>&gt; Can I think of some arguments that are objective? Mixed relops are=
 used
<br>&gt; rarely, compared to other parts of the interface. Perhaps using th=
e
<br>&gt; not-immediately-obvious operator to handle rare use cases is encou=
raging
<br>&gt; misuses. It is different for operator*, because users have to lear=
n it the
<br>&gt; first day. They may never have time to read the entire manual, and=
 when they
<br>&gt; see it in the code, they will mistakenly take it for T &lt; T. So =
the argument
<br>&gt; here would be "tricky meaning for rare cases". Perhaps a descripti=
ve name
<br>&gt; instead of operators would provide a better trade-off between safe=
ty and
<br>&gt; usability.
<br>&gt;
<br>&gt; Anyway, I do not expect I can convince anybody with this argument.=
 At least
<br>&gt; I am now better able to explain my position. It is not "refactorin=
g safety"
<br>&gt; anymore. It is "improved NaN" feature.
<br>
<br>Overwhelmingly I agree with your position. I see disengaged optional
<br>as an "improved NaN" and I do feel that "opt &lt; 5" can be easily
<br>interpreted as "int &lt; int" rather than "optional &lt; optional". My =
only
<br>hesitation (again, it's a hesitation rather than a strong objection)
<br>against prohibiting mixed relops is based on the fact that I feel
<br>"homogeneous" relops are essential for 'optional'. Therefore, I feel
<br>that "op &lt; optional&lt;int&gt;(5)" needs to be supported. And from t=
hat
<br>there is only a tiny step to "op &lt; 5" (as long as it means the same =
as
<br>"op &lt; optional&lt;int&gt;(5)") which can probably be supported by th=
e
<br>performance/optimization argument.
<br>
<br>Yes, my preference as a *reader* would be the explicit and somewhat
<br>lengthy but unambiguous "opt &amp;&amp; *opt &lt; 5" (value comparison)=
 or "op &lt;
<br>optional&lt;int&gt;(5)" (opt comparison). </blockquote><div><br>Or we c=
ould give you an alternative option:<br><br>less_with_nullopt(opt, 5);<br><=
br>It is longer to type, but (1) it is as efficient as a mixed relop can be=
 and (2) you will not mess with the Boolean expression.<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">However, as an
<br>efficiency-conscientious user I might want "*opt &lt; 5" (value
<br>comparison) or "opt &lt; 5" (opt comparison) as optional&lt;int&gt;(5)
<br>construction might be expensive. Subtle? Yes. Still, it won't the only
<br>subtle place in C++ and the std library. Surely, as far as C++ goes,
<br>if one is determined to shoot himself in the foot, he'll succeed it no
<br>matter what.
<br></blockquote>

<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2230_1624615.1359497567645--

.

On Wed, Jan 30, 2013 at 8:52 AM, Matias Capeletto
<matias.capeletto@gmail.com> wrote:
> On Tue, Jan 29, 2013 at 10:33 PM, Vladimir Batov <vb.mail.247@gmail.com> wrote:
>> Yes, my preference as a *reader* would be the explicit and somewhat
>> lengthy but unambiguous "opt && *opt < 5" (value comparison) or "op <
>> optional<int>(5)" (opt comparison). However, as an
>> efficiency-conscientious user I might want "*opt < 5" (value
>> comparison) or
>
> If you are certain that you have a value, because you checked before
> or you just assign it then go for it.
>
>> "opt < 5" (opt comparison) as optional<int>(5)
>> construction might be expensive. Subtle? Yes. Still, it won't the only
>> subtle place in C++ and the std library. Surely, as far as C++ goes,
>> if one is determined to shoot himself in the foot, he'll succeed it no
>> matter what.
>
> The performance argument does not work if you compare (op<5) with
> (op?*op<5:true).

Indeed. Although the right way of writing what you probably meant will be

(op ? (*op < 5) : true)

In all honesty that'd be my personal preference by far as far as
clarity and unambiguity is concerned. Now I've run out of ammunition
playing "devil's advocate" for mixed relops. Can real power users in
favor of mixed relops step forward please?

> As others are expressing, given an ordering to optionals seems to be
> mainly useful in the context of containers. I also will like to see
> examples where you will want to do [ op < optional<int>(5) ].

Well, I've been hearing this quite a lot lately. :-) In general terms
it seems likely to me that when (for whatever reason) I decide to
replace a sortable type T with optional<T>, I'd expect optional<T> to
support sorting as well. That said, it's merely a hunch.

--

---
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/?hl=en.



.

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

On 29 January 2013 15:07, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:

>
> Why do we allow certain features and interfaces and do not allow other? I
> believe the criterion for adding a feature is that the feature provides
> more benefits than it causes troubles. That is, there are two sides to be
> considered not only perils but also benefits. In case of mixed relops, th=
ey
> may not be particularly harmful, but on the other hand, they do not offer
> much value either. This is I guess what Olaf meant. Not being a great per=
il
> is insufficient to remove a feature; but one could state it in a differen=
t
> way: a feature that is not particularly useful is not worth adding.
>

People are looking to add this functionality to other things in the
standard (such as map lookup), so clearly there is a desire for it.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=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/?hl=3Den.



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

On 29 January 2013 15:07, Andrzej Krzemie=C5=84ski <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</a=
>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">

<br><div>Why do we allow certain features and interfaces and do not allow o=
ther? I believe the criterion for adding a feature is that the feature prov=
ides more benefits than it causes troubles. That is, there are two sides to=
 be considered not only perils but also benefits. In case of mixed relops, =
they may not be particularly harmful, but on the other hand, they do not of=
fer much value either. This is I guess what Olaf meant. Not being a great p=
eril is insufficient to remove a feature; but one could state it in a diffe=
rent way: a feature that is not particularly useful is not worth adding. <b=
r>

</div></blockquote><div><br>People are looking to add this functionality to=
 other things in the standard (such as map lookup), so clearly there is a d=
esire for it.<br clear=3D"all"></div></div>-- <br>=C2=A0Nevin &quot;:-)&quo=
t; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404

<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--20cf300fafc7240bd404d474c19e--

.

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

On Tue, Jan 29, 2013 at 7:33 PM, Vladimir Batov <vb.mail.247@gmail.com>wrot=
e:

> On Wed, Jan 30, 2013 at 8:07 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail=
..com>
> wrote:
> > ...
> > Why do we allow certain features and interfaces and do not allow other?=
 I
> > believe the criterion for adding a feature is that the feature provides
> more
> > benefits than it causes troubles. That is, there are two sides to be
> > considered not only perils but also benefits. In case of mixed relops,
> they
> > may not be particularly harmful, but on the other hand, they do not off=
er
> > much value either. This is I guess what Olaf meant. Not being a great
> peril
> > is insufficient to remove a feature; but one could state it in a
> different
> > way: a feature that is not particularly useful is not worth adding.
>
> I might add "a feature that can be done by conventional/already
> available means is not worth adding".
>
> Which is an argument that you can make about relops among optionals.

So, let's please separate the discussions.

Either we discuss whether optionals should have a default ordering (that
is, opt < opt valid?), whether they should be equaility-comparable (opt =3D=
=3D
opt valid?), or whether users should be forced to explicitly convert both
operands for whatever comparison.



> > Why is optional<T> not implicitly convertible to T? There are obviously
> some
> > technical problems (e.g., what would such conversion do for
> optional<bool>),
> > but if they were magically overcome would we offer such conversion or
> not? I
> > believe not, because it is one of the safety features of optional, that
> you
> > have to explicitly ask for the contained value, otherwise compiler can
> warn
> > you about the omission. This is already an implementation of an "improv=
ed
> > NaN". The only exception to this safety rule is mixed relops. This is t=
he
> > only case where we suspend this "improved NaN" feature. "Improved NaN"
> is a
> > feature, and by keeping mixed relops, we would be compromising this
> feature
> > (by providing a different one). The way I see it, it is a trade-off
> between
> > two features. We could try to weigh them somehow, although this may be
> too
> > personal.
> >
> > Can I think of some arguments that are objective? Mixed relops are used
> > rarely, compared to other parts of the interface. Perhaps using the
> > not-immediately-obvious operator to handle rare use cases is encouragin=
g
> > misuses. It is different for operator*, because users have to learn it
> the
> > first day. They may never have time to read the entire manual, and when
> they
> > see it in the code, they will mistakenly take it for T < T. So the
> argument
> > here would be "tricky meaning for rare cases". Perhaps a descriptive na=
me
> > instead of operators would provide a better trade-off between safety an=
d
> > usability.
> >
> > Anyway, I do not expect I can convince anybody with this argument. At
> least
> > I am now better able to explain my position. It is not "refactoring
> safety"
> > anymore. It is "improved NaN" feature.
>
> Overwhelmingly I agree with your position. I see disengaged optional
> as an "improved NaN" and I do feel that "opt < 5" can be easily
> interpreted as "int < int" rather than "optional < optional".


Really? How could that ever be interpreted like that by anything but
misunderstanding?

I really don't buy that.



> My only
> hesitation (again, it's a hesitation rather than a strong objection)
> against prohibiting mixed relops is based on the fact that I feel
> "homogeneous" relops are essential for 'optional'. Therefore, I feel
> that "op < optional<int>(5)" needs to be supported. And from that
> there is only a tiny step to "op < 5" (as long as it means the same as
> "op < optional<int>(5)") which can probably be supported by the
> performance/optimization argument.
>
> Yes, my preference as a *reader* would be the explicit and somewhat
> lengthy but unambiguous "opt && *opt < 5" (value comparison)


This line of argument puzzles me.

if you had opt1 and op2, wouldn't you, by the same "reader's choice" prefer
to see?

opt1 && opt2 && *opt1 < *opt2

instead of

opt1 < opt2

??

Like I said, I really don't see how the potential "mystery" about the
semantics of the comparison in the presence of nullopt appears to be fueled
by mixing the types of operands. I would said that if anything, having one
T at least cuts down the possible branches by a factor of 2, so it actually
makes it more clear, not less.



--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=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/?hl=3Den.



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jan 29, 2013 at 7:33 PM, Vladimir Batov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:vb.mail.247@gmail.com" target=3D"_blank">vb.mail.247@gmail.com</=
a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Wed, Jan 30, 2013 at 8:07 AM, Andrzej Krz=
emie=C5=84ski &lt;<a href=3D"mailto:akrzemi1@gmail.com">akrzemi1@gmail.com<=
/a>&gt; wrote:<br>


&gt; ...<br>
<div class=3D"im">&gt; Why do we allow certain features and interfaces and =
do not allow other? I<br>
&gt; believe the criterion for adding a feature is that the feature provide=
s more<br>
&gt; benefits than it causes troubles. That is, there are two sides to be<b=
r>
&gt; considered not only perils but also benefits. In case of mixed relops,=
 they<br>
&gt; may not be particularly harmful, but on the other hand, they do not of=
fer<br>
&gt; much value either. This is I guess what Olaf meant. Not being a great =
peril<br>
&gt; is insufficient to remove a feature; but one could state it in a diffe=
rent<br>
&gt; way: a feature that is not particularly useful is not worth adding.<br=
>
<br>
</div>I might add &quot;a feature that can be done by conventional/already<=
br>
available means is not worth adding&quot;.<br>
<div class=3D"im"><br></div></blockquote><div>Which is an argument that you=
 can make about relops among optionals.<br><br>So, let&#39;s please separat=
e the discussions.<br><br></div><div>Either we discuss whether optionals sh=
ould have a default ordering (that is, opt &lt; opt valid?), whether they s=
hould be equaility-comparable (opt =3D=3D opt valid?), or whether users sho=
uld be forced to explicitly convert both operands for whatever comparison.<=
br>

</div><br><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D=
"im">
&gt; Why is optional&lt;T&gt; not implicitly convertible to T? There are ob=
viously some<br>
&gt; technical problems (e.g., what would such conversion do for optional&l=
t;bool&gt;),<br>
&gt; but if they were magically overcome would we offer such conversion or =
not? I<br>
&gt; believe not, because it is one of the safety features of optional, tha=
t you<br>
&gt; have to explicitly ask for the contained value, otherwise compiler can=
 warn<br>
&gt; you about the omission. This is already an implementation of an &quot;=
improved<br>
&gt; NaN&quot;. The only exception to this safety rule is mixed relops. Thi=
s is the<br>
&gt; only case where we suspend this &quot;improved NaN&quot; feature. &quo=
t;Improved NaN&quot; is a<br>
&gt; feature, and by keeping mixed relops, we would be compromising this fe=
ature<br>
&gt; (by providing a different one). The way I see it, it is a trade-off be=
tween<br>
&gt; two features. We could try to weigh them somehow, although this may be=
 too<br>
&gt; personal.<br>
&gt;<br>
&gt; Can I think of some arguments that are objective? Mixed relops are use=
d<br>
&gt; rarely, compared to other parts of the interface. Perhaps using the<br=
>
&gt; not-immediately-obvious operator to handle rare use cases is encouragi=
ng<br>
&gt; misuses. It is different for operator*, because users have to learn it=
 the<br>
&gt; first day. They may never have time to read the entire manual, and whe=
n they<br>
&gt; see it in the code, they will mistakenly take it for T &lt; T. So the =
argument<br>
&gt; here would be &quot;tricky meaning for rare cases&quot;. Perhaps a des=
criptive name<br>
&gt; instead of operators would provide a better trade-off between safety a=
nd<br>
&gt; usability.<br>
&gt;<br>
&gt; Anyway, I do not expect I can convince anybody with this argument. At =
least<br>
&gt; I am now better able to explain my position. It is not &quot;refactori=
ng safety&quot;<br>
&gt; anymore. It is &quot;improved NaN&quot; feature.<br>
<br>
</div>Overwhelmingly I agree with your position. I see disengaged optional<=
br>
as an &quot;improved NaN&quot; and I do feel that &quot;opt &lt; 5&quot; ca=
n be easily<br>
interpreted as &quot;int &lt; int&quot; rather than &quot;optional &lt; opt=
ional&quot;.</blockquote><div><br></div><div>Really? How could that ever be=
 interpreted like that by anything but misunderstanding?<br></div><div>

<br></div><div>I really don&#39;t buy that.<br><br></div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"> My only<br>
hesitation (again, it&#39;s a hesitation rather than a strong objection)<br=
>
against prohibiting mixed relops is based on the fact that I feel<br>
&quot;homogeneous&quot; relops are essential for &#39;optional&#39;. Theref=
ore, I feel<br>
that &quot;op &lt; optional&lt;int&gt;(5)&quot; needs to be supported. And =
from that<br>
there is only a tiny step to &quot;op &lt; 5&quot; (as long as it means the=
 same as<br>
&quot;op &lt; optional&lt;int&gt;(5)&quot;) which can probably be supported=
 by the<br>
performance/optimization argument.<br>
<br>
Yes, my preference as a *reader* would be the explicit and somewhat<br>
lengthy but unambiguous &quot;opt &amp;&amp; *opt &lt; 5&quot; (value compa=
rison) </blockquote><div><br></div><div>This line of argument puzzles me.<b=
r><br></div><div>if you had opt1 and op2, wouldn&#39;t you, by the same &qu=
ot;reader&#39;s choice&quot; prefer to see?<br>

<br></div><div>opt1 &amp;&amp; opt2 &amp;&amp; *opt1 &lt; *opt2<br><br></di=
v><div>instead of <br><br></div><div>opt1 &lt; opt2<br><br></div><div>??<br=
><br></div><div>Like I said, I really don&#39;t see how the potential &quot=
;mystery&quot; about the semantics of the comparison in the presence of nul=
lopt appears to be fueled by mixing the types of operands. I would said tha=
t if anything, having one T at least cuts down the possible branches by a f=
actor of 2, so it actually makes it more clear, not less.<br>

<br></div></div><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>SciSoft C=
onsulting, Founder<br><a href=3D"http://www.scisoft-consulting.com">http://=
www.scisoft-consulting.com</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b62243465a97904d474da02--

.

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

On Tue, Jan 29, 2013 at 7:37 PM, Matias Capeletto <
matias.capeletto@gmail.com> wrote:

> On Tue, Jan 29, 2013 at 10:07 PM, Andrzej Krzemie=C5=84ski
> <akrzemi1@gmail.com> wrote:
> > Why is optional<T> not implicitly convertible to T? There are obviously
> some
> > technical problems (e.g., what would such conversion do for
> optional<bool>),
> > but if they were magically overcome would we offer such conversion or
> not? I
> > believe not, because it is one of the safety features of optional, that
> you
> > have to explicitly ask for the contained value, otherwise compiler can
> warn
> > you about the omission. This is already an implementation of an "improv=
ed
> > NaN". The only exception to this safety rule is mixed relops. This is t=
he
> > only case where we suspend this "improved NaN" feature. "Improved NaN"
> is a
> > feature, and by keeping mixed relops, we would be compromising this
> feature
> > (by providing a different one). The way I see it, it is a trade-off
> between
> > two features. We could try to weigh them somehow, although this may be
> too
> > personal.
>
> I think that stating this in these terms is a great progress in the
> discussion.
>
> > Anyway, I do not expect I can convince anybody with this argument. At
> least
> > I am now better able to explain my position. It is not "refactoring
> safety"
> > anymore. It is "improved NaN" feature.
>
> +1, I am also starting to think that mixed rel ops are better left
> aside


Would you say that for normal relops?

If not, why would you left out the mixed ones and not the others?



> from the proposal. In the case users end up screaming for them
> later, we can review the decision.
>
>
There is no doubt that we will present this as an "optional" feature, given
all the concerns that it raised.





--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=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/?hl=3Den.



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jan 29, 2013 at 7:37 PM, Matias Capeletto <span dir=3D"ltr">&lt;<a href=
=3D"mailto:matias.capeletto@gmail.com" target=3D"_blank">matias.capeletto@g=
mail.com</a>&gt;</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 class=3D"im">On Tue, Jan 29, 2013 at 10=
:07 PM, Andrzej Krzemie=C5=84ski<br>
&lt;<a href=3D"mailto:akrzemi1@gmail.com">akrzemi1@gmail.com</a>&gt; wrote:=
<br>
&gt; Why is optional&lt;T&gt; not implicitly convertible to T? There are ob=
viously some<br>
&gt; technical problems (e.g., what would such conversion do for optional&l=
t;bool&gt;),<br>
&gt; but if they were magically overcome would we offer such conversion or =
not? I<br>
&gt; believe not, because it is one of the safety features of optional, tha=
t you<br>
&gt; have to explicitly ask for the contained value, otherwise compiler can=
 warn<br>
&gt; you about the omission. This is already an implementation of an &quot;=
improved<br>
&gt; NaN&quot;. The only exception to this safety rule is mixed relops. Thi=
s is the<br>
&gt; only case where we suspend this &quot;improved NaN&quot; feature. &quo=
t;Improved NaN&quot; is a<br>
&gt; feature, and by keeping mixed relops, we would be compromising this fe=
ature<br>
&gt; (by providing a different one). The way I see it, it is a trade-off be=
tween<br>
&gt; two features. We could try to weigh them somehow, although this may be=
 too<br>
&gt; personal.<br>
<br>
</div>I think that stating this in these terms is a great progress in the d=
iscussion.<br>
<div class=3D"im"><br>
&gt; Anyway, I do not expect I can convince anybody with this argument. At =
least<br>
&gt; I am now better able to explain my position. It is not &quot;refactori=
ng safety&quot;<br>
&gt; anymore. It is &quot;improved NaN&quot; feature.<br>
<br>
</div>+1, I am also starting to think that mixed rel ops are better left<br=
>
aside </blockquote><div><br></div><div>Would you say that for normal relops=
?<br><br></div><div>If not, why would you left out the mixed ones and not t=
he others?<br><br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

from the proposal. In the case users end up screaming for them<br>
later, we can review the decision.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>There is no doubt that we will present this as an &quot;optio=
nal&quot; feature, given all the concerns that it raised.<br><br></div><br>

</div><br><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>SciSoft Consult=
ing, Founder<br><a href=3D"http://www.scisoft-consulting.com">http://www.sc=
isoft-consulting.com</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b6222d0a6c4bd04d474e3ed--

.

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

On 29 January 2013 15:47, Tony V E <tvaneerd@gmail.com> wrote:

>
> I think they are almost exclusively for use in map/set.  In which case
> an override of std::less<> would be good enough.


I would vote strongly against that.

It is clever, it breaks expectations, and is non-expert unfriendly.

Are there *any* types in the standard (besides raw pointers under some
implementations, and that is only because C does not require a total
ordering for raw pointers) that specialize less but don't provide operator<?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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



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

On 29 January 2013 15:47, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:=
tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wro=
te:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im"><br>
</div>I think they are almost exclusively for use in map/set. =A0In which c=
ase<br>
an override of std::less&lt;&gt; would be good enough. </blockquote><div><b=
r>I would vote strongly against that.<br><br>It is clever, it breaks expect=
ations, and is non-expert unfriendly.<br><br>Are there *any* types in the s=
tandard (besides raw pointers under some implementations, and that is only =
because C does not require a total ordering for raw pointers) that speciali=
ze less but don&#39;t provide operator&lt;?<br>

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404

<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b6d98c64fd2d904d474f4dc--

.

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

On Tue, Jan 29, 2013 at 8:12 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om>wrote
>
>
> Or we could give you an alternative option:
>
> less_with_nullopt(opt, 5);
>
> It is longer to type, but (1) it is as efficient as a mixed relop can be
> and (2) you will not mess with the Boolean expression.
>

 I'm not at all against these sort of functions, but, why are they being
considered in the context of mixed relops??

IOW, if I ever want to be explicit about how disengaged compares against
engaged by using a function (which is a good idea, no doubt), then I will
want that regardless of whether I have both arguments already being
optionals or not.

That is, unless I'm missing something obvious, if I would write:

less_with_nullopt(opt, 5);

then I would just as well write

less_with_nullopt(opt1, opt2);

I don't see how the fact that one of the operands is a T and not an
optional<> changes the usability of such a function.

(which brings me to repeat what I have been saying... let's not confuse
anymore the arguments about mixing operands with the arguments about the
semantics of comparing optionals)


--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=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/?hl=3Den.



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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jan 29, 2013 at 8:12 PM, Andrzej Krzemie=C5=84ski <span dir=3D"ltr">&lt=
;<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com=
</a>&gt;</span> wrote<blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div><br>Or we could give you an alternative option:<br><br>less_with_nullo=
pt(opt, 5);<br><br>It is longer to type, but (1) it is as efficient as a mi=
xed relop can be and (2) you will not mess with the Boolean expression.<br>

</div></blockquote><div><br></div><div>=C2=A0I&#39;m not at all against the=
se sort of functions, but, why are they being considered in the context of =
mixed relops??<br><br></div><div>IOW, if I ever want to be explicit about h=
ow disengaged compares against engaged by using a function (which is a good=
 idea, no doubt), then I will want that regardless of whether I have both a=
rguments already being optionals or not.<br>

<br></div><div>That is, unless I&#39;m missing something obvious, if I woul=
d write:<br><br>less_with_nullopt(opt, 5);<br><br></div><div>then I would j=
ust as well write<br><br>less_with_nullopt(opt1, opt2);<br></div></div>

<br></div><div class=3D"gmail_extra">I don&#39;t see how the fact that one =
of the operands is a T and not an optional&lt;&gt; changes the usability of=
 such a function.<br><br></div><div class=3D"gmail_extra">(which brings me =
to repeat what I have been saying... let&#39;s not confuse anymore the argu=
ments about mixing operands with the arguments about the semantics of compa=
ring optionals)<br>

</div><div class=3D"gmail_extra"><br clear=3D"all"><br>-- <br>Fernando Cacc=
iola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consul=
ting.com">http://www.scisoft-consulting.com</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b34372c6ed12304d47510bb--

.

On Wed, Jan 30, 2013 at 9:23 AM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Tue, Jan 29, 2013 at 7:33 PM, Vladimir Batov <vb.mail.247@gmail.com>
> wrote:
>> On Wed, Jan 30, 2013 at 8:07 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmai=
l.com>
>> wrote:
>> ...
>> I might add "a feature that can be done by conventional/already
>> available means is not worth adding".
>>
> Which is an argument that you can make about relops among optionals.

I have to disagree. If I am to use optional widely, it's miost likely
end up in an ass. container... which (through the default
implementation of std::less) expects optional::operator<(optional
const&)

>> > ...
>> > see it in the code, they will mistakenly take it for T < T. So the
>> > argument
>> > here would be "tricky meaning for rare cases". Perhaps a descriptive
>> > name
>> > instead of operators would provide a better trade-off between safety a=
nd
>> > usability.
>> > ...
>> Overwhelmingly I agree with your position. I see disengaged optional
>> as an "improved NaN" and I do feel that "opt < 5" can be easily
>> interpreted as "int < int" rather than "optional < optional".
>
> Really? How could that ever be interpreted like that by anything but
> misunderstanding?
>
> I really don't buy that.

There is nothing to buy really. Andrzej expressed his impression that
"opt < 5" might be mistakenly taken for "int < int" and I happen to
share his impression. Misunderstanding? I guess so.

>> My only
>> hesitation (again, it's a hesitation rather than a strong objection)
>> against prohibiting mixed relops is based on the fact that I feel
>> "homogeneous" relops are essential for 'optional'. Therefore, I feel
>> that "op < optional<int>(5)" needs to be supported. And from that
>> there is only a tiny step to "op < 5" (as long as it means the same as
>> "op < optional<int>(5)") which can probably be supported by the
>> performance/optimization argument.
>>
>> Yes, my preference as a *reader* would be the explicit and somewhat
>> lengthy but unambiguous "opt && *opt < 5" (value comparison)
>
> This line of argument puzzles me.
>
> if you had opt1 and op2, wouldn't you, by the same "reader's choice" pref=
er
> to see?

Fernando, I was never talking about "reader's choice". All I was
talking was *my* choice as a casual ;-) code reader. And as a reader
*my* personal preference would be "opt && *opt < 5". Again, it's not
an argument of any sort or justification of anything. Just how I feel.
What's so puzzling? :-)

> opt1 && opt2 && *opt1 < *opt2
>
> instead of
>
> opt1 < opt2

If "opt1 < opt2" is not supported, then optional cannot be used in
ass. containers which seems like a reasonable expectation.

> Like I said, I really don't see how the potential "mystery" about the
> semantics of the comparison in the presence of nullopt appears to be fuel=
ed
> by mixing the types of operands.

I am not sure I understand this. I seem to understand and support
"semantics of the comparison"... and I am happy to live "on the edge"
using "opt < 5".

--=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/?hl=3Den.



.

On Tue, Jan 29, 2013 at 11:26 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Tue, Jan 29, 2013 at 7:37 PM, Matias Capeletto
> <matias.capeletto@gmail.com> wrote:
>> On Tue, Jan 29, 2013 at 10:07 PM, Andrzej Krzemie=C5=84ski
>> <akrzemi1@gmail.com> wrote:
>> > Anyway, I do not expect I can convince anybody with this argument. At
>> > least
>> > I am now better able to explain my position. It is not "refactoring
>> > safety"
>> > anymore. It is "improved NaN" feature.
>>
>> +1, I am also starting to think that mixed rel ops are better left
>> aside
>
> Would you say that for normal relops?

No, because I agree that is important to make them container friendly
and if you are going to define less... you should define op<op as
Nevin Liber just posted.

> If not, why would you left out the mixed ones and not the others?

[Always taking about <, <=3D, > and >=3D here]

I kind of like your line of thinking:
[1] op < op  =3D> [2] op < optional<int>(5) =3D> [3] op < 5

But at this point I am failing to see that [2] is really something
that will come up a lot outside the context of containers. So I tend
to think there is a jump from [1] to [3].
For me, someone writing [2] knows that he wants the default ordering
[nullopts...values].
But someone that writes [3] may be bitten by the fact that there is
actually an arbitrary result chosen in the case of nullopt.

We can not forbid [2] because that will imply no [1]. So we will have
to live with op < optional<int>(5).
But we can force users to choose instead of given them [3]. I think
that the compiler error there will annoy people at first but it will
avoid bugs in user code that are not easy at all to spot. And there
have been several options presented to give the user terse and clear
syntax in replacement of the mix relops.

Best regards
Matias

--=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/?hl=3Den.



.

------=_Part_650_27173749.1359499997171
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu wtorek, 29 stycznia 2013 23:12:03 UTC+1 u=BFytkownik Fernando Caccio=
la=20
napisa=B3:
>
> On Tue, Jan 29, 2013 at 7:07 PM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>
> > wrote:
>
>>
>> =20
>>>> Maybe a matter of taste, but I like their versions better than either
>>>> of the alternatives.  Clear, easy to understand.
>>>>
>>>>
>>> And perhaps I do as well, but that's not central to the point under=20
>>> discussion.
>>>
>>> Which is, do we allow users to use mixed relops or we forbid that. IMO,=
=20
>>> in order to forbid it there must be much more than taste, good style,=
=20
>>> etc... I would only forbid it provided there are *significant reasons* =
to=20
>>> consider that it will be a source of subtle bugs. I would not forbid it=
 on=20
>>> the grounds that you can use alternative expressions.
>>>
>>> For the case at hand, I don't see anything near significant reasons to=
=20
>>> believe it will be a source of bugs
>>>
>>
>> Why do we allow certain features and interfaces and do not allow other? =
I=20
>> believe the criterion for adding a feature is that the feature provides=
=20
>> more benefits than it causes troubles. That is, there are two sides to b=
e=20
>> considered not only perils but also benefits. In case of mixed relops, t=
hey=20
>> may not be particularly harmful, but on the other hand, they do not offe=
r=20
>> much value either. This is I guess what Olaf meant. Not being a great pe=
ril=20
>> is insufficient to remove a feature; but one could state it in a differe=
nt=20
>> way: a feature that is not particularly useful is not worth adding.=20
>>
>> Why is optional<T> not implicitly convertible to T?=20
>>
>
> Indeed the balance is in the actual amounts in the tradeoff.
>
> Perhaps I was not clear but, naturally, some features can be regarded=20
> unsafe and better left out. I'm not arguing that something like that cann=
ot=20
> be the case, I argue that is it, specifically, not the case of mixed relo=
ps.
>
> =20
>
>> There are obviously some technical problems (e.g., what would such=20
>> conversion do for optional<bool>), but if they were magically overcome=
=20
>> would we offer such conversion or not? I believe not, because it is one =
of=20
>> the safety features of optional, that you have to explicitly ask for the=
=20
>> contained value, otherwise compiler can warn you about the omission. Thi=
s=20
>> is already an implementation of an "improved NaN". The only exception to=
=20
>> this safety rule is mixed relops. This is the only case where we suspend=
=20
>> this "improved NaN" feature. "Improved NaN" is a feature, and by keeping=
=20
>> mixed relops, we would be compromising this feature (by providing a=20
>> different one). The way I see it, it is a trade-off between two features=
..=20
>> We could try to weigh them somehow, although this may be too personal.
>>
>> Can I think of some arguments that are objective? Mixed relops are used=
=20
>> rarely, compared to other parts of the interface.
>>
>
> Let me attempt to branch the discussion here.
>
> *ordering* relops are used rarely.
> *equality* relops are used quite often.
>
> Having said that, let me add that IME, the usage of one or other kind of=
=20
> relops is NOT significantly different in the homogeneous case vs the=20
> heterogeneous case.
>
> That is, *it is not* the case, again IME, that  "opt relop opt" is=20
> significantly more common than "opt relop T"
>
> I know that statement sets an unproven fact, but it is nonetheless a fact=
=20
> that is totally fundamental for the current discussion.=20
>

Well, perhaps the difference in opinion results primarily from the usage=20
experience. My experience appears to be quite different. Given the examples=
=20
you provided earlier, and the above statements, I am inclined to think that=
=20
if I used boost::optional the way you do, I would probably share the same=
=20
opinion that you have on mixed ordering and mixed equality.

=20

>
>
> =20
>
>> Perhaps using the not-immediately-obvious operator to handle rare use=20
>> cases is encouraging misuses. It is different for operator*, because use=
rs=20
>> have to learn it the first day. They may never have time to read the ent=
ire=20
>> manual, and when they see it in the code, they will mistakenly take it f=
or=20
>> T < T. So the argument here would be "tricky meaning for rare cases".=20
>> Perhaps a descriptive name instead of operators would provide a better=
=20
>> trade-off between safety and usability.
>>
>> Anyway, I do not expect I can convince anybody with this argument. At=20
>> least I am now better able to explain my position. It is not "refactorin=
g=20
>> safety" anymore. It is "improved NaN" feature.
>>
>>
> OK, but, how is the improved NaN feature affected differently by *mixed*=
=20
> relops as opposed to (homogeneous) relops ?
>

Homogenous ordering also compromises the improved NaN feature. I guess the=
=20
reason I do not complain about homogenous ordering is that I never ever had=
=20
to use it directly. I only needed it for making=20
std::set<boost::optional<T>> to work. Again, this boils down to the=20
individual's usage experience. In contrast, I used mixed ordering only once=
=20
in my experience, and it was by mistake: I really intended to compare two=
=20
T's.

=20

>
> Still after all that has been said, I remain in the position that,=20
>
> *provided* opt < opt is OK,  then so is opt < make_optional<t>, and then,=
=20
> I still fail to see why opt < t would not be exactly equally OK.
>

The only argument I can make here is different probability of making a=20
programming error. When you compare two optionals you probably do it=20
consciously. Whereas, when comparing T with optional<T>, it is more likely=
=20
that you intended to compare two T's and forgot that one of the T's was=20
actually a nullable one. I guess it is all about this probability. =20


> The only argument I've got this far is that I might want the compiler to=
=20
> forbid performing operations against different types. I would totally=20
> subscribe to that, in another language, like in C# where you cannot, for=
=20
> instance, even pass 1.2 to a function expecting a float, something that i=
s=20
> totally OK in C++.
>
> IMHO, everything else that I've read so far is not *really* (again IMHO)=
=20
> about mixing opts and T's in a comparison but about the comparisons=20
> themselves. That is a totally valid discussion, but is an entirely=20
> different one.
>

"Technically", you are right. However, I do not entirely agree. I sense the=
=20
subtle difference between allowing mixed comparison and any comparison,=20
however I admit I cannot express it objectively. I tried to explain it=20
using the probability.=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/?hl=3Den.



------=_Part_650_27173749.1359499997171
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu wtorek, 29 stycznia 2013 23:12:03 UTC+1 u=BFytkownik Fernand=
o Cacciola napisa=B3:<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"><div><div class=3D"gmail_quote">On Tue, Jan 29, 2013 at 7:07 PM, A=
ndrzej Krzemie=F1ski <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"-WS6tOSj1qsJ">akrz...@gmail.com</a>&gt=
;</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><br><blockquote class=3D"gmail_quote" s=
tyle=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"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div>
<br>
</div>Maybe a matter of taste, but I like their versions better than either=
<br>
of the alternatives. &nbsp;Clear, easy to understand.<br>
<span><font color=3D"#888888"><br></font></span></blockquote><div><br></div=
><div>And perhaps I do as well, but that's not central to the point under d=
iscussion.<br><br></div><div>Which is, do we allow users to use mixed relop=
s or we forbid that. IMO, in order to forbid it there must be much more tha=
n taste, good style, etc... I would only forbid it provided there are *sign=
ificant reasons* to consider that it will be a source of subtle bugs. I wou=
ld not forbid it on the grounds that you can use alternative expressions.<b=
r>



<br></div><div>For the case at hand, I don't see anything near significant =
reasons to believe it will be a source of bugs</div></div></div></div></blo=
ckquote></div><div><br>Why do we allow certain features and interfaces and =
do not allow other? I believe the criterion for adding a feature is that th=
e feature provides more benefits than it causes troubles. That is, there ar=
e two sides to be considered not only perils but also benefits. In case of =
mixed relops, they may not be particularly harmful, but on the other hand, =
they do not offer much value either. This is I guess what Olaf meant. Not b=
eing a great peril is insufficient to remove a feature; but one could state=
 it in a different way: a feature that is not particularly useful is not wo=
rth adding. <br>

<br>Why is optional&lt;T&gt; not implicitly convertible to T? </div></block=
quote><div><br></div><div>Indeed the balance is in the actual amounts in th=
e tradeoff.<br><br></div><div>Perhaps I was not clear but, naturally, some =
features can be regarded unsafe and better left out. I'm not arguing that s=
omething like that cannot be the case, I argue that is it, specifically, no=
t the case of mixed relops.<br>

<br></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>There are ob=
viously some technical problems (e.g., what would such conversion do for op=
tional&lt;bool&gt;), but if they were magically overcome would we offer suc=
h conversion or not? I believe not, because it is one of the safety feature=
s of optional, that you have to explicitly ask for the contained value, oth=
erwise compiler can warn you about the omission. This is already an impleme=
ntation of an "improved NaN". The only exception to this safety rule is mix=
ed relops. This is the only case where we suspend this  "improved NaN" feat=
ure.  "Improved NaN" is a feature, and by keeping mixed relops, we would be=
 compromising this feature (by providing a different one). The way I see it=
, it is a trade-off between two features. We could try to weigh them someho=
w, although this may be too personal.<br>

<br>Can I think of some arguments that are objective? Mixed relops are used=
 rarely, compared to other parts of the interface.</div></blockquote><div><=
br></div><div>Let me attempt to branch the discussion here.<br><br></div>

<div>*ordering* relops are used rarely.<br></div><div>*equality* relops are=
 used quite often.<br><br></div><div>Having said that, let me add that IME,=
 the usage of one or other kind of relops is NOT significantly different in=
 the homogeneous case vs the heterogeneous case.<br>

<br></div><div>That is, *it is not* the case, again IME, that&nbsp; "opt re=
lop opt" is significantly more common than "opt relop T"<br><br>I know that=
 statement sets an unproven fact, but it is nonetheless a fact that is tota=
lly fundamental for the current discussion. <br></div></div></div></div></b=
lockquote><div><br>Well, perhaps the difference in opinion results primaril=
y from the usage experience. My experience appears to be quite different. G=
iven the examples you provided earlier, and the above statements, I am incl=
ined to think that if I used boost::optional the way you do, I would probab=
ly share the same opinion that you have on mixed ordering and mixed equalit=
y.<br><br>&nbsp;<br></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>

</div><div><br></div><div><br>&nbsp;</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv> Perhaps using the not-immediately-obvious operator to handle rare use c=
ases is encouraging misuses. It is different for operator*, because users h=
ave to learn it the first day. They may never have time to read the entire =
manual, and when they see it in the code, they will mistakenly take it for =
T &lt; T. So the argument here would be "tricky meaning for rare cases". Pe=
rhaps a descriptive name instead of operators would provide a better trade-=
off between safety and usability.<br>

<br>Anyway, I do not expect I can convince anybody with this argument. At l=
east I am now better able to explain my position. It is not "refactoring sa=
fety" anymore. It is "improved NaN" feature.<br><br>

</div></blockquote><div><br></div><div>OK, but, how is the improved NaN fea=
ture affected differently by *mixed* relops as opposed to (homogeneous) rel=
ops ?<br></div></div></div></div></blockquote><div><br>Homogenous ordering =
also compromises the improved NaN feature. I guess the reason I do not comp=
lain about homogenous ordering is that I never ever had to use it directly.=
 I only needed it for making std::set&lt;boost::optional&lt;T&gt;&gt; to wo=
rk. Again, this boils down to the individual's usage experience. In contras=
t, I used mixed ordering only once in my experience, and it was by mistake:=
 I really intended to compare two T's.<br><br>&nbsp;<br></div><blockquote c=
lass=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_q=
uote"><div></div><br></div><div class=3D"gmail_quote">Still after all that =
has been said, I remain in the position that, <br>

<br></div><div class=3D"gmail_quote">*provided* opt &lt; opt is OK,&nbsp; t=
hen so is opt &lt; make_optional&lt;t&gt;, and then, I still fail to see wh=
y opt &lt; t would not be exactly equally OK.<br></div></div></div></blockq=
uote><div><br>The only argument I can make here is different probability of=
 making a programming error. When you compare two optionals you probably do=
 it consciously. Whereas, when comparing T with optional&lt;T&gt;, it is mo=
re likely that you intended to compare two T's and forgot that one of the T=
's was actually a nullable one. I guess it is all about this probability.&n=
bsp; <br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote"><br>The only argument I've got this f=
ar is that I might want the compiler to forbid performing operations agains=
t different types. I would totally subscribe to that, in another language, =
like in C# where you cannot, for instance, even pass 1.2 to a function expe=
cting a float, something that is totally OK in C++.<br>

<br></div><div class=3D"gmail_quote">IMHO, everything else that I've read s=
o far is not *really* (again IMHO) about mixing opts and T's in a compariso=
n but about the comparisons themselves. That is a totally valid discussion,=
 but is an entirely different one.<br>

</div></div></div></blockquote><div><br>"Technically", you are right. Howev=
er, I do not entirely agree. I sense the subtle difference between allowing=
 mixed comparison and any comparison, however I admit I cannot express it o=
bjectively. I tried to explain it using the probability. <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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_650_27173749.1359499997171--

.

------=_Part_794_29957034.1359500779513
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu wtorek, 29 stycznia 2013 23:38:38 UTC+1 u=BFytkownik Fernando Caccio=
la=20
napisa=B3:
>
> On Tue, Jan 29, 2013 at 8:12 PM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>
> > wrote
>>
>>
>> Or we could give you an alternative option:
>>
>> less_with_nullopt(opt, 5);
>>
>> It is longer to type, but (1) it is as efficient as a mixed relop can be=
=20
>> and (2) you will not mess with the Boolean expression.
>>
>
>  I'm not at all against these sort of functions, but, why are they being=
=20
> considered in the context of mixed relops??
>

The alternative to providing mixed relops -- that I am considering -- is to=
=20
poison them but at the same time offer functions like less_with_nullopt, so=
=20
that people who do not like complicated boolean expressions in=20
if-statements and do not want to pay the run-time penalty are not hit too=
=20
much by the poisoning.


> IOW, if I ever want to be explicit about how disengaged compares against=
=20
> engaged by using a function (which is a good idea, no doubt), then I will=
=20
> want that regardless of whether I have both arguments already being=20
> optionals or not.
>
> That is, unless I'm missing something obvious, if I would write:
>
> less_with_nullopt(opt, 5);
>
> then I would just as well write
>
> less_with_nullopt(opt1, opt2);
>
> I don't see how the fact that one of the operands is a T and not an=20
> optional<> changes the usability of such a function.
>

True, you could use it with two optionals, but there is no value added=20
compared to opt1 < opt2. In case of mixed types the value added is=20
significant in case mixed relops are poisoned.=20


> (which brings me to repeat what I have been saying... let's not confuse=
=20
> anymore the arguments about mixing operands with the arguments about the=
=20
> semantics of comparing optionals)
>

I do not feel I am really confusing the arguments. I feel the mixed relops=
=20
are different than homogenous ones, although the difference is=20
"quantitative" rather than "qualitative".

--=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/?hl=3Den.



------=_Part_794_29957034.1359500779513
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu wtorek, 29 stycznia 2013 23:38:38 UTC+1 u=BFytkownik Fernand=
o Cacciola napisa=B3:<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"><div><div class=3D"gmail_quote">On Tue, Jan 29, 2013 at 8:12 PM, A=
ndrzej Krzemie=F1ski <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"obPBtMPluXQJ">akrz...@gmail.com</a>&gt=
;</span> wrote<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div><br>Or we could give you an alternative option:<br><br>less_with_nullo=
pt(opt, 5);<br><br>It is longer to type, but (1) it is as efficient as a mi=
xed relop can be and (2) you will not mess with the Boolean expression.<br>

</div></blockquote><div><br></div><div>&nbsp;I'm not at all against these s=
ort of functions, but, why are they being considered in the context of mixe=
d relops??<br></div></div></div></div></blockquote><div><br>The alternative=
 to providing mixed relops -- that I am considering -- is to poison them bu=
t at the same time offer functions like less_with_nullopt, so that people w=
ho do not like complicated boolean expressions in if-statements and do not =
want to pay the run-time penalty are not hit too much by the poisoning.<br>=
<br></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"><di=
v><div class=3D"gmail_quote"><div><br></div><div>IOW, if I ever want to be =
explicit about how disengaged compares against engaged by using a function =
(which is a good idea, no doubt), then I will want that regardless of wheth=
er I have both arguments already being optionals or not.<br>

<br></div><div>That is, unless I'm missing something obvious, if I would wr=
ite:<br><br>less_with_nullopt(opt, 5);<br><br></div><div>then I would just =
as well write<br><br>less_with_nullopt(opt1, opt2);<br></div></div>

<br></div><div>I don't see how the fact that one of the operands is a T and=
 not an optional&lt;&gt; changes the usability of such a function.<br></div=
></div></blockquote><div><br>True, you could use it with two optionals, but=
 there is no value added compared to opt1 &lt; opt2. In case of mixed types=
 the value added is significant in case mixed relops are poisoned. <br><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><b=
r></div><div>(which brings me to repeat what I have been saying... let's no=
t confuse anymore the arguments about mixing operands with the arguments ab=
out the semantics of comparing optionals)<br></div></div></blockquote><div>=
<br>I do not feel I am really confusing the arguments. I feel the mixed rel=
ops are different than homogenous ones, although the difference is "quantit=
ative" rather than "qualitative".<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_794_29957034.1359500779513--

.

On Tue, Jan 29, 2013 at 11:51 PM, Matias Capeletto
<matias.capeletto@gmail.com> wrote:
> [Always taking about <, <=, > and >= here]
>
> I kind of like your line of thinking:
> [1] op < op  => [2] op < optional<int>(5) => [3] op < 5
> ...
> We can not forbid [2] because that will imply no [1]. So we will have
> to live with op < optional<int>(5).
> But we can force users to choose instead of given them [3]. I think
> that the compiler error there will annoy people at first but it will
> avoid bugs in user code that are not easy at all to spot. And there
> have been several options presented to give the user terse and clear
> syntax in replacement of the mix relops.

Some more examples of mix-relops ill posed code:

// Wrong result, seems natural, but it returns false if width or
height is nullopt
bool fits_in( figure f, optional<double> width, optional<double> height ) {
  auto bbox = get_bbox(f);
  return bbox.width() < width && bbox.height() < height ;
}

// Invalid inderection, this would have been nice to catch at compile time
void constraint_size( figure f, optional<double> width,
optional<double> height ) {
  auto bbox = get_bbox(f);
  double sx = ( width  < bbox.width () ) ? *width /bbox.width () : 1.0;
  double sy = ( height < bbox.height() ) ? *height/bbox.height() : 1.0;
  scale(f,sx,sy);
}

About op-op inequality comparison, they are a must need for working
with containers but they may not even the best choice for all use
cases when querying the assoc. containers. For example, if N3465 (
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3465.pdf )
gets into the standard then we could write code like:

  set<optional<T>> opt_set;
  ...
  // Make sure we do not have nullopts in the set
  opt_set.remove(begin(opt_set),opt_set.upper_bound(nullopt));

  // Direct find, we do not want the optional relops to kick in for
performance reason
  // Here there is no conversion from 4 to optional<4> and the T-T
relops are used.
  if( opt_set.find( 4, indirect_mixed_less<T>() ) != opt_set.end() ) {
    ...
  }

Where:

template<class T>
struct indirect_mixed_less {
  bool operator()( optional<T> const& op, T const& t ) const { return
*op < t; }
  bool operator()( T const& t, optional<T> const& op ) const { return
t < *op; }
};

Best regards
Matias

--

---
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/?hl=en.



.

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



On 2013/01/29 07:58 +0900, Andrzej Krzemie=C5=84ski wrote:

...., perhaps less-than comparisonis primarily about order, and nothing else=
..  ...


Is the validity of std::set<std::optional<T>>, without specifying
ordering type argument, so strong requirement?

Now I think it can be a reasonable choice of design to require
specifying ordering for the use of std::set, which is "ordered set" in
fact. For casual users who don't care about ordering, they can likely be
satisfied with std::unordered_set<optional<T>>, I think.

Please look the following pseudo codes to get my idea. I'm tempted to
propose this to break the never-meeting discussion about mixed relops.

namespace std {

template<typename T> struct optional { ... };

// Provide operator =3D=3D, !=3D to avoid unnecessary implicit conversions.
....

// Poison operator <, <=3D, >, >=3D via implicit conversions, since they
// don't know which side they should order nullopt, least or greatest.
....

// **NEW**
// Functional type for ordering which supports 3x3 overload among
// [T, optional<T>, nullopt_t] to avoid unnecessary implicit conversion.
// This can be used explicitly as the comparator for std::set,
// std::sort, ... etc.
template<typename T> struct order_nullopt_least { ... };
// Ditto, with opposite ordering of nullopt.
template<typename T> struct order_nullopt_greatest { ... };

}

// The use.
std::set<optional<T>, std::order_nullopt_least<T>> nullopt_at_start;
std::set<optional<T>, std::order_nullopt_greatest<T>> nullopt_at_last;

// Looks awful? Then probably you want this in fact.
std::unordered_set<optional<T>> yeah;


--=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/?hl=3Den.



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

<pre wrap=3D"">On 2013/01/29 07:58 +0900, Andrzej Krzemie=C5=84ski wrote:
</pre><blockquote type=3D"cite" style=3D"color: #000000;"><pre wrap=3D"">..=
.., perhaps less-than comparison
<span class=3D"moz-txt-citetags"></span>is primarily about order, and nothi=
ng else.  ...
</pre></blockquote><pre wrap=3D""><br>Is the validity of std::set&lt;std::o=
ptional&lt;T&gt;&gt;, without specifying
ordering type argument, so strong requirement?

Now I think it can be a reasonable choice of design to require
specifying ordering for the use of std::set, which is "ordered set" in
fact. For casual users who don't care about ordering, they can likely be
satisfied with std::unordered_set&lt;optional&lt;T&gt;&gt;, I think.

Please look the following pseudo codes to get my idea. I'm tempted to
propose this to break the never-meeting discussion about mixed relops.

namespace std {

template&lt;typename T&gt; struct optional { ... };

// Provide operator =3D=3D, !=3D to avoid unnecessary implicit conversions.
....

// Poison operator &lt;, &lt;=3D, &gt;, &gt;=3D via implicit conversions, s=
ince they
// don't know which side they should order nullopt, least or greatest.
....

// <b class=3D"moz-txt-star"><span class=3D"moz-txt-tag">*</span>NEW<span c=
lass=3D"moz-txt-tag">*</span></b>
// Functional type for ordering which supports 3x3 overload among
// [T, optional&lt;T&gt;, nullopt_t] to avoid unnecessary implicit conversi=
on.
// This can be used explicitly as the comparator for std::set,
// std::sort, ... etc.
template&lt;typename T&gt; struct order_nullopt_least { ... };
// Ditto, with opposite ordering of nullopt.
template&lt;typename T&gt; struct order_nullopt_greatest { ... };

}

// The use.
std::set&lt;optional&lt;T&gt;, std::order_nullopt_least&lt;T&gt;&gt; nullop=
t_at_start;
std::set&lt;optional&lt;T&gt;, std::order_nullopt_greatest&lt;T&gt;&gt; nul=
lopt_at_last;

// Looks awful? Then probably you want this in fact.
std::unordered_set&lt;optional&lt;T&gt;&gt; yeah;

</pre>

<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_685_11033462.1359517440992--

.

------=_Part_58_24938022.1359535034332
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu =B6roda, 30 stycznia 2013 04:44:00 UTC+1 u=BFytkownik Kazutoshi SATO=
DA=20
napisa=B3:
>
> On 2013/01/29 07:58 +0900, Andrzej Krzemie=F1ski wrote:
>
> ..., perhaps less-than comparisonis primarily about order, and nothing el=
se.  ...
>
>
> Is the validity of std::set<std::optional<T>>, without specifying
> ordering type argument, so strong requirement?
>
> Now I think it can be a reasonable choice of design to require
> specifying ordering for the use of std::set, which is "ordered set" in
> fact. For casual users who don't care about ordering, they can likely be
> satisfied with std::unordered_set<optional<T>>, I think.
>
> Please look the following pseudo codes to get my idea. I'm tempted to
> propose this to break the never-meeting discussion about mixed relops.
>
> namespace std {
>
> template<typename T> struct optional { ... };
>
> // Provide operator =3D=3D, !=3D to avoid unnecessary implicit conversion=
s.
> ...
>
> // Poison operator <, <=3D, >, >=3D via implicit conversions, since they
> // don't know which side they should order nullopt, least or greatest.
> ...
>
> // **NEW**
> // Functional type for ordering which supports 3x3 overload among
> // [T, optional<T>, nullopt_t] to avoid unnecessary implicit conversion.
> // This can be used explicitly as the comparator for std::set,
> // std::sort, ... etc.
> template<typename T> struct order_nullopt_least { ... };
> // Ditto, with opposite ordering of nullopt.
> template<typename T> struct order_nullopt_greatest { ... };
>
> }
>
> // The use.
> std::set<optional<T>, std::order_nullopt_least<T>> nullopt_at_start;
> std::set<optional<T>, std::order_nullopt_greatest<T>> nullopt_at_last;
>
> // Looks awful? Then probably you want this in fact.
> std::unordered_set<optional<T>> yeah;
>
>
I get the idea. While this is definitely type-safe, or just safe, it may=20
make optional scary for the beginners. If they want to use map<optional<T>>=
=20
and they start learning al these order_nullopt_least things they will=20
switch to map<T*>. It is valid to expect "just give me the default=20
ordering".

Note also that even though the discussion is long and is not converging to=
=20
a consensus, it does not stop us from presenting a proposal to the=20
Committee. Our plan is to just make an arbitrary call for one option (say=
=20
enabling mixed relops) and provide the second one as an "auxiliary"=20
proposal. We let the Committee decide. The goal of this thread is primarily=
=20
to collect sound arguments in favor and against either option and present=
=20
them in the proposal.=20

If we reach a consensus it is even better, but I treat it as a bonus.

--=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/?hl=3Den.



------=_Part_58_24938022.1359535034332
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu =B6roda, 30 stycznia 2013 04:44:00 UTC+1 u=BFytkownik Kazuto=
shi SATODA napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><pre>On 2=
013/01/29 07:58 +0900, Andrzej Krzemie=F1ski wrote:
</pre><blockquote type=3D"cite" style=3D"color:#000000"><pre>..., perhaps l=
ess-than comparison
<span></span>is primarily about order, and nothing else.  ...
</pre></blockquote><pre><br>Is the validity of std::set&lt;std::optional&lt=
;T&gt;&gt;, without specifying
ordering type argument, so strong requirement?

Now I think it can be a reasonable choice of design to require
specifying ordering for the use of std::set, which is "ordered set" in
fact. For casual users who don't care about ordering, they can likely be
satisfied with std::unordered_set&lt;optional&lt;T&gt;<wbr>&gt;, I think.

Please look the following pseudo codes to get my idea. I'm tempted to
propose this to break the never-meeting discussion about mixed relops.

namespace std {

template&lt;typename T&gt; struct optional { ... };

// Provide operator =3D=3D, !=3D to avoid unnecessary implicit conversions.
....

// Poison operator &lt;, &lt;=3D, &gt;, &gt;=3D via implicit conversions, s=
ince they
// don't know which side they should order nullopt, least or greatest.
....

// <b><span>*</span>NEW<span>*</span></b>
// Functional type for ordering which supports 3x3 overload among
// [T, optional&lt;T&gt;, nullopt_t] to avoid unnecessary implicit conversi=
on.
// This can be used explicitly as the comparator for std::set,
// std::sort, ... etc.
template&lt;typename T&gt; struct order_nullopt_least { ... };
// Ditto, with opposite ordering of nullopt.
template&lt;typename T&gt; struct order_nullopt_greatest { ... };

}

// The use.
std::set&lt;optional&lt;T&gt;, std::order_nullopt_least&lt;T&gt;&gt; nullop=
t_at_start;
std::set&lt;optional&lt;T&gt;, std::order_nullopt_greatest&lt;T&gt;<wbr>&gt=
; nullopt_at_last;

// Looks awful? Then probably you want this in fact.
std::unordered_set&lt;optional&lt;T&gt;<wbr>&gt; yeah;
</pre></blockquote><div><br>I get the idea. While this is definitely type-s=
afe, or just safe, it may make optional scary for the beginners. If they wa=
nt to use map&lt;optional&lt;T&gt;&gt; and they start learning al these ord=
er_nullopt_least things they will switch to map&lt;T*&gt;. It is valid to e=
xpect "just give me the default ordering".<br><br>Note also that even thoug=
h the discussion is long and is not converging to a consensus, it does not =
stop us from presenting a proposal to the Committee. Our plan is to just ma=
ke an arbitrary call for one option (say enabling mixed relops) and provide=
 the second one as an "auxiliary" proposal. We let the Committee decide. Th=
e goal of this thread is primarily to collect sound arguments in favor and =
against either option and present them in the proposal. <br><br>If we reach=
 a consensus it is even better, but I treat it as a bonus.<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_58_24938022.1359535034332--

.

On Wed, Jan 30, 2013 at 9:37 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
> I get the idea. While this is definitely type-safe, or just safe, it may
> make optional scary for the beginners. If they want to use map<optional<T=
>>
> and they start learning al these order_nullopt_least things they will swi=
tch
> to map<T*>. It is valid to expect "just give me the default ordering".

Why would beginners put optionals in maps and sets?
Who has put optionals in maps and sets? Real-world code example? ;)
Using map<optional<T>, U, optional_less<T>> doesn't seem unreasonable.



--=20
Olaf

--=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/?hl=3Den.



.

On 30/01/13 09:18, Olaf van der Spek wrote:
> On Wed, Jan 30, 2013 at 9:37 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail=
..com> wrote:
>> I get the idea. While this is definitely type-safe, or just safe, it may
>> make optional scary for the beginners. If they want to use map<optional<=
T>>
>> and they start learning al these order_nullopt_least things they will sw=
itch
>> to map<T*>. It is valid to expect "just give me the default ordering".
> Why would beginners put optionals in maps and sets?
> Who has put optionals in maps and sets? Real-world code example? ;)

I have. Just as I am reading this email, I am working on a function with=20
a set<vector<optional<set<int>>>>. I find it very natural and usable.

> Using map<optional<T>, U, optional_less<T>> doesn't seem unreasonable.
Providing things such as "optional_less" looks useless to me, as I need=20
to order the vectors in the outer set, and vector uses < on it's members=20
for it's <, so I would have to implement a new "optional_less" for=20
vector<optional<T>>, which I don't really want to do.

Chris

--=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/?hl=3Den.



.

On 2013/01/30 19:19 +0900, Chris Jefferson wrote:
> On 30/01/13 09:18, Olaf van der Spek wrote:
>> Why would beginners put optionals in maps and sets?
>> Who has put optionals in maps and sets? Real-world code example? ;)
>
> I have. Just as I am reading this email, I am working on a function with
> a set<vector<optional<set<int>>>>. I find it very natural and usable.
>
> Using map<optional<T>, U, optional_less<T>> doesn't seem unreasonable.
> Providing things such as "optional_less" looks useless to me, as I need
> to order the vectors in the outer set, and vector uses < on it's members
> for it's <, so I would have to implement a new "optional_less" for
> vector<optional<T>>, which I don't really want to do.

Do you really want "ordered"-set there? In other words, what is the
problem to use unordered_set<vector<optional<set<int>>>> there?

I think of C++03 compatibility where unordered_set is not standardized
yet. But it doesn't count here, in context of std-proposal for post
C++11 standard which has them.


As I mentioned in the previous post, I think std::unordered_set and
std::unordered_map will lower the needs of the default (but arbitrary)
ordering (much, I think). But I don't have seen any consideration
about them in discussion so far. So I want to hear what others think
about them.

--
k_satoda

--

---
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/?hl=en.



.

On 30/01/13 13:30, Kazutoshi Satoda wrote:
> On 2013/01/30 19:19 +0900, Chris Jefferson wrote:
>> On 30/01/13 09:18, Olaf van der Spek wrote:
>>> Why would beginners put optionals in maps and sets?
>>> Who has put optionals in maps and sets? Real-world code example? ;)
>>
>> I have. Just as I am reading this email, I am working on a function with
>> a set<vector<optional<set<int>>>>. I find it very natural and usable.
>>
>> Using map<optional<T>, U, optional_less<T>> doesn't seem unreasonable.
>> Providing things such as "optional_less" looks useless to me, as I need
>> to order the vectors in the outer set, and vector uses < on it's members
>> for it's <, so I would have to implement a new "optional_less" for
>> vector<optional<T>>, which I don't really want to do.
>
> Do you really want "ordered"-set there? In other words, what is the
> problem to use unordered_set<vector<optional<set<int>>>> there?

Yes, I do want a std::set here, as I require stability as I insert and
remove values from the set.

> I think of C++03 compatibility where unordered_set is not standardized
> yet. But it doesn't count here, in context of std-proposal for post
> C++11 standard which has them.
>
>
> As I mentioned in the previous post, I think std::unordered_set and
> std::unordered_map will lower the needs of the default (but arbitrary)
> ordering (much, I think). But I don't have seen any consideration
> about them in discussion so far. So I want to hear what others think
> about them.

For many of my purposes (which are specialised, but aren't everyone's?)
unordered_set is not an appropriate replacement for set.

Also remember there are other needs for <. I also sort a
vector<vector<optional<int>>> in my current program.

Personally, I notice I rarely use '<' directly on two optionals, I
frequently use < indirectly, like putting in a std::set, std::sort,
ordering of std::vectors and std::tuples which contain optionals.

Chris

--

---
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/?hl=en.



.

On 2013/01/30 22:39 +0900, Chris Jefferson wrote:
> On 30/01/13 13:30, Kazutoshi Satoda wrote:
>> On 2013/01/30 19:19 +0900, Chris Jefferson wrote:
>>> a set<vector<optional<set<int>>>>. I find it very natural and usable.
>>>
>>> Using map<optional<T>, U, optional_less<T>> doesn't seem unreasonable.
>>> Providing things such as "optional_less" looks useless to me, as I need
>>> to order the vectors in the outer set, and vector uses < on it's members
>>> for it's <, so I would have to implement a new "optional_less" for
>>> vector<optional<T>>, which I don't really want to do.
>>
>> Do you really want "ordered"-set there? In other words, what is the
>> problem to use unordered_set<vector<optional<set<int>>>> there?
>
> Yes, I do want a std::set here, as I require stability as I insert and
> remove values from the set.

If your "stability" means preserved order of other elements, or
iterator stability, I agree that it's a real problem.

FYI, I found that unordered assoc containers provide memory
(reference and pointer) stability, and can be prepared to provide
iterator stability with reserve() or rehash().
(23.2.5 [unord.req] p13,14)

> Also remember there are other needs for <. I also sort a
> vector<vector<optional<int>>> in my current program.

For that case, I can't give an easy alternative now.

Only I could thought of was an additional overload in
order_nullopt_...<T> for containers of which value_type is
optional<T>, to enable to write:
     vector<vector<optional<int>>> v;
     sort(v, v, order_nullopt_least<int>{});
.. But there will likely be uncountable cases which can't be covered
with that.

> Personally, I notice I rarely use '<' directly on two optionals, I
> frequently use < indirectly, like putting in a std::set, std::sort,
> ordering of std::vectors and std::tuples which contain optionals.

Yes, I also learned that there are many places where operator < is
used in standard library components under the hood. Thank you for the
quick answer.

Then, as long as these indirect but wide-spread use of operator <
stands, it seems preferred to provide a default ordering on
std::optional<T> with operator <, provided that the ordering is clearly
specified at some places where it's hard to miss it. For example,
define the default ordering at the same section (sentence?) of the
definition of "disengaged" state.

Now my current tastes are:
   o  homogeneous operator ==, !=
   o  mixed operator ==, !=
   o  homogeneous operator <, <=, >, >=
   x  mixed operator <, <=, >, >=

--
k_satoda

--

---
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/?hl=en.



.

------=_Part_2566_20778130.1359563997029
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu =B6roda, 30 stycznia 2013 00:06:19 UTC+1 u=BFytkownik Andrzej=20
Krzemie=F1ski napisa=B3:
>
>
>
> W dniu wtorek, 29 stycznia 2013 23:38:38 UTC+1 u=BFytkownik Fernando=20
> Cacciola napisa=B3:
>>
>> On Tue, Jan 29, 2013 at 8:12 PM, Andrzej Krzemie=F1ski <akrz...@gmail.co=
m>wrote
>>>
>>>
>>> Or we could give you an alternative option:
>>>
>>> less_with_nullopt(opt, 5);
>>>
>>> It is longer to type, but (1) it is as efficient as a mixed relop can b=
e=20
>>> and (2) you will not mess with the Boolean expression.
>>>
>>
>>  I'm not at all against these sort of functions, but, why are they being=
=20
>> considered in the context of mixed relops??
>>
>
> The alternative to providing mixed relops -- that I am considering -- is=
=20
> to poison them but at the same time offer functions like less_with_nullop=
t,=20
> so that people who do not like complicated boolean expressions in=20
> if-statements and do not want to pay the run-time penalty are not hit too=
=20
> much by the poisoning.
>
>
>> IOW, if I ever want to be explicit about how disengaged compares against=
=20
>> engaged by using a function (which is a good idea, no doubt), then I wil=
l=20
>> want that regardless of whether I have both arguments already being=20
>> optionals or not.
>>
>> That is, unless I'm missing something obvious, if I would write:
>>
>> less_with_nullopt(opt, 5);
>>
>> then I would just as well write
>>
>> less_with_nullopt(opt1, opt2);
>>
>> I don't see how the fact that one of the operands is a T and not an=20
>> optional<> changes the usability of such a function.
>>
>
> True, you could use it with two optionals, but there is no value added=20
> compared to opt1 < opt2. In case of mixed types the value added is=20
> significant in case mixed relops are poisoned.=20
>
>
>> (which brings me to repeat what I have been saying... let's not confuse=
=20
>> anymore the arguments about mixing operands with the arguments about the=
=20
>> semantics of comparing optionals)
>>
>
> I do not feel I am really confusing the arguments. I feel the mixed relop=
s=20
> are different than homogenous ones, although the difference is=20
> "quantitative" rather than "qualitative".
>

Now I start to understand something (which was probably obvious to others):=
=20
with optional we are proposing two opposite features: (1) an "improved NaN"=
=20
and (2) "just another value of T". The former begs for syntactic difference=
=20
when accessing the special value (the main purpose of optional). The latter=
=20
begs for a uniform handling of nullopt with other values: hence the=20
implicit conversion, assignment from T, relops. The two goals are=20
incompatible of one another, and we are trying to squeeze both features. I=
=20
do not necessarily say it is undesired or not doable, but finding the=20
balance will be very tricky.

--=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/?hl=3Den.



------=_Part_2566_20778130.1359563997029
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu =B6roda, 30 stycznia 2013 00:06:19 UTC+1 u=BFytkownik Andrze=
j Krzemie=F1ski napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>=
<br>W dniu wtorek, 29 stycznia 2013 23:38:38 UTC+1 u=BFytkownik Fernando Ca=
cciola 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><div class=3D"gmail_quote">On Tue, Jan 29, 2013 at 8:12 PM, Andrzej Krz=
emie=F1ski <span dir=3D"ltr">&lt;<a>akrz...@gmail.com</a>&gt;</span> wrote<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">

<div><br>Or we could give you an alternative option:<br><br>less_with_nullo=
pt(opt, 5);<br><br>It is longer to type, but (1) it is as efficient as a mi=
xed relop can be and (2) you will not mess with the Boolean expression.<br>

</div></blockquote><div><br></div><div>&nbsp;I'm not at all against these s=
ort of functions, but, why are they being considered in the context of mixe=
d relops??<br></div></div></div></div></blockquote><div><br>The alternative=
 to providing mixed relops -- that I am considering -- is to poison them bu=
t at the same time offer functions like less_with_nullopt, so that people w=
ho do not like complicated boolean expressions in if-statements and do not =
want to pay the run-time penalty are not hit too much by the poisoning.<br>=
<br></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><di=
v class=3D"gmail_quote"><div><br></div><div>IOW, if I ever want to be expli=
cit about how disengaged compares against engaged by using a function (whic=
h is a good idea, no doubt), then I will want that regardless of whether I =
have both arguments already being optionals or not.<br>

<br></div><div>That is, unless I'm missing something obvious, if I would wr=
ite:<br><br>less_with_nullopt(opt, 5);<br><br></div><div>then I would just =
as well write<br><br>less_with_nullopt(opt1, opt2);<br></div></div>

<br></div><div>I don't see how the fact that one of the operands is a T and=
 not an optional&lt;&gt; changes the usability of such a function.<br></div=
></div></blockquote><div><br>True, you could use it with two optionals, but=
 there is no value added compared to opt1 &lt; opt2. In case of mixed types=
 the value added is significant in case mixed relops are poisoned. <br><br>=
</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><br></d=
iv><div>(which brings me to repeat what I have been saying... let's not con=
fuse anymore the arguments about mixing operands with the arguments about t=
he semantics of comparing optionals)<br></div></div></blockquote><div><br>I=
 do not feel I am really confusing the arguments. I feel the mixed relops a=
re different than homogenous ones, although the difference is "quantitative=
" rather than "qualitative".<br></div></blockquote><div><br></div><div>Now =
I start to understand something (which was probably obvious to others): wit=
h optional we are proposing two opposite features: (1) an "improved NaN" an=
d (2) "just another value of T". The former begs for syntactic difference w=
hen accessing the special value (the main purpose of optional). The latter =
begs for a uniform handling of nullopt with other values: hence the implici=
t conversion, assignment from T, relops. The two goals are incompatible of =
one another, and we are trying to squeeze both features. I do not necessari=
ly say it is undesired or not doable, but finding the balance will be very =
tricky.</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2566_20778130.1359563997029--

.

On Wed, Jan 30, 2013 at 8:39 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
 wrote:
>
>
> W dniu =B6roda, 30 stycznia 2013 00:06:19 UTC+1 u=BFytkownik Andrzej Krze=
mie=F1ski
> napisa=B3:
>>
>>
>>
>> W dniu wtorek, 29 stycznia 2013 23:38:38 UTC+1 u=BFytkownik Fernando
>> Cacciola napisa=B3:
>>>
>>> On Tue, Jan 29, 2013 at 8:12 PM, Andrzej Krzemie=F1ski <akrz...@gmail.c=
om>
>>> wrote
>>>>
>>>>
>>>> Or we could give you an alternative option:
>>>>
>>>> less_with_nullopt(opt, 5);
>>>>
>>>> It is longer to type, but (1) it is as efficient as a mixed relop can =
be
>>>> and (2) you will not mess with the Boolean expression.
>>>
>>>
>>>  I'm not at all against these sort of functions, but, why are they bein=
g
>>> considered in the context of mixed relops??
>>
>>
>> The alternative to providing mixed relops -- that I am considering -- is
>> to poison them but at the same time offer functions like less_with_nullo=
pt,
>> so that people who do not like complicated boolean expressions in
>> if-statements and do not want to pay the run-time penalty are not hit to=
o
>> much by the poisoning.
>>
>>>
>>> IOW, if I ever want to be explicit about how disengaged compares agains=
t
>>> engaged by using a function (which is a good idea, no doubt), then I wi=
ll
>>> want that regardless of whether I have both arguments already being
>>> optionals or not.
>>>
>>> That is, unless I'm missing something obvious, if I would write:
>>>
>>> less_with_nullopt(opt, 5);
>>>
>>> then I would just as well write
>>>
>>> less_with_nullopt(opt1, opt2);
>>>
>>> I don't see how the fact that one of the operands is a T and not an
>>> optional<> changes the usability of such a function.
>>
>>
>> True, you could use it with two optionals, but there is no value added
>> compared to opt1 < opt2. In case of mixed types the value added is
>> significant in case mixed relops are poisoned.
>>
>>>
>>> (which brings me to repeat what I have been saying... let's not confuse
>>> anymore the arguments about mixing operands with the arguments about th=
e
>>> semantics of comparing optionals)
>>
>>
>> I do not feel I am really confusing the arguments. I feel the mixed relo=
ps
>> are different than homogenous ones, although the difference is
>> "quantitative" rather than "qualitative".
>
>
> Now I start to understand something (which was probably obvious to others=
):
> with optional we are proposing two opposite features: (1) an "improved Na=
N"
> and (2) "just another value of T". The former begs for syntactic differen=
ce
> when accessing the special value (the main purpose of optional). The latt=
er
> begs for a uniform handling of nullopt with other values: hence the impli=
cit
> conversion, assignment from T, relops. The two goals are incompatible of =
one
> another, and we are trying to squeeze both features. I do not necessarily
> say it is undesired or not doable, but finding the balance will be very
> tricky.

I think the problem is much smaller than it appears from the length of
this discussion. If you provide mixed comparisons, I think people will
generally be fine. If you provide homogenous comparisons but poison
mixed comparisons, I think people will generally be fine. If you don't
provide homogenous comparisons, I expect the LWG to insist on them so
that optional<T> interoperates with std::set<>, but I could be wrong.

You should just write the best proposal you can, with alternatives
where you think the committee might disagree (Ville's list at [Dynamic
of a propoal] is good), and we'll discuss it in Bristol. At some point
you just have to ignore the people on this list who will argue
forever.

Jeffrey

--=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/?hl=3Den.



.

------=_Part_432_11745745.1359621742776
Content-Type: text/plain; charset=ISO-8859-1



> > Now I start to understand something (which was probably obvious to
> others):
> > with optional we are proposing two opposite features: (1) an "improved
> NaN"
> > and (2) "just another value of T". The former begs for syntactic
> difference
> > when accessing the special value (the main purpose of optional). The
> latter
> > begs for a uniform handling of nullopt with other values: hence the
> implicit
> > conversion, assignment from T, relops. The two goals are incompatible of
> one
> > another, and we are trying to squeeze both features. I do not
> necessarily
> > say it is undesired or not doable, but finding the balance will be very
> > tricky.
>
> I think the problem is much smaller than it appears from the length of
> this discussion. If you provide mixed comparisons, I think people will
> generally be fine. If you provide homogenous comparisons but poison
> mixed comparisons, I think people will generally be fine. If you don't
> provide homogenous comparisons, I expect the LWG to insist on them so
> that optional<T> interoperates with std::set<>, but I could be wrong.
>
> You should just write the best proposal you can, with alternatives
> where you think the committee might disagree (Ville's list at [Dynamic
> of a propoal] is good), and we'll discuss it in Bristol. At some point
> you just have to ignore the people on this list who will argue
> forever.
>

I would like to run through you a yet another possible solution to ordering
suggested by Vicente J. Botet Escriba in the other thread. In short,
whether the nullopt state is least of all T's or greatest of all T's is
implementation-defined. This way, you are guaranteed that ordered
containers work, but you cannot rely on the results, when using LessThan
comparison manually. This also implies that you cannot use mixed ordering
in most of the cases, and it becomes more natural to poison them.

The only problem I perceive that the users will not notice that they cannot
rely on the ordering on nullopt, and will still decide to rely on it, which
will work on their platform, but will render the code non-portable.

I would like to hear your opinion..

Regards,
&rzej

--

---
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/?hl=en.



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

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Now I start to unders=
tand something (which was probably obvious to others):
<br>&gt; with optional we are proposing two opposite features: (1) an "impr=
oved NaN"
<br>&gt; and (2) "just another value of T". The former begs for syntactic d=
ifference
<br>&gt; when accessing the special value (the main purpose of optional). T=
he latter
<br>&gt; begs for a uniform handling of nullopt with other values: hence th=
e implicit
<br>&gt; conversion, assignment from T, relops. The two goals are incompati=
ble of one
<br>&gt; another, and we are trying to squeeze both features. I do not nece=
ssarily
<br>&gt; say it is undesired or not doable, but finding the balance will be=
 very
<br>&gt; tricky.
<br>
<br>I think the problem is much smaller than it appears from the length of
<br>this discussion. If you provide mixed comparisons, I think people will
<br>generally be fine. If you provide homogenous comparisons but poison
<br>mixed comparisons, I think people will generally be fine. If you don't
<br>provide homogenous comparisons, I expect the LWG to insist on them so
<br>that optional&lt;T&gt; interoperates with std::set&lt;&gt;, but I could=
 be wrong.
<br>
<br>You should just write the best proposal you can, with alternatives
<br>where you think the committee might disagree (Ville's list at [Dynamic
<br>of a propoal] is good), and we'll discuss it in Bristol. At some point
<br>you just have to ignore the people on this list who will argue
<br>forever.
<br></blockquote><div><br></div><div>I would like to run through you a yet =
another possible solution to ordering suggested by&nbsp;Vicente J. Botet Es=
criba in the other thread. In short, whether the nullopt state is least of =
all T's or greatest of all T's is implementation-defined. This way, you are=
 guaranteed that ordered containers work, but you cannot rely on the result=
s, when using LessThan comparison manually. This also implies that you cann=
ot use mixed ordering in most of the cases, and it becomes more natural to =
poison them.</div><div><br></div><div>The only problem I perceive that the =
users will not notice that they cannot rely on the ordering on nullopt, and=
 will still decide to rely on it, which will work on their platform, but wi=
ll render the code non-portable.</div><div><br></div><div>I would like to h=
ear your opinion..</div><div><br></div><div>Regards,</div><div>&amp;rzej</d=
iv>

<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_432_11745745.1359621742776--

.

On 31 January 2013 10:42, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:
> I would like to run through you a yet another possible solution to orderi=
ng
> suggested by Vicente J. Botet Escriba in the other thread. In short, whet=
her
> the nullopt state is least of all T's or greatest of all T's is
> implementation-defined. This way, you are guaranteed that ordered contain=
ers
> work, but you cannot rely on the results, when using LessThan comparison
> manually. This also implies that you cannot use mixed ordering in most of
> the cases, and it becomes more natural to poison them.

I have a bad feeling about this..

> The only problem I perceive that the users will not notice that they cann=
ot
> rely on the ordering on nullopt, and will still decide to rely on it, whi=
ch
> will work on their platform, but will render the code non-portable.

...and I find this unacceptable. It's a heinous beartrap. If users can't rel=
y on
the ordering in a portable manner, disable the ordering. Please don't place
such traps into it. And, since we really don't want to disable ordering, le=
t's
not make it implementation-specific. We have enough of that disease
already, and enough is enough.

--=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/?hl=3Den.



.

> I would like to run through you a yet another possible solution to
> ordering
> suggested by Vicente J. Botet Escriba in the other thread. In short,
> whether the nullopt state is least of all T's or greatest of all T's is
> implementation-defined. This way, you are guaranteed that ordered
> containers work, but you cannot rely on the results, when using LessThan
> comparison manually.

What does this brings excepted unreliability?

I've already negative feelings about implementation defined things
which were made implementation defined in order to take into account
rare implementations.

I'm strongly against making something implementation defined for the
sake of making things unreliable.

Yours,

--
Jean-Marc

--

---
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/?hl=en.



.

------=_Part_526_32760598.1359629430145
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 31 stycznia 2013 10:53:09 UTC+1 u=BFytkownik Jean-Marc=20
Bourguet napisa=B3:
>
> > I would like to run through you a yet another possible solution to=20
> > ordering=20
> > suggested by Vicente J. Botet Escriba in the other thread. In short,=20
> > whether the nullopt state is least of all T's or greatest of all T's is=
=20
> > implementation-defined. This way, you are guaranteed that ordered=20
> > containers work, but you cannot rely on the results, when using LessTha=
n=20
> > comparison manually.=20
>
> What does this brings excepted unreliability?=20
>

I guess, the intention is that "manual" ordering is unreliable, therefore=
=20
you are discouraged from using it, while storage in tree-based containers=
=20
is perfectly reliable (unless you marshal and de-marshal the containers=20
across two platforms).

But I do not intend to propose this. I was just wondering about the=20
community's opinion. And I got it :)


> I've already negative feelings about implementation defined things=20
> which were made implementation defined in order to take into account=20
> rare implementations.=20
>
> I'm strongly against making something implementation defined for the=20
> sake of making things unreliable.=20
>
> Yours,=20
>
> --=20
> Jean-Marc=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/?hl=3Den.



------=_Part_526_32760598.1359629430145
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu czwartek, 31 stycznia 2013 10:53:09 UTC+1 u=BFytkownik Jean-=
Marc Bourguet napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; I=
 would like to run through you a yet another possible solution to
<br>&gt; ordering
<br>&gt; suggested by Vicente J. Botet Escriba in the other thread. In shor=
t,
<br>&gt; whether the nullopt state is least of all T's or greatest of all T=
's is
<br>&gt; implementation-defined. This way, you are guaranteed that ordered
<br>&gt; containers work, but you cannot rely on the results, when using Le=
ssThan
<br>&gt; comparison manually.
<br>
<br>What does this brings excepted unreliability?
<br></blockquote><div><br></div><div>I guess, the intention is that "manual=
" ordering is unreliable, therefore you are discouraged from using it, whil=
e storage in tree-based containers is perfectly reliable (unless you marsha=
l and de-marshal the containers across two platforms).</div><div><br></div>=
<div>But I do not intend to propose this. I was just wondering about the co=
mmunity's opinion. And I got it :)</div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">
<br>I've already negative feelings about implementation defined things
<br>which were made implementation defined in order to take into account
<br>rare implementations.
<br>
<br>I'm strongly against making something implementation defined for the
<br>sake of making things unreliable.
<br>
<br>Yours,
<br>
<br>--=20
<br>Jean-Marc
<br>
<br></blockquote>

<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_526_32760598.1359629430145--

.

On Jan 31, 2013, at 3:53 AM, "jm@bourguet.org" <jm@bourguet.org> wrote:

> What does this brings excepted unreliability?

+1. Implementers don't need this freedom.

--

---
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/?hl=en.



.

On 31 January 2013 12:50, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:
> But I do not intend to propose this. I was just wondering about the
> community's opinion. And I got it :)

Well, not only the community's opinion; with Nevin's latest reply,
three committee members have
said "please no". ;)

--=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/?hl=3Den.



.

On Tue, Jan 29, 2013 at 7:51 PM, Matias Capeletto
<matias.capeletto@gmail.com> wrote:
> On Tue, Jan 29, 2013 at 11:26 PM, Fernando Cacciola
> <fernando.cacciola@gmail.com> wrote:
>> On Tue, Jan 29, 2013 at 7:37 PM, Matias Capeletto
>> <matias.capeletto@gmail.com> wrote:
>>> On Tue, Jan 29, 2013 at 10:07 PM, Andrzej Krzemie=C5=84ski
>>> <akrzemi1@gmail.com> wrote:
>>> > Anyway, I do not expect I can convince anybody with this argument. At
>>> > least
>>> > I am now better able to explain my position. It is not "refactoring
>>> > safety"
>>> > anymore. It is "improved NaN" feature.
>>>
>>> +1, I am also starting to think that mixed rel ops are better left
>>> aside
>>
>> Would you say that for normal relops?
>
> No, because I agree that is important to make them container friendly
> and if you are going to define less... you should define op<op as
> Nevin Liber just posted.
>
What would you say about "opt > opt" then ?
That is not needed for any ass container.

What I'm trying to do is prove, or show, is that the real nature of
the problems that has been put forth so far are not really about
mixing operand types but about the very nature of ordering optionals.

That you need < for ass container is just poisoning the discussion. So
let's consider > instead.

>> If not, why would you left out the mixed ones and not the others?
>
> [Always taking about <, <=3D, > and >=3D here]
>
> I kind of like your line of thinking:
> [1] op < op  =3D> [2] op < optional<int>(5) =3D> [3] op < 5
>
> But someone that writes [3] may be bitten by the fact that there is
> actually an arbitrary result chosen in the case of nullopt.
>
But, isn't there "an arbitrary result chosen in the case of nullopt" when y=
ou do

op  < op

just as well??

In fact, as I mentioned already, there are TWO not just ONE possible
arbitrary results in that case, so it's even MORE subtle.

Best


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=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/?hl=3Den.



.

On Tue, Jan 29, 2013 at 7:53 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>>
>> OK, but, how is the improved NaN feature affected differently by *mixed*
>> relops as opposed to (homogeneous) relops ?
>
>
> Homogenous ordering also compromises the improved NaN feature. I guess th=
e
> reason I do not complain about homogenous ordering is that I never ever h=
ad
> to use it directly. I only needed it for making std::set<boost::optional<=
T>>
> to work. Again, this boils down to the individual's usage experience. In
> contrast, I used mixed ordering only once in my experience, and it was by
> mistake: I really intended to compare two T's.
>

OK.

Would you agree that the arguments themselves would only lead to the
conclusion that opt < opt is just as, or at least almost as, error
prone as opt < 5?

We would be removing feature B for reasons that would, in all
fairness, apply to feature A as well, yet feature A stays just because
it has one important use case (ass containers). That seems wrong.

In terms of experience, being the original creator, I believe is fair
to say that I alone have used it in many many ways, much much more
than most any other person, even those using boost::optional. And IME
relops (specially =3D=3D and !=3D), mixed and not, are used a lot.


>
>>
>>
>> Still after all that has been said, I remain in the position that,
>>
>> *provided* opt < opt is OK,  then so is opt < make_optional<t>, and then=
,
>> I still fail to see why opt < t would not be exactly equally OK.
>
>
> The only argument I can make here is different probability of making a
> programming error. When you compare two optionals you probably do it
> consciously. Whereas, when comparing T with optional<T>, it is more likel=
y
> that you intended to compare two T's and forgot that one of the T's was
> actually a nullable one. I guess it is all about this probability.
>

I would agree that there are indeed somewhat larger chances of meaning
T < T when you used mix relops.

Yet, like I said, this particular possible source of error is IMO not
strong enough to remove a feature from *this* language, which openly
supports implicit conversions in binary operations, so it's already
common for a C++ programmer to watch out for that.
If this were C#, which follows a much more restrictive policy in the
name of safety, I would totally agree (but then there would not be T
-> OPT T either)


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=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/?hl=3Den.



.

On Tue, Jan 29, 2013 at 9:21 PM, Matias Capeletto
<matias.capeletto@gmail.com> wrote:
> On Tue, Jan 29, 2013 at 11:51 PM, Matias Capeletto
> <matias.capeletto@gmail.com> wrote:
>> [Always taking about <, <=, > and >= here]
>>
>> I kind of like your line of thinking:
>> [1] op < op  => [2] op < optional<int>(5) => [3] op < 5
>> ...
>> We can not forbid [2] because that will imply no [1]. So we will have
>> to live with op < optional<int>(5).
>> But we can force users to choose instead of given them [3]. I think
>> that the compiler error there will annoy people at first but it will
>> avoid bugs in user code that are not easy at all to spot. And there
>> have been several options presented to give the user terse and clear
>> syntax in replacement of the mix relops.
>
> Some more examples of mix-relops ill posed code:
>
> // Wrong result, seems natural, but it returns false if width or
> height is nullopt
> bool fits_in( figure f, optional<double> width, optional<double> height ) {
>   auto bbox = get_bbox(f);
>   return bbox.width() < width && bbox.height() < height ;

OK.
But, is this wrong because bbox.width() is a 'double' and not an
optional<double>?
Of course not... if it where opt then this would be just as wrong.

And I can easily imagine a "BBox" that defines optional<double>
width()" to denote the case of an empty bbox
(explicitly empty bboxes are very common in computer graphics)

(it cannot return just 0 because you could have a non-empty bbox that
has an height > 0 but width == 0 )

So, is the real problem is in the arbitrary definition of ordering.

The "mixed" ops just makes the chances of that being the source of a
bug larger, but not as much as it seems to be assumed, because there
are still a lot of uses for non-mixed relops as well (specially == and
!=)


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



.

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

Le 31/01/13 09:42, Andrzej Krzemien'ski a =E9crit :
>
>     > Now I start to understand something (which was probably obvious
>     to others):
>     > with optional we are proposing two opposite features: (1) an
>     "improved NaN"
>     > and (2) "just another value of T". The former begs for syntactic
>     difference
>     > when accessing the special value (the main purpose of optional).
>     The latter
>     > begs for a uniform handling of nullopt with other values: hence
>     the implicit
>     > conversion, assignment from T, relops. The two goals are
>     incompatible of one
>     > another, and we are trying to squeeze both features. I do not
>     necessarily
>     > say it is undesired or not doable, but finding the balance will
>     be very
>     > tricky.
>
>     I think the problem is much smaller than it appears from the
>     length of
>     this discussion. If you provide mixed comparisons, I think people
>     will
>     generally be fine. If you provide homogenous comparisons but poison
>     mixed comparisons, I think people will generally be fine. If you
>     don't
>     provide homogenous comparisons, I expect the LWG to insist on them so
>     that optional<T> interoperates with std::set<>, but I could be wrong.
>
>     You should just write the best proposal you can, with alternatives
>     where you think the committee might disagree (Ville's list at
>     [Dynamic
>     of a propoal] is good), and we'll discuss it in Bristol. At some
>     point
>     you just have to ignore the people on this list who will argue
>     forever.
>
>
> I would like to run through you a yet another possible solution to=20
> ordering suggested by Vicente J. Botet Escriba in the other thread. In=20
> short, whether the nullopt state is least of all T's or greatest of=20
> all T's is implementation-defined. This way, you are guaranteed that=20
> ordered containers work, but you cannot rely on the results, when=20
> using LessThan comparison manually. This also implies that you cannot=20
> use mixed ordering in most of the cases, and it becomes more natural=20
> to poison them.
>
> The only problem I perceive that the users will not notice that they=20
> cannot rely on the ordering on nullopt, and will still decide to rely=20
> on it, which will work on their platform, but will render the code=20
> non-portable.
>
> I would like to hear your opinion..
>
>
I've reconsidered my suggestion as I was not really comfortable with it.

When considering optional<T> as a model of a sequence of 0..1 T, the=20
lexicographical order is natural, as e.g. most of the STL containers are=20
ordered lexicographically.

When considering it as a pointer (with nullopt) the comparison should be=20
undefined if we follow the current standard and if I'm not wrong on the=20
interpretation

5.9 Past bullet 2
"--- If two pointers p and q of the same type point to different objects=20
that are not members of the same
object or elements of the same array or to different functions, or if=20
only one of them is null, the results
of p<q, p>q, p<=3Dq, and p>=3Dq are unspecified.
"

Of course, optional T is neither a sequence nor a smart pointer, but we=20
expect the rel op to compare the value, so I agree that the=20
lexicographical order is the correct option. In addition, taking the=20
disengaged optional (empty) as the smallest optional follows exactly the=20
lexicographical order.

Maybe nullopt recalls too much nullptr and don't suggest an empty=20
sequence. Has someone considered to use the Boost.Optional none_t as a=20
literal for empty sequences?


Vicente

--=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/?hl=3Den.



--------------050901020806040300070308
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">Le 31/01/13 09:42, Andrzej Krzemie&#324;ski
      a &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
      cite="mid:9cffa67e-16ce-420f-88a8-8f53dfa817e2@isocpp.org"
      type="cite"><br>
      <blockquote class="gmail_quote" style="margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Now I
        start to understand something (which was probably obvious to
        others):
        <br>
        &gt; with optional we are proposing two opposite features: (1)
        an "improved NaN"
        <br>
        &gt; and (2) "just another value of T". The former begs for
        syntactic difference
        <br>
        &gt; when accessing the special value (the main purpose of
        optional). The latter
        <br>
        &gt; begs for a uniform handling of nullopt with other values:
        hence the implicit
        <br>
        &gt; conversion, assignment from T, relops. The two goals are
        incompatible of one
        <br>
        &gt; another, and we are trying to squeeze both features. I do
        not necessarily
        <br>
        &gt; say it is undesired or not doable, but finding the balance
        will be very
        <br>
        &gt; tricky.
        <br>
        <br>
        I think the problem is much smaller than it appears from the
        length of
        <br>
        this discussion. If you provide mixed comparisons, I think
        people will
        <br>
        generally be fine. If you provide homogenous comparisons but
        poison
        <br>
        mixed comparisons, I think people will generally be fine. If you
        don't
        <br>
        provide homogenous comparisons, I expect the LWG to insist on
        them so
        <br>
        that optional&lt;T&gt; interoperates with std::set&lt;&gt;, but
        I could be wrong.
        <br>
        <br>
        You should just write the best proposal you can, with
        alternatives
        <br>
        where you think the committee might disagree (Ville's list at
        [Dynamic
        <br>
        of a propoal] is good), and we'll discuss it in Bristol. At some
        point
        <br>
        you just have to ignore the people on this list who will argue
        <br>
        forever.
        <br>
      </blockquote>
      <div><br>
      </div>
      <div>I would like to run through you a yet another possible
        solution to ordering suggested by&nbsp;Vicente J. Botet Escriba in
        the other thread. In short, whether the nullopt state is least
        of all T's or greatest of all T's is implementation-defined.
        This way, you are guaranteed that ordered containers work, but
        you cannot rely on the results, when using LessThan comparison
        manually. This also implies that you cannot use mixed ordering
        in most of the cases, and it becomes more natural to poison
        them.</div>
      <div><br>
      </div>
      <div>The only problem I perceive that the users will not notice
        that they cannot rely on the ordering on nullopt, and will still
        decide to rely on it, which will work on their platform, but
        will render the code non-portable.</div>
      <div><br>
      </div>
      <div>I would like to hear your opinion..</div>
      <div><br>
      </div>
      <br>
    </blockquote>
    I've reconsidered my suggestion as I was not really comfortable with
    it. <br>
    <br>
    When considering optional&lt;T&gt; as a model of a sequence of 0..1
    T, the lexicographical order is natural, as e.g. most of the STL
    containers are ordered lexicographically. <br>
    <br>
    When considering it as a pointer (with nullopt) the comparison
    should be undefined if we follow the current standard and if I'm not
    wrong on the interpretation<br>
    <br>
    5.9 Past bullet 2<br>
    "&#8212; If two pointers p and q of the same type point to di&#64256;erent
    objects that are not members of the same<br>
    object or elements of the same array or to di&#64256;erent functions, or if
    only one of them is null, the results<br>
    of p&lt;q, p&gt;q, p&lt;=q, and p&gt;=q are unspeci&#64257;ed.<br>
    "<br>
    <br>
    Of course, optional T is neither a sequence nor a smart pointer, but
    we expect the rel op to compare the value, so I agree that the
    lexicographical order is the correct option. In addition, taking the
    disengaged optional (empty) as the smallest optional follows exactly
    the lexicographical order. <br>
    <br>
    Maybe nullopt recalls too much nullptr and don't suggest an empty
    sequence. Has someone considered to use the Boost.Optional none_t as
    a literal for empty sequences?<br>
    <br>
    <br>
    Vicente<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/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

--------------050901020806040300070308--

.

On Thu, Jan 31, 2013 at 7:33 PM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
>
> Maybe nullopt recalls too much nullptr and don't suggest an empty sequence.
> Has someone considered to use the Boost.Optional none_t as a literal for
> empty sequences?
>
This proposal derives from Boost.Optional, so indeed in its very first
version, none_t as exists in Boost was proposed.
There was a long discussion about it, which resulted in the current nullopt

Please search the archives.

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



.

------=_Part_938_11622437.1359673807783
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 31 stycznia 2013 23:38:51 UTC+1 u=BFytkownik Fernando=20
Cacciola napisa=B3:
>
> On Thu, Jan 31, 2013 at 7:33 PM, Vicente J. Botet Escriba=20
> <vicent...@wanadoo.fr <javascript:>> wrote:=20
> >=20
> > Maybe nullopt recalls too much nullptr and don't suggest an empty=20
> sequence.=20
> > Has someone considered to use the Boost.Optional none_t as a literal fo=
r=20
> > empty sequences?=20
> >=20
> This proposal derives from Boost.Optional, so indeed in its very first=20
> version, none_t as exists in Boost was proposed.=20
> There was a long discussion about it, which resulted in the current=20
> nullopt=20
>
> Please search the archives.=20
>

IIRC, the argument was that "nullopt" indicates that it is something=20
particular to optional. "none" is a very generic name, and if added to the=
=20
Standard Library, it rises questions like, how does it interact with other=
=20
components: can a pointer be assigned "none"? Is "none" convertible to=20
nullptr? Is it convertible to bool? Can I use it to initialize any empty=20
container explicitly? etc.

On the other hand, "nullopt" is not "nullptr" which already sends a message=
=20
that it is not a pointer, because if it was it would definitely use=20
nullptr. (like std::function does :)

Regards,
&rzej

--=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/?hl=3Den.



------=_Part_938_11622437.1359673807783
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu czwartek, 31 stycznia 2013 23:38:51 UTC+1 u=BFytkownik Ferna=
ndo Cacciola napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu,=
 Jan 31, 2013 at 7:33 PM, Vicente J. Botet Escriba
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
Gyn9qnJjd90J">vicent...@wanadoo.fr</a>&gt; wrote:
<br>&gt;
<br>&gt; Maybe nullopt recalls too much nullptr and don't suggest an empty =
sequence.
<br>&gt; Has someone considered to use the Boost.Optional none_t as a liter=
al for
<br>&gt; empty sequences?
<br>&gt;
<br>This proposal derives from Boost.Optional, so indeed in its very first
<br>version, none_t as exists in Boost was proposed.
<br>There was a long discussion about it, which resulted in the current nul=
lopt
<br>
<br>Please search the archives.
<br></blockquote><div><br>IIRC, the argument was that "nullopt" indicates t=
hat it is something particular to optional. "none" is a very generic name, =
and if added to the Standard Library, it rises questions like, how does it =
interact with other components: can a pointer be assigned "none"? Is "none"=
 convertible to nullptr? Is it convertible to bool? Can I use it to initial=
ize any empty container explicitly? etc.<br><br>On the other hand, "nullopt=
" is not "nullptr" which already sends a message that it is not a pointer, =
because if it was it would definitely use nullptr. (like std::function does=
 :)<br><br>Regards,<br>&amp;rzej<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_938_11622437.1359673807783--

.

On Thu, Jan 31, 2013 at 10:58 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
>> // Wrong result, seems natural, but it returns false if width or
>> height is nullopt
>> bool fits_in( figure f, optional<double> width, optional<double> height ) {
>>   auto bbox = get_bbox(f);
>>   return bbox.width() < width && bbox.height() < height ;
>
> OK.
> But, is this wrong because bbox.width() is a 'double' and not an
> optional<double>?
> Of course not... if it where opt then this would be just as wrong.

True

> And I can easily imagine a "BBox" that defines optional<double>
> width()" to denote the case of an empty bbox
> (explicitly empty bboxes are very common in computer graphics)
>
> (it cannot return just 0 because you could have a non-empty bbox that
> has an height > 0 but width == 0 )

That's still empty, isn't it?
If it's not, you could just check both width and height instead of
making both/either of them optionals.

> So, is the real problem is in the arbitrary definition of ordering.

Right. That definition is fine for sorting and ass. containers, but
not for other things.


--
Olaf

--

---
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/?hl=en.



.

On 2013/01/29 07:58 +0900, Andrzej Krzemie=C5=84ski wrote:
 > ..., perhaps less-than comparison
 > is primarily about order, and nothing else.  ...

Is the validity of std::set<std::optional<T>>, without specifying
ordering type argument, so strong requirement?

Now I think it can be a reasonable choice of design to require
specifying ordering for the use of std::set, which is "ordered set" in
fact. For casual users who don't care about ordering, they can likely be
satisfied with std::unordered_set<optional<T>>, I think.

Please look the following pseudo codes to get my idea. I'm tempted to
propose this to break the never-meeting discussion about mixed relops.

namespace std {

template<typename T> struct optional { ... };

// Provide operator =3D=3D, !=3D to avoid unnecessary implicit conversions.
....

// Poison operator <, <=3D, >, >=3D via implicit conversions, since they
// don't know which side they should order nullopt, least or greatest.
....

// *NEW*
// Functional type for ordering which supports 3x3 overload among
// [T, optional<T>, nullopt_t] to avoid unnecessary implicit conversion.
// This can be used explicitly as the comparator for std::set,
// std::sort, ... etc.
template<typename T> struct order_nullopt_least { ... };
// Ditto, with opposite ordering of nullopt.
template<typename T> struct order_nullopt_greatest { ... };

}

// The use.
std::set<optional<T>, std::order_nullopt_least<T>> nullopt_at_start;
std::set<optional<T>, std::order_nullopt_greatest<T>> nullopt_at_last;

// Looks awful? Then probably you want this in fact.
std::unordered_set<optional<T>> yeah;


--=20
k_satoda

--=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/?hl=3Den.



.

------=_Part_372_6167164.1359989874551
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu poniedzia=B3ek, 28 stycznia 2013 23:58:17 UTC+1 u=BFytkownik Andrzej=
=20
Krzemie=F1ski napisa=B3:
>
> Hi Everyone,
> I needed to say this in a new thread as the other one was getting too=20
> crowded.
>
=20
I wanted to consult with people here one more thing about mixed relops.=20
Assuming that we allow mixed relops for optional values, should we also=20
provide them for optional references?

int i =3D 9;
optional<int&> oi =3D i;
return oi =3D=3D i; // should it work?

Regards,
&rzej

--=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/?hl=3Den.



------=_Part_372_6167164.1359989874551
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu poniedzia=B3ek, 28 stycznia 2013 23:58:17 UTC+1 u=BFytkownik=
 Andrzej Krzemie=F1ski napisa=B3:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">Hi Everyone,<br>I needed to say this in a new thread as the other one wa=
s getting too crowded.<br></blockquote><div>&nbsp;<br>I wanted to consult w=
ith people here one more thing about mixed relops. Assuming that we allow m=
ixed relops for optional values, should we also provide them for optional r=
eferences?<br><br>int i =3D 9;<br>optional&lt;int&amp;&gt; oi =3D i;<br>ret=
urn oi =3D=3D i; // should it work?<br><br>Regards,<br>&amp;rzej<br><br></d=
iv>

<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_372_6167164.1359989874551--

.

On 4 February 2013 16:57, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:
> I wanted to consult with people here one more thing about mixed relops.
> Assuming that we allow mixed relops for optional values, should we also
> provide them for optional references?
> int i =3D 9;
> optional<int&> oi =3D i;
> return oi =3D=3D i; // should it work?

I think that should work, yes.

--=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/?hl=3Den.



.

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

On 4 February 2013 09:11, Ville Voutilainen <ville.voutilainen@gmail.com>wr=
ote:

> On 4 February 2013 16:57, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> w=
rote:
> > I wanted to consult with people here one more thing about mixed relops.
> > Assuming that we allow mixed relops for optional values, should we also
> > provide them for optional references?
> > int i =3D 9;
> > optional<int&> oi =3D i;
> > return oi =3D=3D i; // should it work?
>
> I think that should work, yes.
>

+1
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=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/?hl=3Den.



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

On 4 February 2013 09:11, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">

<div class=3D"im">On 4 February 2013 16:57, Andrzej Krzemie=C5=84ski &lt;<a=
 href=3D"mailto:akrzemi1@gmail.com">akrzemi1@gmail.com</a>&gt; wrote:<br>
&gt; I wanted to consult with people here one more thing about mixed relops=
..<br>
&gt; Assuming that we allow mixed relops for optional values, should we als=
o<br>
&gt; provide them for optional references?<br>
&gt; int i =3D 9;<br>
&gt; optional&lt;int&amp;&gt; oi =3D i;<br>
&gt; return oi =3D=3D i; // should it work?<br>
<br>
</div>I think that should work, yes.<br clear=3D"all"></blockquote></div><b=
r>+1<br>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>&gt;=C2=A0 (847) 691-1404

<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001636920b5fa57dd604d4e7c421--

.

On Mon, Feb 4, 2013 at 9:57 AM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com> =
wrote:
>
>
> W dniu poniedzia=B3ek, 28 stycznia 2013 23:58:17 UTC+1 u=BFytkownik Andrz=
ej
> Krzemie=F1ski napisa=B3:
>>
>> Hi Everyone,
>> I needed to say this in a new thread as the other one was getting too
>> crowded.
>
>
> I wanted to consult with people here one more thing about mixed relops.
> Assuming that we allow mixed relops for optional values, should we also
> provide them for optional references?
>
> int i =3D 9;
> optional<int&> oi =3D i;
> return oi =3D=3D i; // should it work?
>

Just to be clear, does it compare the values, or the ref?

ie

int i =3D 9;
optional<int&> oi =3D i;
int j =3D 9;
return oi =3D=3D j;  // also true?


And does this follow whichever rules of set-the-value or set-the-ref
you are choosing?

....
j =3D 5;
oi =3D j;

cout << i;  // prints... 5? 9?


Sorry to bring up the optional & discussion again.  I really just
wondered whether it was consistent with assignment, whichever way it
goes.

> Regards,
> &rzej
>

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/?hl=3Den.



.

On 4 February 2013 20:54, Tony V E <tvaneerd@gmail.com> wrote:
>> int i = 9;
>> optional<int&> oi = i;
>> return oi == i; // should it work?
> Just to be clear, does it compare the values, or the ref?

The value. It can't compare "the ref", and comparing addresses would be
borderline insane.

> int i = 9;
> optional<int&> oi = i;
> int j = 9;
> return oi == j;  // also true?

Yes, true.

> And does this follow whichever rules of set-the-value or set-the-ref
> you are choosing?
> j = 5;
> oi = j;
> cout << i;  // prints... 5? 9?

Good question. According to the discussion in Portland,
copy/move-assigning an optional<T&> from
another optional<T&> would reseat the reference, but I don't know what
assigning from a T would
do. My reflex would be to say that it doesn't reseat, but that's just a reflex.

--

---
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/?hl=en.



.

------=_Part_792_3852711.1360005987688
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu poniedzia=B3ek, 4 lutego 2013 20:23:38 UTC+1 u=BFytkownik Ville=20
Voutilainen napisa=B3:
>
> On 4 February 2013 20:54, Tony V E <tvan...@gmail.com <javascript:>>=20
> wrote:=20
> >> int i =3D 9;=20
> >> optional<int&> oi =3D i;=20
> >> return oi =3D=3D i; // should it work?=20
> > Just to be clear, does it compare the values, or the ref?=20
>
> The value. It can't compare "the ref", and comparing addresses would be=
=20
> borderline insane.=20
>
> > int i =3D 9;=20
> > optional<int&> oi =3D i;=20
> > int j =3D 9;=20
> > return oi =3D=3D j;  // also true?=20
>
> Yes, true.=20
>
> > And does this follow whichever rules of set-the-value or set-the-ref=20
> > you are choosing?=20
> > j =3D 5;=20
> > oi =3D j;=20
> > cout << i;  // prints... 5? 9?=20
>
> Good question. According to the discussion in Portland,=20
> copy/move-assigning an optional<T&> from=20
> another optional<T&> would reseat the reference, but I don't know what=20
> assigning from a T would=20
> do. My reflex would be to say that it doesn't reseat, but that's just a=
=20
> reflex.=20
>

I answered this in a new thread:=20
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/1P188wd-TBQ/di=
scussion
I anticipate this might start a long thread=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/?hl=3Den.



------=_Part_792_3852711.1360005987688
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu poniedzia=B3ek, 4 lutego 2013 20:23:38 UTC+1 u=BFytkownik Vi=
lle Voutilainen napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 4=
 February 2013 20:54, Tony V E &lt;<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"Kl90sUNbQFMJ">tvan...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; int i =3D 9;
<br>&gt;&gt; optional&lt;int&amp;&gt; oi =3D i;
<br>&gt;&gt; return oi =3D=3D i; // should it work?
<br>&gt; Just to be clear, does it compare the values, or the ref?
<br>
<br>The value. It can't compare "the ref", and comparing addresses would be
<br>borderline insane.
<br>
<br>&gt; int i =3D 9;
<br>&gt; optional&lt;int&amp;&gt; oi =3D i;
<br>&gt; int j =3D 9;
<br>&gt; return oi =3D=3D j; &nbsp;// also true?
<br>
<br>Yes, true.
<br>
<br>&gt; And does this follow whichever rules of set-the-value or set-the-r=
ef
<br>&gt; you are choosing?
<br>&gt; j =3D 5;
<br>&gt; oi =3D j;
<br>&gt; cout &lt;&lt; i; &nbsp;// prints... 5? 9?
<br>
<br>Good question. According to the discussion in Portland,
<br>copy/move-assigning an optional&lt;T&amp;&gt; from
<br>another optional&lt;T&amp;&gt; would reseat the reference, but I don't =
know what
<br>assigning from a T would
<br>do. My reflex would be to say that it doesn't reseat, but that's just a=
 reflex.
<br></blockquote><div><br>I answered this in a new thread: https://groups.g=
oogle.com/a/isocpp.org/d/topic/std-proposals/1P188wd-TBQ/discussion<br>I an=
ticipate this might start a long thread <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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_792_3852711.1360005987688--

.

On 4 February 2013 21:26, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:
> I answered this in a new thread:
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/1P188wd-TBQ/=
discussion
> I anticipate this might start a long thread

That it may do. Choose the option that you think is best, and convey
the paper to the LEWG,
without an endless discussion. ;)

--=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/?hl=3Den.



.