Topic: Compressing std::optional
Author: vlovich@gmail.com
Date: Wed, 24 Jun 2015 09:55:49 -0700 (PDT)
Raw View
------=_Part_1089_1110554904.1435164949798
Content-Type: multipart/alternative;
boundary="----=_Part_1090_1315895451.1435164949798"
------=_Part_1090_1315895451.1435164949798
Content-Type: text/plain; charset=UTF-8
Hi,
I'd like to bring up this topic again. I know Andrzej brought it up a
couple of years ago for tr2 but I think I have a different take.
First, I'd like to motivate the discussion with the limitations of the
current approach.
- For small types optional can double the size of storage
- Overhead can add up when stored in arrays (& most of it due to padding
if the sizeof(T) > 1).
- Cannot be used as a drop-in in a memory-mapped structure. In these
scenarios it's not uncommon to have a sentinel value.
- Cannot be used in as a drop-in in existing code that uses a sentinel
(i.e type-safety)
- Lots of overhead when a struct contains lots of optionals. For
example, protobuf uses bit-packing for this.
The main limitation, at least as I see it, of the Andrzej's traits
implementation is that it cannot be customized per-instance of optional.
This is probably fine for user-defined types but makes this optimization
not possible for built-in types. It's not uncommon to have only certain
instances of built-in types have invalid bit-patterns (e.g. NaN for double,
maximum value for size_t as reported by std::string).
To that end, my proposal to accomplish something like this would require
adding a secondary template parameter that defines the storage of the
initialization state. Here is a straw-man skeleton example of what the
std::optional class interface might look like. constexpr omitted for
simplicity but I don't see anything preventing it & optional_storage is the
hypothetical :
template <typename T, typename S = default_optional_initialization_storage>
class optional {
public:
optional(std::nullopt_t)
{
std::get<0>(_data).set_initialized(reinterpret_cast<T*>(&std::get<1
>(_data)), false);
}
optional(const T&)
{
std::get<0>(_data).set_initialized(reinterpret_cast<T*>(&std::get<1
>(_data)), true);
}
...
bool is_initialized() const
{
return std::get<0>(_data).is_initialized();
}
...
private:
std::tuple<S, aligned_storage_t<sizeof(T)>> _data;
};
default_optional_initialization_storage would comply with the interface for
optional_initialization_storage & look something like:
struct default_optional_initialization_storage {
template <typename T>
bool is_initialized(T*) const
{
return _initialized;
}
template <typename T>
void set_initialized(T*, bool initialized)
{
_initialized = initialized;
}
bool _initialized = false;
};
An example for hiding the state as via NaN for double:
struct nan_optional_storage {
bool is_initialized(double* value) const
{
return !std::isnan(*value)
}
void set_initialized(double* value, bool initialized)
{
if (!initialized) {
*value = std::numeric_limits<double>::quite_NaN();
}
}
};
Some of my thoughts on this sample code:
- It is by no means an exaustive implementation and I'm sure there's
lots of nitpicking to be done over details/naming/etc. I just want to get
a sense of does something like this even make sense.
- This is purely a mechanism through which optional can be optimized
with domain-specific knowledge. There is no optimization suggested for
built-in types (e.g. not even pointer types would optimize the nullptr case
by default).
- The sentinel-value use-case would probably be important enough that a
simple API for expressing such a sentinel value would be valuable
(something like optional<double, sentinel<double, nan("")>>)
- This is purely a customization point to apply domain-specific
knowledge to optimize optional. There is no optimization available by
default.
- The careful reader will note that the bit-packing case has not been
addressed. I am not quite certain how to actually achieve this since the
storage lives external to the optional<> itself. Passing through some kind
of ctx in all optional APIs?
- It has been suggested by some that this no longer represents the CS
concept of an optional monad and should be a distinct type. I'm not sure I
really see why (purity of mapping C++ to theoretical CS aside).
Thanks for reading,
Vitali
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1090_1315895451.1435164949798
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>I'd like to bring up this topic again. I =
know Andrzej brought it up a couple of years ago for tr2 but I think I have=
a different take.<br>First, I'd like to motivate the discussion with the l=
imitations of the current approach.<br><ul><li>For small types optional can=
double the size of storage</li><li>Overhead can add up when stored in arra=
ys (& most of it due to padding if the sizeof(T) > 1).</li><li>Canno=
t be used as a drop-in in a memory-mapped structure. In these scenari=
os it's not uncommon to have a sentinel value.</li><li>Cannot be used in as=
a drop-in in existing code that uses a sentinel (i.e type-safety)</li><li>=
Lots of overhead when a struct contains lots of optionals. For exampl=
e, protobuf uses bit-packing for this.</li></ul><p>The main limitation, at =
least as I see it, of the Andrzej's traits implementation is that it cannot=
be customized per-instance of optional. This is probably fine for us=
er-defined types but makes this optimization not possible for built-in type=
s. It's not uncommon to have only certain instances of built-in types=
have invalid bit-patterns (e.g. NaN for double, maximum value for size_t a=
s reported by std::string).<br></p><p><br></p><p>To that end, my proposal t=
o accomplish something like this would require adding a secondary template =
parameter that defines the storage of the initialization state. Here =
is a straw-man skeleton example of what the std::optional class interface m=
ight look like. constexpr omitted for simplicity but I don't see anything p=
reventing it & optional_storage is the hypothetical :</p><p><br></p><p>=
</p><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"subpret=
typrint"><span style=3D"color: #008;" class=3D"styled-by-prettify">template=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"col=
or: #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"> S </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> default_optional_initialization_storage</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> optional </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">public</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
optional</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">nullopt_t</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>  =
; std</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">get</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><s=
pan style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">>(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">_data</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">).</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">set_initialized</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span class=3D"kw1"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">reinterpret_cast</span></spa=
n><span class=3D"sy1"><span style=3D"color: #660;" class=3D"styled-by-prett=
ify"><</span></span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">T</span><span class=3D"sy2"><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">*</span></span><span class=3D"sy1"><span style=3D"color: #=
660;" class=3D"styled-by-prettify">>(</span></span><span style=3D"color:=
#000;" class=3D"styled-by-prettify">&std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">get</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify"><</span><span style=3D"color: #066;" class=3D"styled=
-by-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
_data</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)),</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">false</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"co=
lor: #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><br> optional</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=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"colo=
r: #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">{</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br> std</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">get</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">>(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">_data</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">).</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">set_initialized</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><code class=3D"prettyprint"><span class=3D"kw1"><span style=3D"color=
: #008;" class=3D"styled-by-prettify">reinterpret_cast</span></span><span c=
lass=3D"sy1"><span style=3D"color: #660;" class=3D"styled-by-prettify"><=
</span></span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</=
span><span class=3D"sy2"><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">*</span></span><span class=3D"sy1"><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">>(&</span></span></code>std</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">get</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">>(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">_data</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">)),</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">true</=
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 style=3D"color: #660;" class=3D"styled-by-prettify">}</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>  =
; ...<br> </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> is_initialized</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: #008;" class=3D"styled-by-prettify">const=
</span><span style=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: #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-pre=
ttify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">get</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">>(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">_data</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">).</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">is_initialized</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">private</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br> std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">tuple</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
S</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> aligned_storage_t=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span><sp=
an 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=
: #660;" class=3D"styled-by-prettify">)>></span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> _data</span><span style=3D"color: #66=
0;" 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"st=
yled-by-prettify">};</span></div></code></div><br><p></p><p>default_optiona=
l_initialization_storage would comply with the interface for optional_initi=
alization_storage & look something like:<code class=3D"prettyprint"><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></code></=
p><p><br><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"=
styled-by-prettify"></span></code></p><p><code class=3D"prettyprint"><span =
style=3D"color: #000;" class=3D"styled-by-prettify"></span></code></p><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-wr=
ap: break-word;"><code class=3D"prettyprint"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> default_optional_initialization_storage</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br> template <typename T><br>&n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">bool</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> is_=
initialized</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><code cl=
ass=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><code class=3D"prettyprint"><span style=3D"color: #660;" class=3D"styled=
-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">T*</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"></span></code></span></code></span></code>)</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">const</span><span style=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: #=
000;" class=3D"styled-by-prettify"><br> return _=
initialized;</span><span style=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: #000;" class=3D"styled-by-prettify"=
><br><br> template <typename T><br> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> set_initialized</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"><code class=3D"pretty=
print"><code class=3D"prettyprint"><span style=3D"color: #660;" class=3D"st=
yled-by-prettify"></span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify"><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #660;"=
class=3D"styled-by-prettify"></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #000;=
" class=3D"styled-by-prettify">T*, </span></code></span></code></span></cod=
e></span></code></code></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify"><code class=3D"prettyprint"><code class=3D"prettyprint"><span =
style=3D"color: #660;" class=3D"styled-by-prettify"><code class=3D"prettypr=
int"><span style=3D"color: #000;" class=3D"styled-by-prettify"><code class=
=3D"prettyprint"><span style=3D"color: #660;" class=3D"styled-by-prettify">=
<code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><code class=3D"prettyprint"><code class=3D"prettyprint"><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"></span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"></span></code></code> initialized</span><=
/code></span></code></span></code></span></code></code></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">)<br> {<br=
> _initialized =3D </span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prettypri=
nt"><code class=3D"prettyprint"><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><code class=3D"prettyprint"><code class=3D"prettyprint"><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"><code class=3D"pretty=
print"><span style=3D"color: #000;" class=3D"styled-by-prettify"><code clas=
s=3D"prettyprint"><span style=3D"color: #660;" class=3D"styled-by-prettify"=
><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">initialized</span></code></span></code></span></code></span></c=
ode></code></span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
></span></code></code>;<br> }</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"><br><br> </span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"pretty=
print"><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"></span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">bool</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"></span></code></code> _initialized =3D false;</span><code class=3D"pretty=
print"><span style=3D"color: #000;" class=3D"styled-by-prettify"><code clas=
s=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span></code></span></code><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span></div></code></code></div><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify"></span><p></p><p><br><code class=3D"prettyprint=
"><span style=3D"color: #660;" class=3D"styled-by-prettify"></span></code><=
/p>An example for hiding the state as via NaN for double:<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> nan_optional_storage </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"c=
olor: #000;" class=3D"styled-by-prettify"><br> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> is_initialized</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><code c=
lass=3D"prettyprint"><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy"><code class=3D"prettyprint"><code class=3D"prettyprint"><span style=3D"=
color: #660;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"pretty=
print"><span style=3D"color: #660;" class=3D"styled-by-prettify"><code clas=
s=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>double* value</span></code></span></code></span></code></span></code></cod=
e></span></code></code>) </span><code class=3D"prettyprint"><code class=3D"=
prettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">cons=
t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
; {<br> return !std::=
isnan(*value)<br> }<br></span></code></code><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> void =
set_initialized(double* value, bool initialized)<br> {<br=
> if (!initialized) {<br> &n=
bsp; *value =3D std::=
numeric_limits<double>::quite_NaN();<br>  =
; }<br> }<br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">;<br><br></span></div></code></div><code class=3D"p=
rettyprint"><span style=3D"color: #660;" class=3D"styled-by-prettify"><br><=
/span></code>Some of my thoughts on this sample code:<br><ul><li>It is by n=
o means an exaustive implementation and I'm sure there's lots of nitpicking=
to be done over details/naming/etc. I just want to get a sense of do=
es something like this even make sense.<br></li><li>This is purely a mechan=
ism through which optional can be optimized with domain-specific knowledge.=
There is no optimization suggested for built-in types (e.g. not even=
pointer types would optimize the nullptr case by default).</li><li>The sen=
tinel-value use-case would probably be important enough that a simple API f=
or expressing such a sentinel value would be valuable (something like optio=
nal<double, sentinel<double, nan("")>>)</li><li>This is purely =
a customization point to apply domain-specific knowledge to optimize option=
al. There is no optimization available by default.</li><li>The carefu=
l reader will note that the bit-packing case has not been addressed. =
I am not quite certain how to actually achieve this since the storage lives=
external to the optional<> itself. Passing through some kind o=
f ctx in all optional APIs?</li><li>It has been suggested by some that this=
no longer represents the CS concept of an optional monad and should be a d=
istinct type. I'm not sure I really see why (purity of mapping C++ to=
theoretical CS aside).</li></ul>Thanks for reading,<br>Vitali<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1090_1315895451.1435164949798--
------=_Part_1089_1110554904.1435164949798--
.
Author: vlovich@gmail.com
Date: Wed, 24 Jun 2015 10:00:17 -0700 (PDT)
Raw View
------=_Part_1312_406570771.1435165217659
Content-Type: multipart/alternative;
boundary="----=_Part_1313_2089467090.1435165217659"
------=_Part_1313_2089467090.1435165217659
Content-Type: text/plain; charset=UTF-8
Forgot to mention. The reader may ask that this should just be left to
users to implement their own class. std::optional is non-trivial to get
the interface & implementation right (moreso I think than even something
like vector).
A customization point solves an optimization problem that many may have in
a much simpler way without having to try to implement the entire optional
interface.
On Wednesday, June 24, 2015 at 9:55:50 AM UTC-7, vlo...@gmail.com wrote:
>
> Hi,
>
> I'd like to bring up this topic again. I know Andrzej brought it up a
> couple of years ago for tr2 but I think I have a different take.
> First, I'd like to motivate the discussion with the limitations of the
> current approach.
>
> - For small types optional can double the size of storage
> - Overhead can add up when stored in arrays (& most of it due to
> padding if the sizeof(T) > 1).
> - Cannot be used as a drop-in in a memory-mapped structure. In these
> scenarios it's not uncommon to have a sentinel value.
> - Cannot be used in as a drop-in in existing code that uses a sentinel
> (i.e type-safety)
> - Lots of overhead when a struct contains lots of optionals. For
> example, protobuf uses bit-packing for this.
>
> The main limitation, at least as I see it, of the Andrzej's traits
> implementation is that it cannot be customized per-instance of optional.
> This is probably fine for user-defined types but makes this optimization
> not possible for built-in types. It's not uncommon to have only certain
> instances of built-in types have invalid bit-patterns (e.g. NaN for double,
> maximum value for size_t as reported by std::string).
>
>
> To that end, my proposal to accomplish something like this would require
> adding a secondary template parameter that defines the storage of the
> initialization state. Here is a straw-man skeleton example of what the
> std::optional class interface might look like. constexpr omitted for
> simplicity but I don't see anything preventing it & optional_storage is the
> hypothetical :
>
>
> template <typename T, typename S = default_optional_initialization_storage
> >
> class optional {
> public:
> optional(std::nullopt_t)
> {
> std::get<0>(_data).set_initialized(reinterpret_cast<T*>(&std::get<
> 1>(_data)), false);
> }
>
> optional(const T&)
> {
> std::get<0>(_data).set_initialized(reinterpret_cast<T*>(&std::get<
> 1>(_data)), true);
> }
> ...
> bool is_initialized() const
> {
> return std::get<0>(_data).is_initialized();
> }
> ...
> private:
> std::tuple<S, aligned_storage_t<sizeof(T)>> _data;
> };
>
> default_optional_initialization_storage would comply with the interface
> for optional_initialization_storage & look something like:
>
>
> struct default_optional_initialization_storage {
> template <typename T>
> bool is_initialized(T*) const
> {
> return _initialized;
> }
>
> template <typename T>
> void set_initialized(T*, bool initialized)
> {
> _initialized = initialized;
> }
>
> bool _initialized = false;
> };
>
>
> An example for hiding the state as via NaN for double:
>
> struct nan_optional_storage {
> bool is_initialized(double* value) const
> {
> return !std::isnan(*value)
> }
>
> void set_initialized(double* value, bool initialized)
> {
> if (!initialized) {
> *value = std::numeric_limits<double>::quite_NaN();
> }
> }
> };
>
>
> Some of my thoughts on this sample code:
>
> - It is by no means an exaustive implementation and I'm sure there's
> lots of nitpicking to be done over details/naming/etc. I just want to get
> a sense of does something like this even make sense.
> - This is purely a mechanism through which optional can be optimized
> with domain-specific knowledge. There is no optimization suggested for
> built-in types (e.g. not even pointer types would optimize the nullptr case
> by default).
> - The sentinel-value use-case would probably be important enough that
> a simple API for expressing such a sentinel value would be valuable
> (something like optional<double, sentinel<double, nan("")>>)
> - This is purely a customization point to apply domain-specific
> knowledge to optimize optional. There is no optimization available by
> default.
> - The careful reader will note that the bit-packing case has not been
> addressed. I am not quite certain how to actually achieve this since the
> storage lives external to the optional<> itself. Passing through some kind
> of ctx in all optional APIs?
> - It has been suggested by some that this no longer represents the CS
> concept of an optional monad and should be a distinct type. I'm not sure I
> really see why (purity of mapping C++ to theoretical CS aside).
>
> Thanks for reading,
> Vitali
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1313_2089467090.1435165217659
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Forgot to mention. The reader may ask that this shou=
ld just be left to users to implement their own class. std::optional =
is non-trivial to get the interface & implementation right (moreso I th=
ink than even something like vector).<br>A customization point solves an op=
timization problem that many may have in a much simpler way without having =
to try to implement the entire optional interface.<br><br>On Wednesday, Jun=
e 24, 2015 at 9:55:50 AM UTC-7, vlo...@gmail.com wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr">Hi,<br><br>I'd like to bring up t=
his topic again. I know Andrzej brought it up a couple of years ago f=
or tr2 but I think I have a different take.<br>First, I'd like to motivate =
the discussion with the limitations of the current approach.<br><ul><li>For=
small types optional can double the size of storage</li><li>Overhead can a=
dd up when stored in arrays (& most of it due to padding if the sizeof(=
T) > 1).</li><li>Cannot be used as a drop-in in a memory-mapped structur=
e. In these scenarios it's not uncommon to have a sentinel value.</li=
><li>Cannot be used in as a drop-in in existing code that uses a sentinel (=
i.e type-safety)</li><li>Lots of overhead when a struct contains lots of op=
tionals. For example, protobuf uses bit-packing for this.</li></ul><p=
>The main limitation, at least as I see it, of the Andrzej's traits impleme=
ntation is that it cannot be customized per-instance of optional. Thi=
s is probably fine for user-defined types but makes this optimization not p=
ossible for built-in types. It's not uncommon to have only certain in=
stances of built-in types have invalid bit-patterns (e.g. NaN for double, m=
aximum value for size_t as reported by std::string).<br></p><p><br></p><p>T=
o that end, my proposal to accomplish something like this would require add=
ing a secondary template parameter that defines the storage of the initiali=
zation state. Here is a straw-man skeleton example of what the std::o=
ptional class interface might look like. constexpr omitted for simplicity b=
ut I don't see anything preventing it & optional_storage is the hypothe=
tical :</p><p><br></p><p></p><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">template</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#660"><</span><span sty=
le=3D"color:#008">typename</span><span style=3D"color:#000"> T</span><span =
style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">typename</span><span style=3D"color:#000"> S </span><span s=
tyle=3D"color:#660">=3D</span><span style=3D"color:#000"> default_optional_=
<wbr>initialization_storage</span><span style=3D"color:#660">></span><sp=
an style=3D"color:#000"><br></span><span style=3D"color:#008">class</span><=
span style=3D"color:#000"> optional </span><span style=3D"color:#660">{</sp=
an><span style=3D"color:#000"><br></span><span style=3D"color:#008">public<=
/span><span style=3D"color:#660">:</span><span style=3D"color:#000"><br>&nb=
sp; optional</span><span style=3D"color:#660">(</span><span style=3D=
"color:#000">std</span><span style=3D"color:#660">::</span><span style=3D"c=
olor:#000">nullopt_t</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> std</span><span=
style=3D"color:#660">::</span><span style=3D"color:#008">get</span><span s=
tyle=3D"color:#660"><</span><span style=3D"color:#066">0</span><span sty=
le=3D"color:#660">>(</span><span style=3D"color:#000">_data</span><span =
style=3D"color:#660">).</span><span style=3D"color:#000">set_<wbr>initializ=
ed</span><span style=3D"color:#660">(</span><span><span style=3D"color:#008=
">reinterpret_cast</span></span><span><span style=3D"color:#660"><</span=
></span><span style=3D"color:#000">T</span><span><span style=3D"color:#660"=
><wbr>*</span></span><span><span style=3D"color:#660">>(</span></span><s=
pan style=3D"color:#000">&std</span><span style=3D"color:#660">::</span=
><span style=3D"color:#008">get</span><span style=3D"color:#660"><</span=
><span style=3D"color:#066">1</span><span style=3D"color:#660">>(</span>=
<span style=3D"color:#000">_data</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> &=
nbsp; </span><span style=3D"color:#660">}</span><span style=3D"color:#000">=
<br><br> optional</span><span style=3D"color:#660">(</span><sp=
an style=3D"color:#008">const</span><span style=3D"color:#000"> T</span><sp=
an style=3D"color:#660">&)</span><span style=3D"color:#000"><br> =
</span><span style=3D"color:#660">{</span><span style=3D"color:#000"=
><br> std</span><span style=3D"color:#660">::</s=
pan><span style=3D"color:#008">get</span><span style=3D"color:#660"><</s=
pan><span style=3D"color:#066">0</span><span style=3D"color:#660">>(</sp=
an><span style=3D"color:#000">_data</span><span style=3D"color:#660">).</sp=
an><span style=3D"color:#000">set_<wbr>initialized</span><span style=3D"col=
or:#660">(</span><span style=3D"color:#000"><code><span><span style=3D"colo=
r:#008">reinterpret_cast</span></span><span><span style=3D"color:#660"><=
</span></span><span style=3D"color:#000">T</span><span><span style=3D"color=
:#660"><wbr>*</span></span><span><span style=3D"color:#660">>(&</spa=
n></span></code>std</span><span style=3D"color:#660">::</span><span style=
=3D"color:#008">get</span><span style=3D"color:#660"><</span><span style=
=3D"color:#066">1</span><span style=3D"color:#660">>(</span><span style=
=3D"color:#000">_data</span><span style=3D"color:#660">)),</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#008">true</span><span style=
=3D"color:#660">);</span><span style=3D"color:#000"><br> </spa=
n><span style=3D"color:#660">}</span><span style=3D"color:#000"><br> &=
nbsp; ...<br> </span><span style=3D"color:#008">bool</sp=
an><span style=3D"color:#000"> is_initialized</span><span style=3D"color:#6=
60">()</span><span style=3D"color:#000"> </span><span style=3D"color:#008">=
const</span><span style=3D"color:#000"><br> </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"> std</span><span style=3D"color:#660">::</span><span style=3D"color:=
#008">get</span><span style=3D"color:#660"><</span><span style=3D"color:=
#066">0</span><span style=3D"color:#660">>(</span><span style=3D"color:#=
000">_data</span><span style=3D"color:#660">).</span><span style=3D"color:#=
000">is_<wbr>initialized</span><span style=3D"color:#660">();</span><span s=
tyle=3D"color:#000"><br> </span><span style=3D"color:#660">}</=
span><span style=3D"color:#000"><br> </span><span style=3D"col=
or:#660">...</span><span style=3D"color:#000"><br></span><span style=3D"col=
or:#008">private</span><span style=3D"color:#660">:</span><span style=3D"co=
lor:#000"><br> std</span><span style=3D"color:#660">::</span><=
span style=3D"color:#000">tuple</span><span style=3D"color:#660"><</span=
><span style=3D"color:#000">S</span><span style=3D"color:#660">,</span><spa=
n style=3D"color:#000"> aligned_storage_t</span><span style=3D"color:#660">=
<</span><span style=3D"color:#008">sizeof</span><span style=3D"color:#66=
0">(</span><span style=3D"color:#000">T</span><span style=3D"color:#660">)&=
gt;></span><span style=3D"color:#000"> _data</span><span style=3D"color:=
#660">;</span><span style=3D"color:#000"><br></span><span style=3D"color:#6=
60">};</span></div></code></div><br><p></p><p>default_optional_<wbr>initial=
ization_storage would comply with the interface for optional_initialization=
_<wbr>storage & look something like:<code><span style=3D"color:#000"><b=
r></span></code></p><p><br><code><span style=3D"color:#000"></span></code><=
/p><p><code><span style=3D"color:#000"></span></code></p><div style=3D"back=
ground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:so=
lid;border-width:1px;word-wrap:break-word"><code><code><div><span style=3D"=
color:#008">struct</span><span style=3D"color:#000"> default_optional_<wbr>=
initialization_storage</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"><br> t=
emplate <typename T><br> </span><span style=3D"color:#00=
8">bool</span><span style=3D"color:#000"> is_initialized</span><span style=
=3D"color:#660">(</span><span style=3D"color:#660"><code><span style=3D"col=
or:#000"><code><span style=3D"color:#660"><code><span style=3D"color:#000">=
T*</span><span style=3D"color:#660"></span></code></span></code></span></co=
de>)</span><span style=3D"color:#000"> </span><span style=3D"color:#008">co=
nst</span><span style=3D"color:#000"><br> </span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"><br> =
return _initialized;</span><span style=3D"color:#000"><br> &n=
bsp; </span><span style=3D"color:#660">}</span><span style=3D"color:#000"><=
br><br> template <typename T><br> </sp=
an><span style=3D"color:#008">void</span><span style=3D"color:#000"> set_in=
itialized</span><span style=3D"color:#660">(</span><span style=3D"color:#66=
0"><code><code><span style=3D"color:#660"></span><span style=3D"color:#660"=
><code><span style=3D"color:#000"><code><span style=3D"color:#660"></span><=
span style=3D"color:#660"><code><span style=3D"color:#000">T*, </span></cod=
e></span></code></span></code></span></code></code></span><span style=3D"co=
lor:#660"><code><code><span style=3D"color:#660"><code><span style=3D"color=
:#000"><code><span style=3D"color:#660"><code><span style=3D"color:#000"><c=
ode><code><span style=3D"color:#000"></span><span style=3D"color:#008">bool=
</span><span style=3D"color:#000"></span></code></code> initialized</span><=
/code></span></code></span></code></span></code></code></span><span style=
=3D"color:#000">)<br> {<br> =
_initialized =3D </span><span style=3D"color:#000"><code><code=
><span style=3D"color:#660"><code><code><span style=3D"color:#660"><code><s=
pan style=3D"color:#000"><code><span style=3D"color:#660"><code><span style=
=3D"color:#000">initialized</span></code></span></code></span></code></span=
></code></code></span><span style=3D"color:#000"></span></code></code>;<br>=
}</span><span style=3D"color:#000"><br><br> &=
nbsp; </span><span style=3D"color:#000"><code><code><span style=3D"color:#0=
00"></span><span style=3D"color:#008">bool</span><span style=3D"color:#000"=
></span></code></code> _initialized =3D false;</span><code><span style=3D"c=
olor:#000"><code><span style=3D"color:#000"><br></span></code></span></code=
><span style=3D"color:#660">};</span><span style=3D"color:#000"><br></span>=
</div></code></code></div><span style=3D"color:#660"></span><p></p><p><br><=
code><span style=3D"color:#660"></span></code></p>An example for hiding the=
state as via NaN for double:<br><br><div style=3D"background-color:rgb(250=
,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px=
;word-wrap:break-word"><code><div><span style=3D"color:#008">struct</span><=
span style=3D"color:#000"> nan_optional_storage </span><span style=3D"color=
:#660">{</span><span style=3D"color:#000"></span><span style=3D"color:#000"=
><br> </span><span style=3D"color:#008">bool</span><span style=
=3D"color:#000"> is_initialized</span><span style=3D"color:#660">(</span><s=
pan style=3D"color:#660"><code><code><span style=3D"color:#660"><code><code=
><span style=3D"color:#660"><code><span style=3D"color:#000"><code><span st=
yle=3D"color:#660"><code><span style=3D"color:#000">double* value</span></c=
ode></span></code></span></code></span></code></code></span></code></code>)=
</span><code><code><span style=3D"color:#008">const</span><span style=3D"c=
olor:#000"><br> {<br> =
return !std::isnan(*value)<br> }<br></span></code>=
</code><span style=3D"color:#000"><br> void set_initializ=
ed(double* value, bool initialized)<br> {<br> =
if (!initialized) {<br> &nb=
sp; *value =3D std::numeric_limit=
s<double>::<wbr>quite_NaN();<br> &=
nbsp; }<br> }<br></span><span style=3D"color:#660">}</spa=
n><span style=3D"color:#000">;<br><br></span></div></code></div><code><span=
style=3D"color:#660"><br></span></code>Some of my thoughts on this sample =
code:<br><ul><li>It is by no means an exaustive implementation and I'm sure=
there's lots of nitpicking to be done over details/naming/etc. I jus=
t want to get a sense of does something like this even make sense.<br></li>=
<li>This is purely a mechanism through which optional can be optimized with=
domain-specific knowledge. There is no optimization suggested for bu=
ilt-in types (e.g. not even pointer types would optimize the nullptr case b=
y default).</li><li>The sentinel-value use-case would probably be important=
enough that a simple API for expressing such a sentinel value would be val=
uable (something like optional<double, sentinel<double, nan("")>&g=
t;)</li><li>This is purely a customization point to apply domain-specific k=
nowledge to optimize optional. There is no optimization available by =
default.</li><li>The careful reader will note that the bit-packing case has=
not been addressed. I am not quite certain how to actually achieve t=
his since the storage lives external to the optional<> itself. =
Passing through some kind of ctx in all optional APIs?</li><li>It has been =
suggested by some that this no longer represents the CS concept of an optio=
nal monad and should be a distinct type. I'm not sure I really see wh=
y (purity of mapping C++ to theoretical CS aside).</li></ul>Thanks for read=
ing,<br>Vitali<br></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1313_2089467090.1435165217659--
------=_Part_1312_406570771.1435165217659--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 24 Jun 2015 15:58:45 -0700
Raw View
I'd be happy to see a paper fleshing this out. I don't think anyone
was opposed to the idea, but it would have slowed down the initial
optional<> proposal if it had been included. Now is a great time to
try to add the feature.
On Wed, Jun 24, 2015 at 9:55 AM, <vlovich@gmail.com> wrote:
> Hi,
>
> I'd like to bring up this topic again. I know Andrzej brought it up a
> couple of years ago for tr2 but I think I have a different take.
> First, I'd like to motivate the discussion with the limitations of the
> current approach.
>
> For small types optional can double the size of storage
> Overhead can add up when stored in arrays (& most of it due to padding if
> the sizeof(T) > 1).
> Cannot be used as a drop-in in a memory-mapped structure. In these
> scenarios it's not uncommon to have a sentinel value.
> Cannot be used in as a drop-in in existing code that uses a sentinel (i.e
> type-safety)
> Lots of overhead when a struct contains lots of optionals. For example,
> protobuf uses bit-packing for this.
>
> The main limitation, at least as I see it, of the Andrzej's traits
> implementation is that it cannot be customized per-instance of optional.
> This is probably fine for user-defined types but makes this optimization not
> possible for built-in types. It's not uncommon to have only certain
> instances of built-in types have invalid bit-patterns (e.g. NaN for double,
> maximum value for size_t as reported by std::string).
>
>
> To that end, my proposal to accomplish something like this would require
> adding a secondary template parameter that defines the storage of the
> initialization state. Here is a straw-man skeleton example of what the
> std::optional class interface might look like. constexpr omitted for
> simplicity but I don't see anything preventing it & optional_storage is the
> hypothetical :
>
>
> template <typename T, typename S = default_optional_initialization_storage>
> class optional {
> public:
> optional(std::nullopt_t)
> {
>
> std::get<0>(_data).set_initialized(reinterpret_cast<T*>(&std::get<1>(_data)),
> false);
> }
>
> optional(const T&)
> {
>
> std::get<0>(_data).set_initialized(reinterpret_cast<T*>(&std::get<1>(_data)),
> true);
> }
> ...
> bool is_initialized() const
> {
> return std::get<0>(_data).is_initialized();
> }
> ...
> private:
> std::tuple<S, aligned_storage_t<sizeof(T)>> _data;
> };
>
> default_optional_initialization_storage would comply with the interface for
> optional_initialization_storage & look something like:
>
>
> struct default_optional_initialization_storage {
> template <typename T>
> bool is_initialized(T*) const
> {
> return _initialized;
> }
>
> template <typename T>
> void set_initialized(T*, bool initialized)
> {
> _initialized = initialized;
> }
>
> bool _initialized = false;
> };
>
>
> An example for hiding the state as via NaN for double:
>
> struct nan_optional_storage {
> bool is_initialized(double* value) const
> {
> return !std::isnan(*value)
> }
>
> void set_initialized(double* value, bool initialized)
> {
> if (!initialized) {
> *value = std::numeric_limits<double>::quite_NaN();
> }
> }
> };
>
>
> Some of my thoughts on this sample code:
>
> It is by no means an exaustive implementation and I'm sure there's lots of
> nitpicking to be done over details/naming/etc. I just want to get a sense
> of does something like this even make sense.
> This is purely a mechanism through which optional can be optimized with
> domain-specific knowledge. There is no optimization suggested for built-in
> types (e.g. not even pointer types would optimize the nullptr case by
> default).
> The sentinel-value use-case would probably be important enough that a simple
> API for expressing such a sentinel value would be valuable (something like
> optional<double, sentinel<double, nan("")>>)
> This is purely a customization point to apply domain-specific knowledge to
> optimize optional. There is no optimization available by default.
> The careful reader will note that the bit-packing case has not been
> addressed. I am not quite certain how to actually achieve this since the
> storage lives external to the optional<> itself. Passing through some kind
> of ctx in all optional APIs?
> It has been suggested by some that this no longer represents the CS concept
> of an optional monad and should be a distinct type. I'm not sure I really
> see why (purity of mapping C++ to theoretical CS aside).
>
> Thanks for reading,
> Vitali
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: vlovich@gmail.com
Date: Wed, 24 Jun 2015 16:12:01 -0700 (PDT)
Raw View
------=_Part_68_1911600840.1435187521742
Content-Type: multipart/alternative;
boundary="----=_Part_69_1919958760.1435187521742"
------=_Part_69_1919958760.1435187521742
Content-Type: text/plain; charset=UTF-8
I was hoping that it was purely just to get a solid foundation in place.
I'll try to write-up a proposal & post it to the ML for feedback.
On Wednesday, June 24, 2015 at 3:59:06 PM UTC-7, Jeffrey Yasskin wrote:
>
> I'd be happy to see a paper fleshing this out. I don't think anyone
> was opposed to the idea, but it would have slowed down the initial
> optional<> proposal if it had been included. Now is a great time to
> try to add the feature.
>
> On Wed, Jun 24, 2015 at 9:55 AM, <vlo...@gmail.com <javascript:>> wrote:
> > Hi,
> >
> > I'd like to bring up this topic again. I know Andrzej brought it up a
> > couple of years ago for tr2 but I think I have a different take.
> > First, I'd like to motivate the discussion with the limitations of the
> > current approach.
> >
> > For small types optional can double the size of storage
> > Overhead can add up when stored in arrays (& most of it due to padding
> if
> > the sizeof(T) > 1).
> > Cannot be used as a drop-in in a memory-mapped structure. In these
> > scenarios it's not uncommon to have a sentinel value.
> > Cannot be used in as a drop-in in existing code that uses a sentinel
> (i.e
> > type-safety)
> > Lots of overhead when a struct contains lots of optionals. For example,
> > protobuf uses bit-packing for this.
> >
> > The main limitation, at least as I see it, of the Andrzej's traits
> > implementation is that it cannot be customized per-instance of optional.
> > This is probably fine for user-defined types but makes this optimization
> not
> > possible for built-in types. It's not uncommon to have only certain
> > instances of built-in types have invalid bit-patterns (e.g. NaN for
> double,
> > maximum value for size_t as reported by std::string).
> >
> >
> > To that end, my proposal to accomplish something like this would require
> > adding a secondary template parameter that defines the storage of the
> > initialization state. Here is a straw-man skeleton example of what the
> > std::optional class interface might look like. constexpr omitted for
> > simplicity but I don't see anything preventing it & optional_storage is
> the
> > hypothetical :
> >
> >
> > template <typename T, typename S =
> default_optional_initialization_storage>
> > class optional {
> > public:
> > optional(std::nullopt_t)
> > {
> >
> >
> std::get<0>(_data).set_initialized(reinterpret_cast<T*>(&std::get<1>(_data)),
>
> > false);
> > }
> >
> > optional(const T&)
> > {
> >
> >
> std::get<0>(_data).set_initialized(reinterpret_cast<T*>(&std::get<1>(_data)),
>
> > true);
> > }
> > ...
> > bool is_initialized() const
> > {
> > return std::get<0>(_data).is_initialized();
> > }
> > ...
> > private:
> > std::tuple<S, aligned_storage_t<sizeof(T)>> _data;
> > };
> >
> > default_optional_initialization_storage would comply with the interface
> for
> > optional_initialization_storage & look something like:
> >
> >
> > struct default_optional_initialization_storage {
> > template <typename T>
> > bool is_initialized(T*) const
> > {
> > return _initialized;
> > }
> >
> > template <typename T>
> > void set_initialized(T*, bool initialized)
> > {
> > _initialized = initialized;
> > }
> >
> > bool _initialized = false;
> > };
> >
> >
> > An example for hiding the state as via NaN for double:
> >
> > struct nan_optional_storage {
> > bool is_initialized(double* value) const
> > {
> > return !std::isnan(*value)
> > }
> >
> > void set_initialized(double* value, bool initialized)
> > {
> > if (!initialized) {
> > *value = std::numeric_limits<double>::quite_NaN();
> > }
> > }
> > };
> >
> >
> > Some of my thoughts on this sample code:
> >
> > It is by no means an exaustive implementation and I'm sure there's lots
> of
> > nitpicking to be done over details/naming/etc. I just want to get a
> sense
> > of does something like this even make sense.
> > This is purely a mechanism through which optional can be optimized with
> > domain-specific knowledge. There is no optimization suggested for
> built-in
> > types (e.g. not even pointer types would optimize the nullptr case by
> > default).
> > The sentinel-value use-case would probably be important enough that a
> simple
> > API for expressing such a sentinel value would be valuable (something
> like
> > optional<double, sentinel<double, nan("")>>)
> > This is purely a customization point to apply domain-specific knowledge
> to
> > optimize optional. There is no optimization available by default.
> > The careful reader will note that the bit-packing case has not been
> > addressed. I am not quite certain how to actually achieve this since
> the
> > storage lives external to the optional<> itself. Passing through some
> kind
> > of ctx in all optional APIs?
> > It has been suggested by some that this no longer represents the CS
> concept
> > of an optional monad and should be a distinct type. I'm not sure I
> really
> > see why (purity of mapping C++ to theoretical CS aside).
> >
> > Thanks for reading,
> > Vitali
> >
> > --
> >
> > ---
> > 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-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>
> > Visit this group at
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_69_1919958760.1435187521742
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I was hoping that it was purely just to get a solid founda=
tion in place. I'll try to write-up a proposal & post it to the M=
L for feedback.<br><br>On Wednesday, June 24, 2015 at 3:59:06 PM UTC-7, Jef=
frey Yasskin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I'd be happ=
y to see a paper fleshing this out. I don't think anyone
<br>was opposed to the idea, but it would have slowed down the initial
<br>optional<> proposal if it had been included. Now is a great time =
to
<br>try to add the feature.
<br>
<br>On Wed, Jun 24, 2015 at 9:55 AM, <<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"e637B4yaegIJ" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;">vlo...@gmail.com</a>> wrote:
<br>> Hi,
<br>>
<br>> I'd like to bring up this topic again. I know Andrzej brough=
t it up a
<br>> couple of years ago for tr2 but I think I have a different take.
<br>> First, I'd like to motivate the discussion with the limitations of=
the
<br>> current approach.
<br>>
<br>> For small types optional can double the size of storage
<br>> Overhead can add up when stored in arrays (& most of it due to=
padding if
<br>> the sizeof(T) > 1).
<br>> Cannot be used as a drop-in in a memory-mapped structure. In=
these
<br>> scenarios it's not uncommon to have a sentinel value.
<br>> Cannot be used in as a drop-in in existing code that uses a sentin=
el (i.e
<br>> type-safety)
<br>> Lots of overhead when a struct contains lots of optionals. F=
or example,
<br>> protobuf uses bit-packing for this.
<br>>
<br>> The main limitation, at least as I see it, of the Andrzej's traits
<br>> implementation is that it cannot be customized per-instance of opt=
ional.
<br>> This is probably fine for user-defined types but makes this optimi=
zation not
<br>> possible for built-in types. It's not uncommon to have only =
certain
<br>> instances of built-in types have invalid bit-patterns (e.g. NaN fo=
r double,
<br>> maximum value for size_t as reported by std::string).
<br>>
<br>>
<br>> To that end, my proposal to accomplish something like this would r=
equire
<br>> adding a secondary template parameter that defines the storage of =
the
<br>> initialization state. Here is a straw-man skeleton example o=
f what the
<br>> std::optional class interface might look like. constexpr omitted f=
or
<br>> simplicity but I don't see anything preventing it & optional_s=
torage is the
<br>> hypothetical :
<br>>
<br>>
<br>> template <typename T, typename S =3D default_optional_<wbr>init=
ialization_storage>
<br>> class optional {
<br>> public:
<br>> optional(std::nullopt_t)
<br>> {
<br>>
<br>> std::get<0>(_data).set_<wbr>initialized(reinterpret_cast<=
<wbr>T*>(&std::get<1>(_data)),
<br>> false);
<br>> }
<br>>
<br>> optional(const T&)
<br>> {
<br>>
<br>> std::get<0>(_data).set_<wbr>initialized(reinterpret_cast<=
<wbr>T*>(&std::get<1>(_data)),
<br>> true);
<br>> }
<br>> ...
<br>> bool is_initialized() const
<br>> {
<br>> return std::get<0>(_data).is_<wb=
r>initialized();
<br>> }
<br>> ...
<br>> private:
<br>> std::tuple<S, aligned_storage_t<sizeof(T)>&=
gt; _data;
<br>> };
<br>>
<br>> default_optional_<wbr>initialization_storage would comply with the=
interface for
<br>> optional_initialization_<wbr>storage & look something like:
<br>>
<br>>
<br>> struct default_optional_<wbr>initialization_storage {
<br>> template <typename T>
<br>> bool is_initialized(T*) const
<br>> {
<br>> return _initialized;
<br>> }
<br>>
<br>> template <typename T>
<br>> void set_initialized(T*, bool initialized)
<br>> {
<br>> _initialized =3D initialized;
<br>> }
<br>>
<br>> bool _initialized =3D false;
<br>> };
<br>>
<br>>
<br>> An example for hiding the state as via NaN for double:
<br>>
<br>> struct nan_optional_storage {
<br>> bool is_initialized(double* value) const
<br>> {
<br>> return !std::isnan(*value)
<br>> }
<br>>
<br>> void set_initialized(double* value, bool initialized=
)
<br>> {
<br>> if (!initialized) {
<br>> *value =3D std::numeric_=
limits<double>::<wbr>quite_NaN();
<br>> }
<br>> }
<br>> };
<br>>
<br>>
<br>> Some of my thoughts on this sample code:
<br>>
<br>> It is by no means an exaustive implementation and I'm sure there's=
lots of
<br>> nitpicking to be done over details/naming/etc. I just want t=
o get a sense
<br>> of does something like this even make sense.
<br>> This is purely a mechanism through which optional can be optimized=
with
<br>> domain-specific knowledge. There is no optimization suggeste=
d for built-in
<br>> types (e.g. not even pointer types would optimize the nullptr case=
by
<br>> default).
<br>> The sentinel-value use-case would probably be important enough tha=
t a simple
<br>> API for expressing such a sentinel value would be valuable (someth=
ing like
<br>> optional<double, sentinel<double, nan("")>>)
<br>> This is purely a customization point to apply domain-specific know=
ledge to
<br>> optimize optional. There is no optimization available by def=
ault.
<br>> The careful reader will note that the bit-packing case has not bee=
n
<br>> addressed. I am not quite certain how to actually achieve th=
is since the
<br>> storage lives external to the optional<> itself. Passi=
ng through some kind
<br>> of ctx in all optional APIs?
<br>> It has been suggested by some that this no longer represents the C=
S concept
<br>> of an optional monad and should be a distinct type. I'm not =
sure I really
<br>> see why (purity of mapping C++ to theoretical CS aside).
<br>>
<br>> Thanks for reading,
<br>> Vitali
<br>>
<br>> --
<br>>
<br>> ---
<br>> You received this message because you are subscribed to the Google=
Groups
<br>> "ISO C++ Standard - Future Proposals" group.
<br>> To unsubscribe from this group and stop receiving emails from it, =
send an
<br>> email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"e637B4yaegIJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';return true;">std=
-proposal...@<wbr>isocpp.org</a>.
<br>> To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"e637B4yaegIJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">std-pr...@isocpp.org</a>.
<br>> Visit this group at
<br>> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://=
groups.google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=
=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/=
';return true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>p=
roposals/</a>.
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_69_1919958760.1435187521742--
------=_Part_68_1911600840.1435187521742--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 24 Jun 2015 20:47:18 -0500
Raw View
--001a11c3bad813f8e105194dd026
Content-Type: text/plain; charset=UTF-8
On 24 June 2015 at 17:58, 'Jeffrey Yasskin' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
> I'd be happy to see a paper fleshing this out. I don't think anyone
> was opposed to the idea, but it would have slowed down the initial
> optional<> proposal if it had been included.
Ahem. I was strongly against it when it came up on this list two years
ago, and I'm still strongly against it now. This could be slightly tapered
by proposing a separate type instead of shoehorning it into optional. If
it were to be shoehorned into optional, I'd be strongly against optional
going into C++17, and that would make me sad.
Either way, I believe that it would take a *significant* amount of
committee time to discuss. You have to revisit every issue that optional
and variant touched, including the issues with the empty state of variant,
because now you may not be able to no throw construct the disengaged
state. All this for a type that is so important yet hasn't been
implemented by the people claiming it is so important.
It isn't fair to encourage someone to write up a paper and fly to Kona if
we aren't going to spend enough time to give useful feedback. Do you
really think we'll have that light a load in Kona?
--
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/.
--001a11c3bad813f8e105194dd026
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 24 June 2015 at 17:58, 'Jeffrey Yasskin' via IS=
O C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:s=
td-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>>=
</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">I'd be happy to see a paper fleshing this o=
ut. I don't think anyone<br>
was opposed to the idea, but it would have slowed down the initial<br>
optional<> proposal if it had been included. </blockquote><div><br></=
div><div>Ahem.=C2=A0 I was strongly against it when it came up on this list=
two years ago, and I'm still strongly against it now.=C2=A0 This could=
be slightly tapered by proposing a separate type instead of shoehorning it=
into optional.=C2=A0 If it were to be shoehorned into optional, I'd be=
strongly against optional going into C++17, and that would make me sad.</d=
iv><div><br></div><div>Either way, I believe that it would take a <i>signif=
icant</i> amount of committee time to discuss.=C2=A0 You have to revisit ev=
ery issue that optional and variant touched, including the issues with the =
empty state of variant, because now you may not be able to no throw constru=
ct the disengaged state.=C2=A0 All this for a type that is so important yet=
hasn't been implemented by the people claiming it is so important.</di=
v><div><br></div><div>It isn't fair to encourage someone to write up a =
paper and fly to Kona if we aren't going to spend enough time to give u=
seful feedback.=C2=A0 Do you really think we'll have that light a load =
in Kona?</div></div>-- <br><div class=3D"gmail_signature">=C2=A0Nevin "=
;:-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com"=
target=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 (847) 691-1404</div=
>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c3bad813f8e105194dd026--
.
Author: Fabio Fracassi <f.fracassi@gmx.net>
Date: Thu, 25 Jun 2015 10:08:43 +0200
Raw View
This is a multi-part message in MIME format.
--------------000201020909030505010200
Content-Type: text/plain; charset=UTF-8; format=flowed
On 25.06.2015 03:47, Nevin Liber wrote:
> On 24 June 2015 at 17:58, 'Jeffrey Yasskin' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>> wrote:
>
> I'd be happy to see a paper fleshing this out. I don't think anyone
> was opposed to the idea, but it would have slowed down the initial
> optional<> proposal if it had been included.
>
>
> Ahem. I was strongly against it when it came up on this list two
> years ago, and I'm still strongly against it now. This could be
> slightly tapered by proposing a separate type instead of shoehorning
> it into optional.
I think a separate type should be part of the design discussion, but I
for one would prefer this to be integrated into optional because I see
this as a semantically identical optimization.
> If it were to be shoehorned into optional, I'd be strongly against
> optional going into C++17, and that would make me sad.
>
I on the other hand would be rather sad if we couldn't use optional to
improve code like string::find without introducing overhead.
> Either way, I believe that it would take a /significant/ amount of
> committee time to discuss. You have to revisit every issue that
> optional and variant touched,
I don't think this is a fair characterization. There are some
interactions and probably subtleties that need to be disscussed, but
hardly every interaction. It is mostly an implementation detail.
> including the issues with the empty state of variant, because now you
> may not be able to no throw construct the disengaged state.
I don't see how this follows, we could very well specify this to be
no-throw, without inhibiting any of the motivating use-cases.
Best regards
Fabio
--
---
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/.
--------------000201020909030505010200
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
<br>
<div class=3D"moz-cite-prefix">On 25.06.2015 03:47, Nevin Liber wrote:<=
br>
</div>
<blockquote
cite=3D"mid:CAGg_6+O2-E1avXd54qXw_yNVRc3dCw6ZS=3DbvE=3DGpoWWTT9FjuQ@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">On 24 June 2015 at 17:58, 'Jeffrey Yasskin' via ISO
C++ Standard - Future Proposals <span dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-=
proposals@isocpp.org</a>></span>
wrote:<br>
<div class=3D"gmail_extra">
<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">I'd be
happy to see a paper fleshing this out. I don't think
anyone<br>
was opposed to the idea, but it would have slowed down the
initial<br>
optional<> proposal if it had been included. </blockquo=
te>
<div><br>
</div>
<div>Ahem.=C2=A0 I was strongly against it when it came up on
this list two years ago, and I'm still strongly against it
now.=C2=A0 This could be slightly tapered by proposing a
separate type instead of shoehorning it into optional. <br>
</div>
</div>
</div>
</div>
</blockquote>
I think a separate type should be part of the design discussion, but
I for one would prefer this to be integrated into optional because I
see this as a semantically identical optimization.<br>
<br>
<blockquote
cite=3D"mid:CAGg_6+O2-E1avXd54qXw_yNVRc3dCw6ZS=3DbvE=3DGpoWWTT9FjuQ@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div> If it were to be shoehorned into optional, I'd be
strongly against optional going into C++17, and that would
make me sad.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
I on the other hand would be rather sad if we couldn't use optional
to improve code like string::find without introducing overhead.<br>
<br>
<blockquote
cite=3D"mid:CAGg_6+O2-E1avXd54qXw_yNVRc3dCw6ZS=3DbvE=3DGpoWWTT9FjuQ@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>Either way, I believe that it would take a <i>significant<=
/i>
amount of committee time to discuss.=C2=A0 You have to revisi=
t
every issue that optional and variant touched,</div>
</div>
</div>
</div>
</blockquote>
I don't think this is a fair characterization. There are some
interactions and probably subtleties that need to be disscussed, but
hardly every interaction. It is mostly an implementation detail.<br>
<br>
<blockquote
cite=3D"mid:CAGg_6+O2-E1avXd54qXw_yNVRc3dCw6ZS=3DbvE=3DGpoWWTT9FjuQ@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div> including the issues with the empty state of variant,
because now you may not be able to no throw construct the
disengaged state. <br>
</div>
</div>
</div>
</div>
</blockquote>
I don't see how this follows, we could very well specify this to be
no-throw, without inhibiting any of the motivating use-cases.<br>
<br>
Best regards<br>
<br>
Fabio<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------000201020909030505010200--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 25 Jun 2015 10:31:24 -0400
Raw View
--001a11340b065d789e0519587aad
Content-Type: text/plain; charset=UTF-8
Are you only against it because it might delay optional, or for
technical/design reasons?
(avoiding delay is a valid reason to me, just wondering if there were other
objections)
On Wed, Jun 24, 2015 at 9:47 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 24 June 2015 at 17:58, 'Jeffrey Yasskin' via ISO C++ Standard - Future
> Proposals <std-proposals@isocpp.org> wrote:
>
>> I'd be happy to see a paper fleshing this out. I don't think anyone
>> was opposed to the idea, but it would have slowed down the initial
>> optional<> proposal if it had been included.
>
>
> Ahem. I was strongly against it when it came up on this list two years
> ago, and I'm still strongly against it now. This could be slightly tapered
> by proposing a separate type instead of shoehorning it into optional. If
> it were to be shoehorned into optional, I'd be strongly against optional
> going into C++17, and that would make me sad.
>
> Either way, I believe that it would take a *significant* amount of
> committee time to discuss. You have to revisit every issue that optional
> and variant touched, including the issues with the empty state of variant,
> because now you may not be able to no throw construct the disengaged
> state. All this for a type that is so important yet hasn't been
> implemented by the people claiming it is so important.
>
> It isn't fair to encourage someone to write up a paper and fly to Kona if
> we aren't going to spend enough time to give useful feedback. Do you
> really think we'll have that light a load in Kona?
> --
> 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/.
>
--
---
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/.
--001a11340b065d789e0519587aad
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Are you only against it because it might delay option=
al, or for technical/design reasons?<br><br></div>(avoiding delay is a vali=
d reason to me, just wondering if there were other objections)<br><br><div>=
<div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jun =
24, 2015 at 9:47 PM, Nevin Liber <span dir=3D"ltr"><<a href=3D"mailto:ne=
vin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>></spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D=
"">On 24 June 2015 at 17:58, 'Jeffrey Yasskin' via ISO C++ Standard=
- Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@i=
socpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:=
<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span clas=
s=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">I'd be happy to see a paper flesh=
ing this out. I don't think anyone<br>
was opposed to the idea, but it would have slowed down the initial<br>
optional<> proposal if it had been included. </blockquote><div><br></=
div></span><div>Ahem.=C2=A0 I was strongly against it when it came up on th=
is list two years ago, and I'm still strongly against it now.=C2=A0 Thi=
s could be slightly tapered by proposing a separate type instead of shoehor=
ning it into optional.=C2=A0 If it were to be shoehorned into optional, I&#=
39;d be strongly against optional going into C++17, and that would make me =
sad.</div><div><br></div><div>Either way, I believe that it would take a <i=
>significant</i> amount of committee time to discuss.=C2=A0 You have to rev=
isit every issue that optional and variant touched, including the issues wi=
th the empty state of variant, because now you may not be able to no throw =
construct the disengaged state.=C2=A0 All this for a type that is so import=
ant yet hasn't been implemented by the people claiming it is so importa=
nt.</div><div><br></div><div>It isn't fair to encourage someone to writ=
e up a paper and fly to Kona if we aren't going to spend enough time to=
give useful feedback.=C2=A0 Do you really think we'll have that light =
a load in Kona?</div></div><span class=3D"HOEnZb"><font color=3D"#888888">-=
- <br><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&g=
t;=C2=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=
=3D"_blank">(847) 691-1404</a></div>
</font></span></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11340b065d789e0519587aad--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 25 Jun 2015 10:34:39 -0500
Raw View
--001a11c23d9cedfd750519595e39
Content-Type: text/plain; charset=UTF-8
On 25 June 2015 at 09:31, Tony V E <tvaneerd@gmail.com> wrote:
> Are you only against it because it might delay optional, or for
> technical/design reasons?
>
Both.
If optional significantly changes, then any user experience we have so far
gets thrown out the window. I'm fine if that happens because of the user
experience, but I'm not fine with that for the purposes of invention.
Especially if optional is a vocabulary type being targeted for C++17.
As for technical considerations:
One of the mental models we used for designing optional was that it is a T
with an extra state. This customization breaks that model.
We would have to revisit every single line of optional to see if it still
holds true.
For purposes of this, lets assume I want an optional<string> where
string("Geronimo") is the unengaged state.
Let us start with the simplest constructors:
constexpr optional() noexcept;
constexpr optional(nullopt_t) noexcept;
They are obviously no longer noexecept(true). Do we make that
conditionally noexcept? If so, how? This customization will be as
complicated as allocators (such as a
noexcept_on_nullopt_t_construction_or_assignment member type derived from
bool_type).
How about assignment? Take
optional<T>& operator=(nullopt_t) noexcept;
Besides the noexcept issue, what state is the optional left in when an
exception is thrown? Beats me.
And those are the simpler things. We haven't even gotten to the more
controversial stuff, like heterogeneous comparisons and ordering.
And there may language issues. As proposed:
template <typename T>
void set_initialized(T*, bool initialized)
The T* being passed may be a pointer to uninitialized storage and not a T.
Is that legal?
LEWG likes to "time box" discussions (which I strongly disagree with,
because it basically means we aren't giving the author enough feedback to
make useful progress, making it poor use of both the author's time and the
committee's time. If we don't have the time to adequately discuss things,
why are we soliciting for more stuff?). Based on how much committee time
has been and will be spent on optional and variant, do you really think we
can get through this kind of proposal in only an hour or two? I don't.
Now, a significant portion of the complexity goes away if it is a separate
type, because a separate type can just store a T instead of a block of
storage it has to manage, the ordering can be identical to T, etc.
--
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/.
--001a11c23d9cedfd750519595e39
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 2=
5 June 2015 at 09:31, Tony V E <span dir=3D"ltr"><<a href=3D"mailto:tvan=
eerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr"><div>Are you only against it because i=
t might delay optional, or for technical/design reasons?<br></div></div></b=
lockquote><div><br></div><div>Both.</div><div><br></div><div>If optional si=
gnificantly changes, then any user experience we have so far gets thrown ou=
t the window. I'm fine if that happens because of the user experience, =
but I'm not fine with that for the purposes of invention.=C2=A0 Especia=
lly if optional is a vocabulary type being targeted for C++17.</div><div><b=
r></div><div><br></div><div>As for technical considerations:</div><div><br>=
</div><div>One of the mental models we used for designing optional was that=
it is a T with an extra state.=C2=A0 This customization breaks that model.=
<br></div><div><br></div><div>We would have to revisit every single line of=
optional to see if it still holds true.</div><div><br></div><div>For purpo=
ses of this, lets assume I want an optional<string> where string(&quo=
t;Geronimo") is the unengaged state.</div><div><br></div><div>Let us s=
tart with the simplest constructors:</div><div><br></div><div><pre style=3D=
"margin-left:1em;margin-top:0.5em;margin-bottom:0.5em;color:rgb(0,0,0)"><co=
de style=3D"white-space:inherit"> constexpr optional() noexcept;
</code></pre><pre style=3D"margin-left:1em;margin-top:0.5em;margin-bottom:0=
..5em;color:rgb(0,0,0)"><code style=3D"white-space:inherit"> constexpr opti=
onal(nullopt_t) noexcept;
</code></pre></div><div><br></div><div>They are obviously no longer noexece=
pt(true).=C2=A0 Do we make that conditionally noexcept?=C2=A0 If so, how?=
=C2=A0 This customization will be as complicated as allocators (such as a n=
oexcept_on_nullopt_t_construction_or_assignment member type derived from bo=
ol_type).</div><div><br></div><div>How about assignment?=C2=A0 Take</div><d=
iv><br></div><div><pre style=3D"margin-top:0px;margin-bottom:0px;color:rgb(=
0,0,0)"><code style=3D"white-space:inherit"> optional<T>& oper=
ator=3D(nullopt_t) noexcept;<br></code></pre></div><div><code style=3D"whit=
e-space:inherit"><div style=3D"font-family:arial,sans-serif">Besides the no=
except issue, what state is the optional left in when an exception is throw=
n?=C2=A0 Beats me.</div><div style=3D"font-family:arial,sans-serif"><br></d=
iv><div style=3D"font-family:arial,sans-serif">And those are the simpler th=
ings.=C2=A0 We haven't even gotten to the more controversial stuff, lik=
e heterogeneous comparisons and ordering.</div><div style=3D"font-family:ar=
ial,sans-serif"><br></div><div style=3D"font-family:arial,sans-serif">And t=
here may language issues.=C2=A0 As proposed:</div><div style=3D"font-family=
:arial,sans-serif"><br></div></code><div style=3D"font-family:arial,sans-se=
rif"><code style=3D"white-space:inherit"><span style=3D"font-family:monospa=
ce;font-size:10.4000005722046px;color:rgb(0,0,0);background-color:rgb(250,2=
50,250)">=C2=A0 =C2=A0 template <typename T><br>=C2=A0 =C2=A0=C2=A0</=
span><span style=3D"font-family:monospace;font-size:10.4000005722046px;colo=
r:rgb(0,0,136);background-color:rgb(250,250,250)">void</span><span style=3D=
"font-family:monospace;font-size:10.4000005722046px;color:rgb(0,0,0);backgr=
ound-color:rgb(250,250,250)">=C2=A0set_initialized</span><span style=3D"fon=
t-family:monospace;font-size:10.4000005722046px;color:rgb(102,102,0);backgr=
ound-color:rgb(250,250,250)">(</span><span style=3D"font-family:monospace;f=
ont-size:10.4000005722046px;color:rgb(102,102,0);background-color:rgb(250,2=
50,250)"><code><code><code><span style=3D"color:rgb(0,0,0)"><code><span sty=
le=3D"color:rgb(102,102,0)"></span><span style=3D"color:rgb(102,102,0)"><co=
de><span style=3D"color:rgb(0,0,0)">T*,=C2=A0</span></code></span></code></=
span></code></code></code></span></code><span style=3D"font-family:monospac=
e;font-size:10.4000005722046px;color:rgb(102,102,0);background-color:rgb(25=
0,250,250)"><code><code><code><span style=3D"color:rgb(0,0,0)"><code><span =
style=3D"color:rgb(102,102,0)"><code><span style=3D"color:rgb(0,0,0)"><code=
><code><span style=3D"color:rgb(0,0,136)">bool</span></code></code>=C2=A0in=
itialized</span></code></span></code></span></code></code></code></span><sp=
an style=3D"font-family:monospace;font-size:10.4000005722046px;color:rgb(0,=
0,0);background-color:rgb(250,250,250)">)<br></span></div><div style=3D"fon=
t-family:arial,sans-serif"><span style=3D"font-family:monospace;font-size:1=
0.4000005722046px;color:rgb(0,0,0);background-color:rgb(250,250,250)"><br><=
/span></div><div style=3D"font-family:arial,sans-serif"><div class=3D"gmail=
_quote">The T* being passed may be a pointer to uninitialized storage and n=
ot a T.=C2=A0 Is that legal?</div><div class=3D"gmail_quote"><br></div></di=
v><div style=3D"font-family:arial,sans-serif">LEWG likes to "time box&=
quot; discussions (which I strongly disagree with, because it basically mea=
ns we aren't giving the author enough feedback to make useful progress,=
making it poor use of both the author's time and the committee's t=
ime.=C2=A0 If we don't have the time to adequately discuss things, why =
are we soliciting for more stuff?).=C2=A0 Based on how much committee time =
has been and will be spent on optional and variant, do you really think we =
can get through this kind of proposal in only an hour or two?=C2=A0 I don&#=
39;t.</div></div><div style=3D"font-family:arial,sans-serif"><br></div><div=
style=3D"font-family:arial,sans-serif"><br></div><div style=3D"font-family=
:arial,sans-serif">Now, a significant portion of the complexity goes away i=
f it is a separate type, because a separate type can just store a T instead=
of a block of storage it has to manage, the ordering can be identical to T=
, etc.</div></div>-- <br><div class=3D"gmail_signature">=C2=A0Nevin ":=
-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" t=
arget=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 (847) 691-1404</div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c23d9cedfd750519595e39--
.
Author: vlovich@gmail.com
Date: Thu, 25 Jun 2015 10:58:38 -0700 (PDT)
Raw View
------=_Part_1250_1168177641.1435255118725
Content-Type: multipart/alternative;
boundary="----=_Part_1251_1266111413.1435255118725"
------=_Part_1251_1266111413.1435255118725
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Somehow my reply e-mail had been swallowed.
On Thursday, June 25, 2015 at 8:35:23 AM UTC-7, Nevin ":-)" Liber wrote:
>
> On 25 June 2015 at 09:31, Tony V E <tvan...@gmail.com <javascript:>>=20
> wrote:
>
>> Are you only against it because it might delay optional, or for=20
>> technical/design reasons?
>>
>
> Both.
>
> If optional significantly changes, then any user experience we have so fa=
r=20
> gets thrown out the window. I'm fine if that happens because of the user=
=20
> experience, but I'm not fine with that for the purposes of invention. =20
> Especially if optional is a vocabulary type being targeted for C++17.
>
>
> As for technical considerations:
>
> One of the mental models we used for designing optional was that it is a =
T=20
> with an extra state. This customization breaks that model.
>
> We would have to revisit every single line of optional to see if it still=
=20
> holds true.
>
> For purposes of this, lets assume I want an optional<string> where=20
> string("Geronimo") is the unengaged state.
>
> Let us start with the simplest constructors:
>
> constexpr optional() noexcept;
>
> constexpr optional(nullopt_t) noexcept;
>
>
> They are obviously no longer noexecept(true). Do we make that=20
> conditionally noexcept? If so, how? This customization will be as=20
> complicated as allocators (such as a=20
> noexcept_on_nullopt_t_construction_or_assignment member type derived from=
=20
> bool_type).
>
> How about assignment? Take
>
> optional<T>& operator=3D(nullopt_t) noexcept;
>
> Besides the noexcept issue, what state is the optional left in when an=20
> exception is thrown? Beats me.
>
I=E2=80=99m not as familiar with the issues so I=E2=80=99m probably misunde=
rstanding your=20
concern. Is it that every custom specialization of optional must be able=
=20
to no-throw construct the disengaged state? I think you raise a good point=
=20
with noexcept. I would probably solve that in v1 by just mandating that=20
setting the disengaged state must be a nothrow operation & throwing will=20
invoke std::terminate (just as it does now). If a throwable version of=20
this becomes desirable, the stricter semantics could probably be weakend=20
and maintain backward compatability; starting with maintaining existing=20
noexcept semantics seems like the right first step.
And those are the simpler things. We haven't even gotten to the more=20
> controversial stuff, like heterogeneous comparisons and ordering.
>
Can you clarify why you think those would be affected? I'm sure I'm=20
missing something obvious. It seems to me like whatever=20
comparison/ordering is defined currently would work equally since it has to=
=20
take into account the disengaged state which is now accessible via a=20
function call instead of assuming it's in a separate boolean.
And there may language issues. As proposed:
>
> template <typename T>
> void set_initialized(T*, bool initialized)
>
> The T* being passed may be a pointer to uninitialized storage and not a=
=20
> T. Is that legal?
>
That was just a strawman. I'm still mulling over how it would actually be=
=20
implemented & it's definitely. It would be good to know if this is=20
illegal; at first glance it doesn't seem so since it doesn't seem uncommon=
=20
to have a pointer to uninitialized storage (e.g. std::vector after a=20
reserve).
=20
>
> LEWG likes to "time box" discussions (which I strongly disagree with,=20
> because it basically means we aren't giving the author enough feedback to=
=20
> make useful progress, making it poor use of both the author's time and th=
e=20
> committee's time. If we don't have the time to adequately discuss things=
,=20
> why are we soliciting for more stuff?). Based on how much committee time=
=20
> has been and will be spent on optional and variant, do you really think w=
e=20
> can get through this kind of proposal in only an hour or two? I don't.
>
I=E2=80=99m just following the process as outlined in=20
https://isocpp.org/std/submit-a-proposal
I=E2=80=99ve floated the idea.
The next step I was planning on proposing a first draft of a paper for more=
=20
feedback of what a concrete proposal might look like.
Perhaps after I=E2=80=99ve done steps 2 & 3 we can see if the process has b=
een=20
completed in time for submitting it for Kona & whether the proposal is as=
=20
complicated as you fear?
I certainly appreciate your feedback. I hadn't thought about noexcept &=20
I'll make sure to incorporate it in the proposal. Are there any issues you=
=20
forsee?
=20
> Now, a significant portion of the complexity goes away if it is a separat=
e=20
> type, because a separate type can just store a T instead of a block of=20
> storage it has to manage, the ordering can be identical to T, etc.
>
I like Fabio's phrasing; this is a semantically identical optimization. =20
Introducing a new type for an implementation detail doesn't seem, at least=
=20
at first glance, to be a desirable behaviour. In any case, I will=20
certainly raise your concerns in the draft as a point
of discussion.
--=20
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> (847)=
=20
> 691-1404
> =20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1251_1266111413.1435255118725
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Somehow my reply e-mail had been swallowed.<br><br><br>On =
Thursday, June 25, 2015 at 8:35:23 AM UTC-7, Nevin ":-)" Liber wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote">On 25 June 2015 at 09:31, Tony V E <span dir=3D"ltr"><<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"SLX_4zZA9V4J"=
rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" on=
click=3D"this.href=3D'javascript:';return true;">tvan...@gmail.com</a>><=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>Are you only agains=
t it because it might delay optional, or for technical/design reasons?<br><=
/div></div></blockquote><div><br></div><div>Both.</div><div><br></div><div>=
If optional significantly changes, then any user experience we have so far =
gets thrown out the window. I'm fine if that happens because of the user ex=
perience, but I'm not fine with that for the purposes of invention. E=
specially if optional is a vocabulary type being targeted for C++17.</div><=
div><br></div><div><br></div><div>As for technical considerations:</div><di=
v><br></div><div>One of the mental models we used for designing optional wa=
s that it is a T with an extra state. This customization breaks that =
model.<br></div><div><br></div><div>We would have to revisit every single l=
ine of optional to see if it still holds true.</div><div><br></div><div>For=
purposes of this, lets assume I want an optional<string> where strin=
g("Geronimo") is the unengaged state.</div><div><br></div><div>Let us start=
with the simplest constructors:</div><div><br></div><div><pre style=3D"mar=
gin-left:1em;margin-top:0.5em;margin-bottom:0.5em;color:rgb(0,0,0)"><code s=
tyle=3D"white-space:inherit"> constexpr optional() noexcept;
</code></pre><pre style=3D"margin-left:1em;margin-top:0.5em;margin-bottom:0=
..5em;color:rgb(0,0,0)"><code style=3D"white-space:inherit"> constexpr opti=
onal(nullopt_t) noexcept;
</code></pre></div><div><br></div><div>They are obviously no longer noexece=
pt(true). Do we make that conditionally noexcept? If so, how?&n=
bsp; This customization will be as complicated as allocators (such as a noe=
xcept_on_nullopt_t_<wbr>construction_or_assignment member type derived from=
bool_type).</div><div><br></div><div>How about assignment? Take</div=
><div><br></div><div><pre style=3D"margin-top:0px;margin-bottom:0px;color:r=
gb(0,0,0)"><code style=3D"white-space:inherit"> optional<T>& o=
perator=3D(nullopt_t) noexcept;<br></code></pre></div><div><code style=3D"w=
hite-space:inherit"><div style=3D"font-family:arial,sans-serif">Besides the=
noexcept issue, what state is the optional left in when an exception is th=
rown? Beats me.</div></code></div></div></div></div></blockquote><div=
><br>I=E2=80=99m not as familiar with the issues so I=E2=80=99m probably mi=
sunderstanding
your concern. Is it that every custom specialization of optional mus=
t=20
be able to no-throw construct the disengaged state? I think you raise=
a
good point with noexcept. I would probably solve that in v1 by just =
mandating that setting the disengaged state must be a nothrow operation &am=
p; throwing will invoke std::terminate (just as it does now). If a th=
rowable version of this becomes desirable, the stricter semantics could pro=
bably be weakend and maintain backward compatability; starting with maintai=
ning existing noexcept semantics seems like the right first step.<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><div=
class=3D"gmail_quote"><div><code style=3D"white-space:inherit"><div style=
=3D"font-family:arial,sans-serif">And those are the simpler things. W=
e haven't even gotten to the more controversial stuff, like heterogeneous c=
omparisons and ordering.</div></code></div></div></div></div></blockquote><=
div>Can you clarify why you think those would be affected? I'm sure I=
'm missing something obvious. It seems to me like whatever comparison=
/ordering is defined currently would work equally since it has to take into=
account the disengaged state which is now accessible via a function call i=
nstead of assuming it's in a separate boolean.<br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quo=
te"><div><code style=3D"white-space:inherit"><div style=3D"font-family:aria=
l,sans-serif">And there may language issues. As proposed:</div><div s=
tyle=3D"font-family:arial,sans-serif"><br></div></code><div style=3D"font-f=
amily:arial,sans-serif"><code style=3D"white-space:inherit"><span style=3D"=
font-family:monospace;font-size:10.4000005722046px;color:rgb(0,0,0);backgro=
und-color:rgb(250,250,250)"> template <typename T><br>&n=
bsp; </span><span style=3D"font-family:monospace;font-size:10.4=
000005722046px;color:rgb(0,0,136);background-color:rgb(250,250,250)">void</=
span><span style=3D"font-family:monospace;font-size:10.4000005722046px;colo=
r:rgb(0,0,0);background-color:rgb(250,250,250)"> set_initialized</span=
><span style=3D"font-family:monospace;font-size:10.4000005722046px;color:rg=
b(102,102,0);background-color:rgb(250,250,250)">(</span><span style=3D"font=
-family:monospace;font-size:10.4000005722046px;color:rgb(102,102,0);backgro=
und-color:rgb(250,250,250)"><code><code><code><span style=3D"color:rgb(0,0,=
0)"><code><span style=3D"color:rgb(102,102,0)"></span><span style=3D"color:=
rgb(102,102,0)"><code><span style=3D"color:rgb(0,0,0)">T*, </span></co=
de></span></code></span></code></code></code></span></code><span style=3D"f=
ont-family:monospace;font-size:10.4000005722046px;color:rgb(102,102,0);back=
ground-color:rgb(250,250,250)"><code><code><code><span style=3D"color:rgb(0=
,0,0)"><code><span style=3D"color:rgb(102,102,0)"><code><span style=3D"colo=
r:rgb(0,0,0)"><code><code><span style=3D"color:rgb(0,0,136)">boo<wbr>l</spa=
n></code></code> initialized</span></code></span></code></span></code>=
</code></code></span><span style=3D"font-family:monospace;font-size:10.4000=
005722046px;color:rgb(0,0,0);background-color:rgb(250,250,250)">)<br></span=
></div><div style=3D"font-family:arial,sans-serif"><span style=3D"font-fami=
ly:monospace;font-size:10.4000005722046px;color:rgb(0,0,0);background-color=
:rgb(250,250,250)"><br></span></div><div style=3D"font-family:arial,sans-se=
rif"><div class=3D"gmail_quote">The T* being passed may be a pointer to uni=
nitialized storage and not a T. Is that legal?</div></div></div></div=
></div></div></blockquote><div>That was just a strawman. I'm still mu=
lling over how it would actually be implemented & it's definitely. =
; It would be good to know if this is illegal; at first glance it doesn't s=
eem so since it doesn't seem uncommon to have a pointer to uninitialized st=
orage (e.g. std::vector after a reserve).<br> <br></div><blockquote cl=
ass=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_qu=
ote"><div><div style=3D"font-family:arial,sans-serif"><div class=3D"gmail_q=
uote"><br></div></div><div style=3D"font-family:arial,sans-serif">LEWG like=
s to "time box" discussions (which I strongly disagree with, because it bas=
ically means we aren't giving the author enough feedback to make useful pro=
gress, making it poor use of both the author's time and the committee's tim=
e. If we don't have the time to adequately discuss things, why are we=
soliciting for more stuff?). Based on how much committee time has be=
en and will be spent on optional and variant, do you really think we can ge=
t through this kind of proposal in only an hour or two? I don't.</div=
></div></div></div></div></blockquote><div><br>I=E2=80=99m just following t=
he process as outlined in https://isocpp.org/std/submit-a-proposal<br>I=E2=
=80=99ve floated the idea.<br>The next step I was planning on proposing a f=
irst draft of a paper for more feedback of what a concrete proposal might l=
ook like.<br><br>Perhaps after I=E2=80=99ve done steps 2 & 3 we can see=
if the process has been completed in time for submitting it for Kona &=
whether the proposal is as complicated as you fear?<br>I certainly appreci=
ate your feedback. I hadn't thought about noexcept & I'll make su=
re to incorporate it in the proposal. Are there any issues you forsee=
?<br> <br></div><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"><div style=3D"font-family:arial,sa=
ns-serif">Now, a significant portion of the complexity goes away if it is a=
separate type, because a separate type can just store a T instead of a blo=
ck of storage it has to manage, the ordering can be identical to T, etc.</d=
iv></div></div></div></blockquote><div>I like Fabio's phrasing; this is a s=
emantically identical optimization. Introducing a new type for an imp=
lementation detail doesn't seem, at least at first glance, to be a desirabl=
e behaviour. In any case, I will certainly raise your concerns in the=
draft as a point<br>of discussion.<br><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div>-- <br><div> Nevin ":-)" Libe=
r <mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"SLX_4zZA9V4J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';return true;">ne=
....@eviloverlord.com</a><wbr>> (847) 691-1404</div>
</div></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1251_1266111413.1435255118725--
------=_Part_1250_1168177641.1435255118725--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 25 Jun 2015 13:53:25 -0500
Raw View
--001a11c3bad8cca6fe05195c258b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 25 June 2015 at 12:58, <vlovich@gmail.com> wrote:
> I=E2=80=99m not as familiar with the issues so I=E2=80=99m probably misun=
derstanding your
> concern. Is it that every custom specialization of optional must be able
> to no-throw construct the disengaged state?
>
No, but you weren't proposing to specialize optional. You were proposing
to add a second policy-like template parameter to optional. Those are two
very different things.
If you are specializing it, I really have to question why it has to be
spelled o-p-t-i-o-n-a-l, as it really isn't substitutable in generic
constructs (which is the main reason to have them spelled the same way).
Shades of vector<bool> all over again...
> And those are the simpler things. We haven't even gotten to the more
>> controversial stuff, like heterogeneous comparisons and ordering.
>>
> Can you clarify why you think those would be affected? I'm sure I'm
> missing something obvious. It seems to me like whatever
> comparison/ordering is defined currently would work equally since it has =
to
> take into account the disengaged state which is now accessible via a
> function call instead of assuming it's in a separate boolean.
>
The disengaged state is smaller than every state of T, in both homogeneous
(optional<T> vs optional<T>) and heterogeneous (optional<T> vs T)
comparisons. Do you intend for that to hold, in which case comparing two
engaged optionals now behaves differently than comparing the values they
hold.
>
> And there may language issues. As proposed:
>>
>> template <typename T>
>> void set_initialized(T*, bool initialized)
>>
>> The T* being passed may be a pointer to uninitialized storage and not a
>> T. Is that legal?
>>
> That was just a strawman. I'm still mulling over how it would actually b=
e
> implemented & it's definitely. It would be good to know if this is
> illegal; at first glance it doesn't seem so since it doesn't seem uncommo=
n
> to have a pointer to uninitialized storage (e.g. std::vector after a
> reserve).
>
A pointer, such as char* or void*, to uninitialized storage is okay; I'm
not sure about a pointer *of type T* *to uninitialized storage.
> Perhaps after I=E2=80=99ve done steps 2 & 3 we can see if the process ha=
s been
> completed in time for submitting it for Kona & whether the proposal is as
> complicated as you fear?
>
Are you planning on coming to Kona to present it? If not, my advice is to
get someone who was involved with the discussions around optional to do a
deep dive into your proposal and champion it. Jeffrey and Tony are two
good candidates, if they are going and you can convince them.
> I certainly appreciate your feedback. I hadn't thought about noexcept &
> I'll make sure to incorporate it in the proposal. Are there any issues y=
ou
> forsee?
>
I really don't have the time to look at it in detail. I've already spent
(some say wasted) way too much of my life on optional and variant as it
is...
--=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/.
--001a11c3bad8cca6fe05195c258b
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 2=
5 June 2015 at 12:58, <span dir=3D"ltr"><<a href=3D"mailto:vlovich@gmai=
l.com" target=3D"_blank">vlovich@gmail.com</a>></span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div>I=E2=80=99m not as familiar w=
ith the issues so I=E2=80=99m probably misunderstanding
your concern.=C2=A0 Is it that every custom specialization of optional mus=
t=20
be able to no-throw construct the disengaged state?</div></div></blockquote=
><div><br></div><div>No, but you weren't proposing to specialize option=
al.=C2=A0 You were proposing to add a second policy-like template parameter=
to optional.=C2=A0 Those are two very different things.</div><div><br></di=
v><div>If you are specializing it, I really have to question why it has to =
be spelled o-p-t-i-o-n-a-l, as it really isn't substitutable in generic=
constructs (which is the main reason to have them spelled the same way).=
=C2=A0 Shades of vector<bool> all over again...</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_qu=
ote"><div><code style=3D"white-space:inherit"><div style=3D"font-family:ari=
al,sans-serif">And those are the simpler things.=C2=A0 We haven't even =
gotten to the more controversial stuff, like heterogeneous comparisons and =
ordering.</div></code></div></div></div></div></blockquote></span><div>Can =
you clarify why you think those would be affected?=C2=A0 I'm sure I'=
;m missing something obvious.=C2=A0 It seems to me like whatever comparison=
/ordering is defined currently would work equally since it has to take into=
account the disengaged state which is now accessible via a function call i=
nstead of assuming it's in a separate boolean.<br></div></div></blockqu=
ote><div><br></div><div>The disengaged state is smaller than every state of=
T, in both homogeneous (optional<T> vs optional<T>) and hetero=
geneous (optional<T> vs T) comparisons.=C2=A0 Do you intend for that =
to hold, in which case comparing two engaged optionals now behaves differen=
tly than comparing the values they hold.</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"><div dir=3D"ltr"><div><br></div><span class=3D""><blockq=
uote 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><code style=3D"white-space:inherit"><div style=3D"font-family:a=
rial,sans-serif">And there may language issues.=C2=A0 As proposed:</div><di=
v style=3D"font-family:arial,sans-serif"><br></div></code><div style=3D"fon=
t-family:arial,sans-serif"><code style=3D"white-space:inherit"><span style=
=3D"font-family:monospace;font-size:10.4000005722046px;color:rgb(0,0,0);bac=
kground-color:rgb(250,250,250)">=C2=A0 =C2=A0 template <typename T><b=
r>=C2=A0 =C2=A0=C2=A0</span><span style=3D"font-family:monospace;font-size:=
10.4000005722046px;color:rgb(0,0,136);background-color:rgb(250,250,250)">vo=
id</span><span style=3D"font-family:monospace;font-size:10.4000005722046px;=
color:rgb(0,0,0);background-color:rgb(250,250,250)">=C2=A0set_initialized</=
span><span style=3D"font-family:monospace;font-size:10.4000005722046px;colo=
r:rgb(102,102,0);background-color:rgb(250,250,250)">(</span><span style=3D"=
font-family:monospace;font-size:10.4000005722046px;color:rgb(102,102,0);bac=
kground-color:rgb(250,250,250)"><code><code><code><span style=3D"color:rgb(=
0,0,0)"><code><span style=3D"color:rgb(102,102,0)"></span><span style=3D"co=
lor:rgb(102,102,0)"><code><span style=3D"color:rgb(0,0,0)">T*,=C2=A0</span>=
</code></span></code></span></code></code></code></span></code><span style=
=3D"font-family:monospace;font-size:10.4000005722046px;color:rgb(102,102,0)=
;background-color:rgb(250,250,250)"><code><code><code><span style=3D"color:=
rgb(0,0,0)"><code><span style=3D"color:rgb(102,102,0)"><code><span style=3D=
"color:rgb(0,0,0)"><code><code><span style=3D"color:rgb(0,0,136)">bool</spa=
n></code></code>=C2=A0initialized</span></code></span></code></span></code>=
</code></code></span><span style=3D"font-family:monospace;font-size:10.4000=
005722046px;color:rgb(0,0,0);background-color:rgb(250,250,250)">)<br></span=
></div><div style=3D"font-family:arial,sans-serif"><span style=3D"font-fami=
ly:monospace;font-size:10.4000005722046px;color:rgb(0,0,0);background-color=
:rgb(250,250,250)"><br></span></div><div style=3D"font-family:arial,sans-se=
rif"><div class=3D"gmail_quote">The T* being passed may be a pointer to uni=
nitialized storage and not a T.=C2=A0 Is that legal?</div></div></div></div=
></div></div></blockquote></span><div>That was just a strawman.=C2=A0 I'=
;m still mulling over how it would actually be implemented & it's d=
efinitely.=C2=A0 It would be good to know if this is illegal; at first glan=
ce it doesn't seem so since it doesn't seem uncommon to have a poin=
ter to uninitialized storage (e.g. std::vector after a reserve).<br></div><=
/div></blockquote><div><br></div><div>A pointer, such as char* or void*, to=
uninitialized storage is okay; I'm not sure about a pointer <i>of type=
T*=C2=A0</i>to uninitialized storage.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>=C2=A0Perhaps after I=E2=80=99ve don=
e steps 2 & 3 we can see if the process has been completed in time for =
submitting it for Kona & whether the proposal is as complicated as you =
fear?</div></div></blockquote><div><br></div><div>Are you planning on comin=
g to Kona to present it?=C2=A0 If not, my advice is to get someone who was =
involved with the discussions around optional to do a deep dive into your p=
roposal and champion it.=C2=A0 Jeffrey and Tony are two good candidates, if=
they are going and you can convince them.</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div>I certainly appreciate your feed=
back.=C2=A0 I hadn't thought about noexcept & I'll make sure to=
incorporate it in the proposal.=C2=A0 Are there any issues you forsee?<br>=
</div></div></blockquote><div><br></div><div>I really don't have the ti=
me to look at it in detail.=C2=A0 I've already spent (some say wasted) =
way too much of my life on optional and variant as it is...</div></div>-- <=
br><div class=3D"gmail_signature">=C2=A0Nevin ":-)" Liber=C2=A0 &=
lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin=
@eviloverlord.com</a>>=C2=A0 (847) 691-1404</div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c3bad8cca6fe05195c258b--
.
Author: vlovich@gmail.com
Date: Thu, 25 Jun 2015 12:22:15 -0700 (PDT)
Raw View
------=_Part_1421_2019403190.1435260135729
Content-Type: multipart/alternative;
boundary="----=_Part_1422_1277857142.1435260135729"
------=_Part_1422_1277857142.1435260135729
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, June 25, 2015 at 11:54:07 AM UTC-7, Nevin ":-)" Liber wrote:
>
> On 25 June 2015 at 12:58, <vlo...@gmail.com <javascript:>> wrote:
>
>> I=E2=80=99m not as familiar with the issues so I=E2=80=99m probably misu=
nderstanding your=20
>> concern. Is it that every custom specialization of optional must be abl=
e=20
>> to no-throw construct the disengaged state?
>>
>
> No, but you weren't proposing to specialize optional. You were proposing=
=20
> to add a second policy-like template parameter to optional. Those are tw=
o=20
> very different things.
>
> If you are specializing it, I really have to question why it has to be=20
> spelled o-p-t-i-o-n-a-l, as it really isn't substitutable in generic=20
> constructs (which is the main reason to have them spelled the same way). =
=20
> Shades of vector<bool> all over again...
>
Well to get an optimized policy, the user would have to specialize it with=
=20
their user-defined policy object. Is that not the right terminology? In=
=20
any case what I meant to say is that does every possible policy need to=20
meet these criteria? I agree the answer is yes where it would otherwise=20
cause complexity in the optional API itself (which seems to be the case=20
with the noexcept cases you pointed out).
And those are the simpler things. We haven't even gotten to the more=20
>>> controversial stuff, like heterogeneous comparisons and ordering.
>>>
>> Can you clarify why you think those would be affected? I'm sure I'm=20
>> missing something obvious. It seems to me like whatever=20
>> comparison/ordering is defined currently would work equally since it has=
to=20
>> take into account the disengaged state which is now accessible via a=20
>> function call instead of assuming it's in a separate boolean.
>>
>
> The disengaged state is smaller than every state of T, in both homogeneou=
s=20
> (optional<T> vs optional<T>) and heterogeneous (optional<T> vs T)=20
> comparisons. Do you intend for that to hold, in which case comparing two=
=20
> engaged optionals now behaves differently than comparing the values they=
=20
> hold.
>
I'm probably being a little thick. Can you clarify with the following=20
implementation of equality where you would see a problem with the=20
implementation?
bool operator=3D=3D(const optional<T, P1>& lhs, const optional<T, P2>& rhs)
{
if (!lhs.is_initialized() ^ rhs.is_initialized()) {
return false;
}
if (lhs.is_initialized() && rhs.is_initialized()) {
return *lhs =3D=3D *rhs;
}
return true;
}
I'm not sure I see a scenario in which it matters what policy lhs or rhs=20
have but you clearly have a lot more expertise working with optional &=20
variant :).
=20
>
>> And there may language issues. As proposed:
>>>
>>> template <typename T>
>>> void set_initialized(T*, bool initialized)
>>>
>>> The T* being passed may be a pointer to uninitialized storage and not a=
=20
>>> T. Is that legal?
>>>
>> That was just a strawman. I'm still mulling over how it would actually=
=20
>> be implemented & it's definitely. It would be good to know if this is=
=20
>> illegal; at first glance it doesn't seem so since it doesn't seem uncomm=
on=20
>> to have a pointer to uninitialized storage (e.g. std::vector after a=20
>> reserve).
>>
>
> A pointer, such as char* or void*, to uninitialized storage is okay; I'm=
=20
> not sure about a pointer *of type T* *to uninitialized storage.
>
I could be misreading it but libc++ seems to use a pointer of type T* to=20
store the internal storage, not char*/void*. It's always possible that=20
libc++ has a bug here but I can't think of any good reason it would be=20
disallowed. Also, I'm pretty sure that placement new can be given a=20
pointer to an uninitialized memory location, although that's of course=20
mostly a language feature so it could have special-casing.
=20
> Perhaps after I=E2=80=99ve done steps 2 & 3 we can see if the process ha=
s been=20
>> completed in time for submitting it for Kona & whether the proposal is a=
s=20
>> complicated as you fear?
>>
>
> Are you planning on coming to Kona to present it? If not, my advice is t=
o=20
> get someone who was involved with the discussions around optional to do a=
=20
> deep dive into your proposal and champion it. Jeffrey and Tony are two=
=20
> good candidates, if they are going and you can convince them.
>
I have nothing against coming to Kona. I would certainly be interested in=
=20
presenting it but I can also work to get champions too. I haven't even=20
presented a draft of a proposal so perhaps discussing Kona is a bit=20
premature?
For all I know there are intractable problems that come up when I flush it=
=20
out fully.
=20
> =20
>
>> I certainly appreciate your feedback. I hadn't thought about noexcept &=
=20
>> I'll make sure to incorporate it in the proposal. Are there any issues =
you=20
>> forsee?
>>
>
> I really don't have the time to look at it in detail. I've already spent=
=20
> (some say wasted) way too much of my life on optional and variant as it=
=20
> is...
> --=20
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> (847)=
=20
> 691-1404
> =20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1422_1277857142.1435260135729
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Thursday, June 25, 2015 at 11:54:07 AM UTC-7, Nevin ":-)" Liber =
wrote:<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><d=
iv class=3D"gmail_quote">On 25 June 2015 at 12:58, <span dir=3D"ltr"><<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"cqxzLutdA=
JgJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;=
" onclick=3D"this.href=3D'javascript:';return true;">vlo...@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I=
=E2=80=99m not as familiar with the issues so I=E2=80=99m probably misunder=
standing
your concern. Is it that every custom specialization of optional mus=
t=20
be able to no-throw construct the disengaged state?</div></div></blockquote=
><div><br></div><div>No, but you weren't proposing to specialize optional.&=
nbsp; You were proposing to add a second policy-like template parameter to =
optional. Those are two very different things.</div><div><br></div><d=
iv>If you are specializing it, I really have to question why it has to be s=
pelled o-p-t-i-o-n-a-l, as it really isn't substitutable in generic constru=
cts (which is the main reason to have them spelled the same way). Sha=
des of vector<bool> all over again...</div></div></div></div></blockq=
uote><div>Well to get an optimized policy, the user would have to specializ=
e it with their user-defined policy object. Is that not the right ter=
minology? In any case what I meant to say is that does every possible=
policy need to meet these criteria? I agree the answer is yes where =
it would otherwise cause complexity in the optional API itself (which seems=
to be the case with the noexcept cases you pointed out).<br><br></div><blo=
ckquote 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 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gma=
il_quote"><div><code style=3D"white-space:inherit"><div style=3D"font-famil=
y:arial,sans-serif">And those are the simpler things. We haven't even=
gotten to the more controversial stuff, like heterogeneous comparisons and=
ordering.</div></code></div></div></div></div></blockquote></span><div>Can=
you clarify why you think those would be affected? I'm sure I'm miss=
ing something obvious. It seems to me like whatever comparison/orderi=
ng is defined currently would work equally since it has to take into accoun=
t the disengaged state which is now accessible via a function call instead =
of assuming it's in a separate boolean.<br></div></div></blockquote><div><b=
r></div><div>The disengaged state is smaller than every state of T, in both=
homogeneous (optional<T> vs optional<T>) and heterogeneous (op=
tional<T> vs T) comparisons. Do you intend for that to hold, in=
which case comparing two engaged optionals now behaves differently than co=
mparing the values they hold.</div></div></div></div></blockquote><div>I'm =
probably being a little thick. Can you clarify with the following imp=
lementation of equality where you would see a problem with the implementati=
on?<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">b=
ool</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">operator</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D(</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> optional</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> P1</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">>&</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> lhs</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</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> optional</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> P2</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">>&</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> rhs</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">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">lhs</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">is_initialized</span><span style=
=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"> rhs</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">is_initialized</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">())</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">return</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">false<=
/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 style=3D"color: #660;" class=3D"styled-by-prettify">}</span><spa=
n style=3D"color: #000;" class=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"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">lhs</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">is_initialized</span><span style=3D"color: #660;" c=
lass=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"> rhs</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">is_i=
nitialized</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 st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">ret=
urn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">lhs </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">=3D=3D</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">rhs</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br><br> </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">return</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">true</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code>=
</div><br>I'm not sure I see a scenario in which it matters what policy lhs=
or rhs have but you clearly have a lot more expertise working with optiona=
l & variant :).<br><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><div class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><br></div><span><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><di=
v><code style=3D"white-space:inherit"><div style=3D"font-family:arial,sans-=
serif">And there may language issues. As proposed:</div><div style=3D=
"font-family:arial,sans-serif"><br></div></code><div style=3D"font-family:a=
rial,sans-serif"><code style=3D"white-space:inherit"><span style=3D"font-fa=
mily:monospace;font-size:10.4000005722046px;color:rgb(0,0,0);background-col=
or:rgb(250,250,250)"> template <typename T><br> &n=
bsp; </span><span style=3D"font-family:monospace;font-size:10.40000057=
22046px;color:rgb(0,0,136);background-color:rgb(250,250,250)">void</span><s=
pan style=3D"font-family:monospace;font-size:10.4000005722046px;color:rgb(0=
,0,0);background-color:rgb(250,250,250)"> set_initialized</span><span =
style=3D"font-family:monospace;font-size:10.4000005722046px;color:rgb(102,1=
02,0);background-color:rgb(250,250,250)">(</span><span style=3D"font-family=
:monospace;font-size:10.4000005722046px;color:rgb(102,102,0);background-col=
or:rgb(250,250,250)"><code><code><code><span style=3D"color:rgb(0,0,0)"><co=
de><span style=3D"color:rgb(102,102,0)"></span><span style=3D"color:rgb(102=
,102,0)"><code><span style=3D"color:rgb(0,0,0)">T*, </span></code></sp=
an></code></span></code></code></code></span></code><span style=3D"font-fam=
ily:monospace;font-size:10.4000005722046px;color:rgb(102,102,0);background-=
color:rgb(250,250,250)"><code><code><code><span style=3D"color:rgb(0,0,0)">=
<code><span style=3D"color:rgb(102,102,0)"><code><span style=3D"color:rgb(0=
,0,0)"><code><code><span style=3D"color:rgb(0,0,136)">boo<wbr>l</span></cod=
e></code> initialized</span></code></span></code></span></code></code>=
</code></span><span style=3D"font-family:monospace;font-size:10.40000057220=
46px;color:rgb(0,0,0);background-color:rgb(250,250,250)">)<br></span></div>=
<div style=3D"font-family:arial,sans-serif"><span style=3D"font-family:mono=
space;font-size:10.4000005722046px;color:rgb(0,0,0);background-color:rgb(25=
0,250,250)"><br></span></div><div style=3D"font-family:arial,sans-serif"><d=
iv class=3D"gmail_quote">The T* being passed may be a pointer to uninitiali=
zed storage and not a T. Is that legal?</div></div></div></div></div>=
</div></blockquote></span><div>That was just a strawman. I'm still mu=
lling over how it would actually be implemented & it's definitely. =
; It would be good to know if this is illegal; at first glance it doesn't s=
eem so since it doesn't seem uncommon to have a pointer to uninitialized st=
orage (e.g. std::vector after a reserve).<br></div></div></blockquote><div>=
<br></div><div>A pointer, such as char* or void*, to uninitialized storage =
is okay; I'm not sure about a pointer <i>of type T* </i>to uninitializ=
ed storage.</div></div></div></div></blockquote><div>I could be misreading =
it but libc++ seems to use a pointer of type T* to store the internal stora=
ge, not char*/void*. It's always possible that libc++ has a bug here =
but I can't think of any good reason it would be disallowed. Also, I'=
m pretty sure that placement new can be given a pointer to an uninitialized=
memory location, although that's of course mostly a language feature so it=
could have special-casing.<br> <br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div> Perhaps after I=E2=80=99v=
e done steps 2 & 3 we can see if the process has been completed in time=
for submitting it for Kona & whether the proposal is as complicated as=
you fear?</div></div></blockquote><div><br></div><div>Are you planning on =
coming to Kona to present it? If not, my advice is to get someone who=
was involved with the discussions around optional to do a deep dive into y=
our proposal and champion it. Jeffrey and Tony are two good candidate=
s, if they are going and you can convince them.</div></div></div></div></bl=
ockquote><div>I have nothing against coming to Kona. I would certainl=
y be interested in presenting it but I can also work to get champions too.&=
nbsp; I haven't even presented a draft of a proposal so perhaps discussing =
Kona is a bit premature?<br>For all I know there are intractable problems t=
hat come up when I flush it out fully.<br> <br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
"><div> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I c=
ertainly appreciate your feedback. I hadn't thought about noexcept &a=
mp; I'll make sure to incorporate it in the proposal. Are there any i=
ssues you forsee?<br></div></div></blockquote><div><br></div><div>I really =
don't have the time to look at it in detail. I've already spent (some=
say wasted) way too much of my life on optional and variant as it is...</d=
iv></div>-- <br><div> Nevin ":-)" Liber <mailto:<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"cqxzLutdAJgJ" rel=3D"=
nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D=
"this.href=3D'javascript:';return true;">ne...@eviloverlord.com</a><wbr>>=
; (847) 691-1404</div>
</div></div>
</blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1422_1277857142.1435260135729--
------=_Part_1421_2019403190.1435260135729--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 25 Jun 2015 14:59:16 -0500
Raw View
--001a11c3bad847847e05195d1163
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 25 June 2015 at 14:22, <vlovich@gmail.com> wrote:
>
>
> On Thursday, June 25, 2015 at 11:54:07 AM UTC-7, Nevin ":-)" Liber wrote:
>>
>> On 25 June 2015 at 12:58, <vlo...@gmail.com> wrote:
>>
>>> I=E2=80=99m not as familiar with the issues so I=E2=80=99m probably mis=
understanding
>>> your concern. Is it that every custom specialization of optional must =
be
>>> able to no-throw construct the disengaged state?
>>>
>>
>> No, but you weren't proposing to specialize optional. You were proposin=
g
>> to add a second policy-like template parameter to optional. Those are t=
wo
>> very different things.
>>
>> If you are specializing it, I really have to question why it has to be
>> spelled o-p-t-i-o-n-a-l, as it really isn't substitutable in generic
>> constructs (which is the main reason to have them spelled the same way).
>> Shades of vector<bool> all over again...
>>
> Well to get an optimized policy, the user would have to specialize it wit=
h
> their user-defined policy object. Is that not the right terminology?
>
vector<bool> is a specialization of vector, and has a different interface
than vector. That is very different than, say, providing an allocator
(which is basically a policy) to a vector.
> In any case what I meant to say is that does every possible policy need
> to meet these criteria?
>
It is in the interface for optional, so either it does or you change the
interface. You get to explore the design space.
> The disengaged state is smaller than every state of T, in both homogeneou=
s
>> (optional<T> vs optional<T>) and heterogeneous (optional<T> vs T)
>> comparisons. Do you intend for that to hold, in which case comparing tw=
o
>> engaged optionals now behaves differently than comparing the values they
>> hold.
>>
> I'm probably being a little thick. Can you clarify with the following
> implementation of equality where you would see a problem with the
> implementation?
>
> bool operator=3D=3D(const optional<T, P1>& lhs, const optional<T, P2>& rh=
s)
> {
> if (!lhs.is_initialized() ^ rhs.is_initialized()) {
> return false;
> }
>
> if (lhs.is_initialized() && rhs.is_initialized()) {
> return *lhs =3D=3D *rhs;
> }
>
> return true;
> }
>
>
Say you use NaN for your disengaged value.
float f =3D std::numeric_limits<float>::quiet_NaN();
assert(!(f=3D=3Df));
assert(!(optional<float>(f) =3D=3D optional<float>(f))); // fails
assert(!(optional<float>(f) =3D=3D f)); // fails
assert(!(f =3D=3D optional<float>(f))); // fails
Now, I'm perfectly willing (although others on the committee are not) to
say that non-regular types such as float are insane, and equality
comparisons aren't a problem for regular types.
However, ordered comparisons are different. Using string("Geronimo") as
the disengaged value:
string s =3D "Geronimo";
string t =3D "Geronim";
assert(t < s);
assert(optional<string>(t) < optional<string>(s)); // fails
assert(optional<string>(t) < s); // fails
assert(t < optional<string>(s)); // fails
Is that the desired behavior? As part of your proposal, you explore the
design space, pick something, and then LEWG will debate it if they really
want the feature.
> I have nothing against coming to Kona. I would certainly be interested i=
n
> presenting it but I can also work to get champions too. I haven't even
> presented a draft of a proposal so perhaps discussing Kona is a bit
> premature?
> For all I know there are intractable problems that come up when I flush i=
t
> out fully.
>
My general advice is that people attend a meeting or two before making a
proposal, so that can see what they are in for. Roughly speaking, it's
like defending a dissertation in front of a panel of people who don't
really care if you graduate. You are the domain expert fielding tough
questions from other (domain and non-domain) experts, as well as from
people like me.
I do realize that it sometimes takes a proposal to get an employer to send
someone to a meeting, in which case I advise not picking something too
ambitious. IMO, this is a very ambitious proposal. Of course, other
committee members may feel otherwise and be willing to put in the
preparatory effort so that it gets a fair chance. We are all volunteers
and speak only for ourselves or those we represent, as no one speaks for
the committee.
--=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/.
--001a11c3bad847847e05195d1163
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 2=
5 June 2015 at 14:22, <span dir=3D"ltr"><<a href=3D"mailto:vlovich@gmai=
l.com" target=3D"_blank">vlovich@gmail.com</a>></span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex"><br><br>On Thursday, June 25, 2015 at 11:54:07 AM UTC-7, Nevin &q=
uot;:-)" Liber wrote:<span class=3D""><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color=
:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr=
"><div><div class=3D"gmail_quote">On 25 June 2015 at 12:58, <span dir=3D"l=
tr"><<a rel=3D"nofollow">vlo...@gmail.com</a>></span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div>I=E2=80=99m not as familiar with the issu=
es so I=E2=80=99m probably misunderstanding
your concern.=C2=A0 Is it that every custom specialization of optional mus=
t=20
be able to no-throw construct the disengaged state?</div></div></blockquote=
><div><br></div><div>No, but you weren't proposing to specialize option=
al.=C2=A0 You were proposing to add a second policy-like template parameter=
to optional.=C2=A0 Those are two very different things.</div><div><br></di=
v><div>If you are specializing it, I really have to question why it has to =
be spelled o-p-t-i-o-n-a-l, as it really isn't substitutable in generic=
constructs (which is the main reason to have them spelled the same way).=
=C2=A0 Shades of vector<bool> all over again...</div></div></div></di=
v></blockquote></span><div>Well to get an optimized policy, the user would =
have to specialize it with their user-defined policy object.=C2=A0 Is that =
not the right terminology?</div></blockquote><div><br></div><div>vector<=
bool> is a specialization of vector, and has a different interface than =
vector.=C2=A0 That is very different than, say, providing an allocator (whi=
ch is basically a policy) to a vector.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x"><div>=C2=A0 In any case what I meant to say is that does every possible =
policy need to meet these criteria?=C2=A0</div></blockquote><div><br></div>=
<div>It is in the interface for optional, so either it does or you change t=
he interface.=C2=A0 You get to explore the design space.</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex"><span class=3D""><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote"><div>The disengaged state is smaller than ever=
y state of T, in both homogeneous (optional<T> vs optional<T>) =
and heterogeneous (optional<T> vs T) comparisons.=C2=A0 Do you intend=
for that to hold, in which case comparing two engaged optionals now behave=
s differently than comparing the values they hold.</div></div></div></div><=
/blockquote></span><div>I'm probably being a little thick.=C2=A0 Can yo=
u clarify with the following implementation of equality where you would see=
a problem with the implementation?<br><br><div style=3D"border:1px solid r=
gb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><co=
de><div><span style=3D"color:rgb(0,0,136)">bool</span><span style=3D"color:=
rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">operator</span><span=
style=3D"color:rgb(102,102,0)">=3D=3D(</span><span style=3D"color:rgb(0,0,=
136)">const</span><span style=3D"color:rgb(0,0,0)"> optional</span><span st=
yle=3D"color:rgb(102,102,0)"><</span><span style=3D"color:rgb(0,0,0)">T<=
/span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb=
(0,0,0)"> P1</span><span style=3D"color:rgb(102,102,0)">>&</span><sp=
an style=3D"color:rgb(0,0,0)"> lhs</span><span style=3D"color:rgb(102,102,0=
)">,</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rg=
b(0,0,136)">const</span><span style=3D"color:rgb(0,0,0)"> optional</span><s=
pan style=3D"color:rgb(102,102,0)"><</span><span style=3D"color:rgb(0,0,=
0)">T</span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"col=
or:rgb(0,0,0)"> P2</span><span style=3D"color:rgb(102,102,0)">>&</sp=
an><span style=3D"color:rgb(0,0,0)"> rhs</span><span style=3D"color:rgb(102=
,102,0)">)</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D=
"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color:rgb(0,0,136)">if</span><span style=3D"co=
lor:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">(!</span><span=
style=3D"color:rgb(0,0,0)">lhs</span><span style=3D"color:rgb(102,102,0)">=
..</span><span style=3D"color:rgb(0,0,0)">is_initialized</span><span style=
=3D"color:rgb(102,102,0)">()</span><span style=3D"color:rgb(0,0,0)"> </span=
><span style=3D"color:rgb(102,102,0)">^</span><span style=3D"color:rgb(0,0,=
0)"> rhs</span><span style=3D"color:rgb(102,102,0)">.</span><span style=3D"=
color:rgb(0,0,0)">is_initialized</span><span style=3D"color:rgb(102,102,0)"=
>())</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rg=
b(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">return</span><span =
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">false=
</span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rg=
b(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(102,102,0)">}</=
span><span style=3D"color:rgb(0,0,0)"><br><br>=C2=A0 =C2=A0 </span><span st=
yle=3D"color:rgb(0,0,136)">if</span><span style=3D"color:rgb(0,0,0)"> </spa=
n><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0=
,0)">lhs</span><span style=3D"color:rgb(102,102,0)">.</span><span style=3D"=
color:rgb(0,0,0)">is_initialized</span><span style=3D"color:rgb(102,102,0)"=
>()</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb=
(102,102,0)">&&</span><span style=3D"color:rgb(0,0,0)"> rhs</span><=
span style=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)=
">is_initialized</span><span style=3D"color:rgb(102,102,0)">())</span><span=
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{<=
/span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </sp=
an><span style=3D"color:rgb(0,0,136)">return</span><span style=3D"color:rgb=
(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">*</span><span style=
=3D"color:rgb(0,0,0)">lhs </span><span style=3D"color:rgb(102,102,0)">=3D=
=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb=
(102,102,0)">*</span><span style=3D"color:rgb(0,0,0)">rhs</span><span style=
=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=
=A0 =C2=A0 </span><span style=3D"color:rgb(102,102,0)">}</span><span style=
=3D"color:rgb(0,0,0)"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb=
(0,0,136)">return</span><span style=3D"color:rgb(0,0,0)"> </span><span styl=
e=3D"color:rgb(0,0,136)">true</span><span style=3D"color:rgb(102,102,0)">;<=
/span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(=
102,102,0)">}</span><span style=3D"color:rgb(0,0,0)"><br></span></div></cod=
e></div><br></div></blockquote><div><br></div><div>Say you use NaN for your=
disengaged value.</div><div><br></div><div>float f =3D std::numeric_limits=
<float>::quiet_NaN();<br></div><div>assert(!(f=3D=3Df));</div><div><d=
iv>assert(!(optional<float>(f) =3D=3D optional<float>(f))); // =
fails</div></div><div><div><div>assert(!(optional<float>(f) =3D=3D f)=
); // fails</div></div></div><div><div>assert(!(f =3D=3D optional<float&=
gt;(f))); // fails</div></div><div><br></div><div>Now, I'm perfectly wi=
lling (although others on the committee are not) to say that non-regular ty=
pes such as float are insane, and equality comparisons aren't a problem=
for regular types.</div><div><br></div><div>However, ordered comparisons a=
re different.=C2=A0 Using string("Geronimo") as the disengaged va=
lue:</div><div><br></div><div>string s =3D "Geronimo";</div><div>=
string t =3D "Geronim";</div><div><br></div><div>assert(t < s)=
;</div><div>assert(optional<string>(t) < optional<string>(s)=
); // fails</div><div>assert(optional<string>(t) < s); // fails</d=
iv><div>assert(t < optional<string>(s)); // fails</div><div><br></=
div><div>Is that the desired behavior?=C2=A0 As part of your proposal, you =
explore the design space, pick something, and then LEWG will debate it if t=
hey really want the feature.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>I =
have nothing against coming to Kona.=C2=A0 I would certainly be interested =
in presenting it but I can also work to get champions too.=C2=A0 I haven=
9;t even presented a draft of a proposal so perhaps discussing Kona is a bi=
t premature?<br>For all I know there are intractable problems that come up =
when I flush it out fully.<br></div></blockquote><div><br></div><div>My gen=
eral advice is that people attend a meeting or two before making a proposal=
, so that can see what they are in for.=C2=A0 Roughly speaking, it's li=
ke defending a dissertation in front of a panel of people who don't rea=
lly care if you graduate.=C2=A0 You are the domain expert fielding tough qu=
estions from other (domain and non-domain) experts, as well as from people =
like me.</div><div><br></div><div>I do realize that it sometimes takes a pr=
oposal to get an employer to send someone to a meeting, in which case I adv=
ise not picking something too ambitious.=C2=A0 IMO, this is a very ambitiou=
s proposal.=C2=A0 Of course, other committee members may feel otherwise and=
be willing to put in the preparatory effort so that it gets a fair chance.=
=C2=A0 We are all volunteers and speak only for ourselves or those we repre=
sent, as no one speaks for the committee.</div></div>-- <br><div class=3D"g=
mail_signature">=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>>=C2=A0 (847) 691-1404</div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c3bad847847e05195d1163--
.
Author: Sam Kellett <samkellett@gmail.com>
Date: Thu, 25 Jun 2015 22:03:44 +0100
Raw View
--001a113493327e6a6f05195df548
Content-Type: text/plain; charset=UTF-8
>
> My general advice is that people attend a meeting or two before making a
> proposal, so that can see what they are in for. Roughly speaking, it's
> like defending a dissertation in front of a panel of people who don't
> really care if you graduate. You are the domain expert fielding tough
> questions from other (domain and non-domain) experts, as well as from
> people like me.
>
> I do realize that it sometimes takes a proposal to get an employer to send
> someone to a meeting, in which case I advise not picking something too
> ambitious. IMO, this is a very ambitious proposal. Of course, other
> committee members may feel otherwise and be willing to put in the
> preparatory effort so that it gets a fair chance. We are all volunteers
> and speak only for ourselves or those we represent, as no one speaks for
> the committee.
>
As a neutral and with all due respect: perhaps you shouldn't be the one who
provides tips and advice on submitting a proposal? Given how strongly
opposed you to this proposal I'm slightly worried that your advice may be
misconstrued as a slightly underhanded way to scare away a feature you're
not a fan of instead of letting it live or die by it's own right.
(Important: not saying this is what you're doing at all, I just wanted to
point out that it could easily be interpreted this way.)
--
---
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/.
--001a113493327e6a6f05195df548
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><span class=3D""></span><blockq=
uote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex" class=3D"gmail_quote"><div>My general advice is that p=
eople attend a meeting or two before making a proposal, so that can see wha=
t they are in for.=C2=A0 Roughly speaking, it's like defending a disser=
tation in front of a panel of people who don't really care if you gradu=
ate.=C2=A0 You are the domain expert fielding tough questions from other (d=
omain and non-domain) experts, as well as from people like me.</div><div><b=
r></div><div>I do realize that it sometimes takes a proposal to get an empl=
oyer to send someone to a meeting, in which case I advise not picking somet=
hing too ambitious.=C2=A0 IMO, this is a very ambitious proposal.=C2=A0 Of =
course, other committee members may feel otherwise and be willing to put in=
the preparatory effort so that it gets a fair chance.=C2=A0 We are all vol=
unteers and speak only for ourselves or those we represent, as no one speak=
s for the committee.</div></blockquote><br></div><div class=3D"gmail_extra"=
>As a neutral and with all due respect: perhaps you shouldn't be the on=
e who provides tips and advice on submitting a proposal? Given how strongly=
opposed you to this proposal I'm slightly worried that your advice may=
be misconstrued as a slightly underhanded way to scare away a feature you&=
#39;re not a fan of instead of letting it live or die by it's own right=
..<br><br></div><div class=3D"gmail_extra">(Important: not saying this is wh=
at you're doing at all, I just wanted to point out that it could easily=
be interpreted this way.)<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113493327e6a6f05195df548--
.
Author: jgottman6@gmail.com
Date: Thu, 25 Jun 2015 14:38:21 -0700 (PDT)
Raw View
------=_Part_1038_390070410.1435268301826
Content-Type: multipart/alternative;
boundary="----=_Part_1039_1793290226.1435268301826"
------=_Part_1039_1793290226.1435268301826
Content-Type: text/plain; charset=UTF-8
On Thursday, June 25, 2015 at 4:09:16 AM UTC-4, Fabio Fracassi wrote:
>
>
>
> On 25.06.2015 03:47, Nevin Liber wrote:
>
>
> Either way, I believe that it would take a *significant* amount of
> committee time to discuss. You have to revisit every issue that optional
> and variant touched,
>
> I don't think this is a fair characterization. There are some interactions
> and probably subtleties that need to be disscussed, but hardly every
> interaction. It is mostly an implementation detail.
>
>
> One major difference between your proposed optional<T> and the current
version is the constructors and assignment operators that take a T value.
Currently, if I write code like
optional<size_t> x;
// ...
x = function_returning_a_size_t();
I can assume after the assignment that x contains a value so I don't have
to check it. If we use your version of optional that uses a sentinel value
(for instance std::string::npos) and the function I called can return that
value, I can no longer make that assumption. This is a subtle difference
that can easily cause code to fail.
Joe Gottman
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1039_1793290226.1435268301826
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, June 25, 2015 at 4:09:16 AM UTC-4, Fa=
bio Fracassi wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
<br>
<div>On 25.06.2015 03:47, Nevin Liber wrote:<br>
</div><br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div class=3D"gmail_quote">
<div>Either way, I believe that it would take a <i>significant<=
/i>
amount of committee time to discuss. You have to revisi=
t
every issue that optional and variant touched,</div>
</div>
</div>
</div>
</blockquote>
I don't think this is a fair characterization. There are some
interactions and probably subtleties that need to be disscussed, but
hardly every interaction. It is mostly an implementation detail.<br>
<br><br></div></blockquote><div> One major difference between you=
r proposed optional<T> and the current version is the constructors an=
d assignment operators that take a T value. Currently, if I write cod=
e like<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: #000;" class=3D"styled-by-prettif=
y">optional</span><span style=3D"color: #080;" class=3D"styled-by-prettify"=
><size_t></span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> 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: #800;" class=3D"styled-by-prettify">// ... </span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>x </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> function_returning_a_size_t</sp=
an><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></co=
de></div><br>I can assume after the assignment that x contains a value so I=
don't have to check it. If we use your version of optional that uses=
a sentinel value (for instance std::string::npos) and the function I calle=
d can return that value, I can no longer make that assumption. This i=
s a subtle difference that can easily cause code to fail.<br><br>Joe Gottma=
n<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1039_1793290226.1435268301826--
------=_Part_1038_390070410.1435268301826--
.
Author: vlovich@gmail.com
Date: Thu, 25 Jun 2015 14:54:06 -0700 (PDT)
Raw View
------=_Part_1446_1715458214.1435269246349
Content-Type: multipart/alternative;
boundary="----=_Part_1447_1738241723.1435269246349"
------=_Part_1447_1738241723.1435269246349
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, June 25, 2015 at 12:59:58 PM UTC-7, Nevin ":-)" Liber wrote:
>
> On 25 June 2015 at 14:22, <vlo...@gmail.com <javascript:>> wrote:
>
>>
>>
>> On Thursday, June 25, 2015 at 11:54:07 AM UTC-7, Nevin ":-)" Liber wrote=
:
>>>
>>> On 25 June 2015 at 12:58, <vlo...@gmail.com> wrote:
>>>
>>>> I=E2=80=99m not as familiar with the issues so I=E2=80=99m probably mi=
sunderstanding=20
>>>> your concern. Is it that every custom specialization of optional must=
be=20
>>>> able to no-throw construct the disengaged state?
>>>>
>>>
>>> No, but you weren't proposing to specialize optional. You were=20
>>> proposing to add a second policy-like template parameter to optional. =
=20
>>> Those are two very different things.
>>>
>>> If you are specializing it, I really have to question why it has to be=
=20
>>> spelled o-p-t-i-o-n-a-l, as it really isn't substitutable in generic=20
>>> constructs (which is the main reason to have them spelled the same way)=
.. =20
>>> Shades of vector<bool> all over again...
>>>
>> Well to get an optimized policy, the user would have to specialize it=20
>> with their user-defined policy object. Is that not the right terminolog=
y?
>>
>
> vector<bool> is a specialization of vector, and has a different interface=
=20
> than vector. That is very different than, say, providing an allocator=20
> (which is basically a policy) to a vector.
> =20
>
>> In any case what I meant to say is that does every possible policy nee=
d=20
>> to meet these criteria?=20
>>
>
> It is in the interface for optional, so either it does or you change the=
=20
> interface. You get to explore the design space.
> =20
>
>> The disengaged state is smaller than every state of T, in both=20
>>> homogeneous (optional<T> vs optional<T>) and heterogeneous (optional<T>=
vs=20
>>> T) comparisons. Do you intend for that to hold, in which case comparin=
g=20
>>> two engaged optionals now behaves differently than comparing the values=
=20
>>> they hold.
>>>
>> I'm probably being a little thick. Can you clarify with the following=
=20
>> implementation of equality where you would see a problem with the=20
>> implementation?
>>
>> bool operator=3D=3D(const optional<T, P1>& lhs, const optional<T, P2>& r=
hs)
>> {
>> if (!lhs.is_initialized() ^ rhs.is_initialized()) {
>> return false;
>> }
>>
>> if (lhs.is_initialized() && rhs.is_initialized()) {
>> return *lhs =3D=3D *rhs;
>> }
>>
>> return true;
>> }
>>
>>
> Say you use NaN for your disengaged value.
>
> float f =3D std::numeric_limits<float>::quiet_NaN();
> assert(!(f=3D=3Df));
> assert(!(optional<float>(f) =3D=3D optional<float>(f))); // fails
>
This is actually still true. I'm assuming you meant if you include a=20
policy where it's folded into the nan:
assert (!(optional<float, nan_sentinel>(f) =3D=3D optional<float,=20
nan_sentinel>(f))); // fails because both are disengaged as per the policy
assert (!(optional<float, nan_sentinel>(f) =3D=3D optional<float>(f))); //=
=20
fails because lhs is disengaged.
assert(!(optional<float>(f) =3D=3D f)); // fails
>
This still passes. However:
assert (!(optional<float, nan_seninel>(f) =3D=3D f))) // fails because lhs =
is=20
disengaged.
If NaN is a valid value, then you either need to find a different sentinel=
=20
or realize that an optimized policy won't work for you.
assert(!(f =3D=3D optional<float>(f))); // fails
>
> Now, I'm perfectly willing (although others on the committee are not) to=
=20
> say that non-regular types such as float are insane, and equality=20
> comparisons aren't a problem for regular types.
>
> However, ordered comparisons are different. Using string("Geronimo") as=
=20
> the disengaged value:
>
> string s =3D "Geronimo";
> string t =3D "Geronim";
>
> assert(t < s);
> assert(optional<string>(t) < optional<string>(s)); // fails
> assert(optional<string>(t) < s); // fails
> assert(t < optional<string>(s)); // fails
>
> Is that the desired behavior? As part of your proposal, you explore the=
=20
> design space, pick something, and then LEWG will debate it if they really=
=20
> want the feature.
>
Yes it is. The sentinel value is defined to be the disengaged state &=20
cannot be represented as a valid value. If the above assertions are=20
unexpected then the policy
is incorrectly implemented.
=20
> I have nothing against coming to Kona. I would certainly be interested i=
n=20
>> presenting it but I can also work to get champions too. I haven't even=
=20
>> presented a draft of a proposal so perhaps discussing Kona is a bit=20
>> premature?
>> For all I know there are intractable problems that come up when I flush=
=20
>> it out fully.
>>
>
> My general advice is that people attend a meeting or two before making a=
=20
> proposal, so that can see what they are in for. Roughly speaking, it's=
=20
> like defending a dissertation in front of a panel of people who don't=20
> really care if you graduate. You are the domain expert fielding tough=20
> questions from other (domain and non-domain) experts, as well as from=20
> people like me.
>
> I do realize that it sometimes takes a proposal to get an employer to sen=
d=20
> someone to a meeting, in which case I advise not picking something too=20
> ambitious. IMO, this is a very ambitious proposal. Of course, other=20
> committee members may feel otherwise and be willing to put in the=20
> preparatory effort so that it gets a fair chance. We are all volunteers=
=20
> and speak only for ourselves or those we represent, as no one speaks for=
=20
> the committee.
> --=20
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> (847)=
=20
> 691-1404
> =20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1447_1738241723.1435269246349
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Thursday, June 25, 2015 at 12:59:58 PM UTC-7, Nevin ":-)" Liber =
wrote:<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><d=
iv class=3D"gmail_quote">On 25 June 2015 at 14:22, <span dir=3D"ltr"><<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"5iukfICxM=
_gJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;=
" onclick=3D"this.href=3D'javascript:';return true;">vlo...@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><br><br>On Thursday, June 25, 2015 at =
11:54:07 AM UTC-7, Nevin ":-)" Liber wrote:<span><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On 25 June 2015 at 12:58, <span d=
ir=3D"ltr"><<a rel=3D"nofollow">vlo...@gmail.com</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex"><div dir=3D"ltr"><div>I=E2=80=99m not as familiar with t=
he issues so I=E2=80=99m probably misunderstanding
your concern. Is it that every custom specialization of optional mus=
t=20
be able to no-throw construct the disengaged state?</div></div></blockquote=
><div><br></div><div>No, but you weren't proposing to specialize optional.&=
nbsp; You were proposing to add a second policy-like template parameter to =
optional. Those are two very different things.</div><div><br></div><d=
iv>If you are specializing it, I really have to question why it has to be s=
pelled o-p-t-i-o-n-a-l, as it really isn't substitutable in generic constru=
cts (which is the main reason to have them spelled the same way). Sha=
des of vector<bool> all over again...</div></div></div></div></blockq=
uote></span><div>Well to get an optimized policy, the user would have to sp=
ecialize it with their user-defined policy object. Is that not the ri=
ght terminology?</div></blockquote><div><br></div><div>vector<bool> i=
s a specialization of vector, and has a different interface than vector.&nb=
sp; That is very different than, say, providing an allocator (which is basi=
cally a policy) to a vector.</div><div> </div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>&n=
bsp; In any case what I meant to say is that does every possible policy nee=
d to meet these criteria? </div></blockquote><div><br></div><div>It is=
in the interface for optional, so either it does or you change the interfa=
ce. You get to explore the design space.</div><div> </div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex"><span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote"><div>The disengaged state is smaller than every state of T, in both=
homogeneous (optional<T> vs optional<T>) and heterogeneous (op=
tional<T> vs T) comparisons. Do you intend for that to hold, in=
which case comparing two engaged optionals now behaves differently than co=
mparing the values they hold.</div></div></div></div></blockquote></span><d=
iv>I'm probably being a little thick. Can you clarify with the follow=
ing implementation of equality where you would see a problem with the imple=
mentation?<br><br><div style=3D"border:1px solid rgb(187,187,187);word-wrap=
:break-word;background-color:rgb(250,250,250)"><code><div><span style=3D"co=
lor:rgb(0,0,136)">bool</span><span style=3D"color:rgb(0,0,0)"> </span><span=
style=3D"color:rgb(0,0,136)">operator</span><span style=3D"color:rgb(102,1=
02,0)">=3D=3D(</span><span style=3D"color:rgb(0,0,136)">const</span><span s=
tyle=3D"color:rgb(0,0,0)"> optional</span><span style=3D"color:rgb(102,102,=
0)"><</span><span style=3D"color:rgb(0,0,0)">T</span><span style=3D"colo=
r:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> P1</span><span =
style=3D"color:rgb(102,102,0)">>&</span><span style=3D"color:rgb(0,0=
,0)"> lhs</span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D=
"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">const</span><=
span style=3D"color:rgb(0,0,0)"> optional</span><span style=3D"color:rgb(10=
2,102,0)"><</span><span style=3D"color:rgb(0,0,0)">T</span><span style=
=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> P2</spa=
n><span style=3D"color:rgb(102,102,0)">>&</span><span style=3D"color=
:rgb(0,0,0)"> rhs</span><span style=3D"color:rgb(102,102,0)">)</span><span =
style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">=
{</span><span style=3D"color:rgb(0,0,0)"><br> </span><span sty=
le=3D"color:rgb(0,0,136)">if</span><span style=3D"color:rgb(0,0,0)"> </span=
><span style=3D"color:rgb(102,102,0)">(!</span><span style=3D"color:rgb(0,0=
,0)">lhs</span><span style=3D"color:rgb(102,102,0)">.</span><span style=3D"=
color:rgb(0,0,0)">is_initialized</span><span style=3D"color:rgb(102,102,0)"=
>()</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb=
(102,102,0)">^</span><span style=3D"color:rgb(0,0,0)"> rhs</span><span styl=
e=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)">is_init=
ialized</span><span style=3D"color:rgb(102,102,0)">())</span><span style=3D=
"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</span><sp=
an style=3D"color:rgb(0,0,0)"><br> </span><span =
style=3D"color:rgb(0,0,136)">return</span><span style=3D"color:rgb(0,0,0)">=
</span><span style=3D"color:rgb(0,0,136)">false</span><span style=3D"color=
:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br> =
</span><span style=3D"color:rgb(102,102,0)">}</span><span style=3D"color:r=
gb(0,0,0)"><br><br> </span><span style=3D"color:rgb(0,0,136)">=
if</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(=
102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">lhs</span><span style=
=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)">is_initi=
alized</span><span style=3D"color:rgb(102,102,0)">()</span><span style=3D"c=
olor:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">&&</s=
pan><span style=3D"color:rgb(0,0,0)"> rhs</span><span style=3D"color:rgb(10=
2,102,0)">.</span><span style=3D"color:rgb(0,0,0)">is_initialized</span><sp=
an style=3D"color:rgb(102,102,0)">())</span><span style=3D"color:rgb(0,0,0)=
"> </span><span style=3D"color:rgb(102,102,0)">{</span><span style=3D"color=
:rgb(0,0,0)"><br> </span><span style=3D"color:rg=
b(0,0,136)">return</span><span style=3D"color:rgb(0,0,0)"> </span><span sty=
le=3D"color:rgb(102,102,0)">*</span><span style=3D"color:rgb(0,0,0)">lhs </=
span><span style=3D"color:rgb(102,102,0)">=3D=3D</span><span style=3D"color=
:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">*</span><span sty=
le=3D"color:rgb(0,0,0)">rhs</span><span style=3D"color:rgb(102,102,0)">;</s=
pan><span style=3D"color:rgb(0,0,0)"><br> </span><span style=
=3D"color:rgb(102,102,0)">}</span><span style=3D"color:rgb(0,0,0)"><br><br>=
</span><span style=3D"color:rgb(0,0,136)">return</span><span =
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">true<=
/span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb=
(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">}</span><span styl=
e=3D"color:rgb(0,0,0)"><br></span></div></code></div><br></div></blockquote=
><div><br></div><div>Say you use NaN for your disengaged value.</div><div><=
br></div><div>float f =3D std::numeric_limits<float>::<wbr>quiet_NaN(=
);<br></div><div>assert(!(f=3D=3Df));</div><div><div>assert(!(optional<f=
loat>(f) =3D=3D optional<float>(f))); // fails</div></div></div></=
div></div></blockquote><div>This is actually still true. I'm assuming=
you meant if you include a policy where it's folded into the nan:<br>asser=
t (!(optional<float, nan_sentinel>(f) =3D=3D optional<float, nan_s=
entinel>(f))); // fails because both are disengaged as per the policy<br=
>assert (!(optional<float, nan_sentinel>(f) =3D=3D optional<float&=
gt;(f))); // fails because lhs is disengaged.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e"><div><div><div>assert(!(optional<float>(f) =3D=3D f)); // fails</d=
iv></div></div></div></div></div></blockquote><div>This still passes. =
However:<br>assert (!(optional<float, nan_seninel>(f) =3D=3D f))) //=
fails because lhs is disengaged.<br><br>If NaN is a valid value, then you =
either need to find a different sentinel or realize that an optimized polic=
y won't work for you.<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><div class=3D"gmail_quote"><div><div>assert(!(f=
=3D=3D optional<float>(f))); // fails</div></div><div><br></div><div=
>Now, I'm perfectly willing (although others on the committee are not) to s=
ay that non-regular types such as float are insane, and equality comparison=
s aren't a problem for regular types.</div><div><br></div><div>However, ord=
ered comparisons are different. Using string("Geronimo") as the disen=
gaged value:</div><div><br></div><div>string s =3D "Geronimo";</div><div>st=
ring t =3D "Geronim";</div><div><br></div><div>assert(t < s);</div><div>=
assert(optional<string>(t) < optional<string>(s)); // fails<=
/div><div>assert(optional<string>(t) < s); // fails</div><div>asse=
rt(t < optional<string>(s)); // fails</div><div><br></div><div>Is =
that the desired behavior? As part of your proposal, you explore the =
design space, pick something, and then LEWG will debate it if they really w=
ant the feature.</div></div></div></div></blockquote><div>Yes it is. =
The sentinel value is defined to be the disengaged state & cannot be re=
presented as a valid value. If the above assertions are unexpected th=
en the policy<br>is incorrectly implemented.<br> <br></div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style=
:solid;padding-left:1ex"><div>I have nothing against coming to Kona. =
I would certainly be interested in presenting it but I can also work to get=
champions too. I haven't even presented a draft of a proposal so per=
haps discussing Kona is a bit premature?<br>For all I know there are intrac=
table problems that come up when I flush it out fully.<br></div></blockquot=
e><div><br></div><div>My general advice is that people attend a meeting or =
two before making a proposal, so that can see what they are in for. R=
oughly speaking, it's like defending a dissertation in front of a panel of =
people who don't really care if you graduate. You are the domain expe=
rt fielding tough questions from other (domain and non-domain) experts, as =
well as from people like me.</div><div><br></div><div>I do realize that it =
sometimes takes a proposal to get an employer to send someone to a meeting,=
in which case I advise not picking something too ambitious. IMO, thi=
s is a very ambitious proposal. Of course, other committee members ma=
y feel otherwise and be willing to put in the preparatory effort so that it=
gets a fair chance. We are all volunteers and speak only for ourselv=
es or those we represent, as no one speaks for the committee.</div></div>--=
<br><div> Nevin ":-)" Liber <mailto:<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"5iukfICxM_gJ" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">ne...@eviloverlord.com</a><wbr>> (8=
47) 691-1404</div>
</div></div>
</blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1447_1738241723.1435269246349--
------=_Part_1446_1715458214.1435269246349--
.
Author: vlovich@gmail.com
Date: Thu, 25 Jun 2015 14:56:50 -0700 (PDT)
Raw View
------=_Part_1461_232919426.1435269410375
Content-Type: multipart/alternative;
boundary="----=_Part_1462_1961587948.1435269410376"
------=_Part_1462_1961587948.1435269410376
Content-Type: text/plain; charset=UTF-8
On Thursday, June 25, 2015 at 2:38:21 PM UTC-7, jgot...@gmail.com wrote:
>
>
>
> On Thursday, June 25, 2015 at 4:09:16 AM UTC-4, Fabio Fracassi wrote:
>>
>>
>>
>> On 25.06.2015 03:47, Nevin Liber wrote:
>>
>>
>> Either way, I believe that it would take a *significant* amount of
>> committee time to discuss. You have to revisit every issue that optional
>> and variant touched,
>>
>> I don't think this is a fair characterization. There are some
>> interactions and probably subtleties that need to be disscussed, but hardly
>> every interaction. It is mostly an implementation detail.
>>
>>
>> One major difference between your proposed optional<T> and the current
> version is the constructors and assignment operators that take a T value.
> Currently, if I write code like
>
> optional<size_t> x;
> // ...
> x = function_returning_a_size_t();
>
> I can assume after the assignment that x contains a value so I don't have
> to check it. If we use your version of optional that uses a sentinel value
> (for instance std::string::npos) and the function I called can return that
> value, I can no longer make that assumption. This is a subtle difference
> that can easily cause code to fail.
>
> Joe Gottman
>
Correct. That's why optional<size_t> continues to behave the same way.
For example, for the std::string API you could do:
using optional_find = std::optional<size_t, optional_find_policy>;
optional_find x = std::string{"abcd"}.find("efg");
assert (!x);
which is much more elegant I think.
I've prototyped the code forked from Andrzej's branch here:
https://github.com/vlovich/Optional
I've updated test_optional to show what it might look like.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1462_1961587948.1435269410376
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Thursday, June 25, 2015 at 2:38:21 PM UTC-7, jgot...@gmail.com w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>=
On Thursday, June 25, 2015 at 4:09:16 AM UTC-4, Fabio Fracassi wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
<br>
<div>On 25.06.2015 03:47, Nevin Liber wrote:<br>
</div><br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div class=3D"gmail_quote">
<div>Either way, I believe that it would take a <i>significant<=
/i>
amount of committee time to discuss. You have to revisi=
t
every issue that optional and variant touched,</div>
</div>
</div>
</div>
</blockquote>
I don't think this is a fair characterization. There are some
interactions and probably subtleties that need to be disscussed, but
hardly every interaction. It is mostly an implementation detail.<br>
<br><br></div></blockquote><div> One major difference between you=
r proposed optional<T> and the current version is the constructors an=
d assignment operators that take a T value. Currently, if I write cod=
e like<br><br><div style=3D"background-color:rgb(250,250,250);border-color:=
rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word">=
<code><div><span style=3D"color:#000">optional</span><span style=3D"color:#=
080"><size_t></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:#800">// ... </span><span style=3D"color:#000"><br>x </span><span=
style=3D"color:#660">=3D</span><span style=3D"color:#000"> function_return=
ing_a_size_t</span><span style=3D"color:#660">();</span><span style=3D"colo=
r:#000"><br></span></div></code></div><br>I can assume after the assignment=
that x contains a value so I don't have to check it. If we use your =
version of optional that uses a sentinel value (for instance std::string::n=
pos) and the function I called can return that value, I can no longer make =
that assumption. This is a subtle difference that can easily cause co=
de to fail.<br><br>Joe Gottman<br></div></div></blockquote><div>Correct.&nb=
sp; That's why optional<size_t> continues to behave the same way.&nbs=
p; For example, for the std::string API you could do:<br><br>using optional=
_find =3D std::optional<size_t, optional_find_policy>;<br>optional_fi=
nd x =3D std::string{"abcd"}.find("efg");<br>assert (!x);<br><br>which is m=
uch more elegant I think. <br><br>I've prototyped the code forked from Andr=
zej's branch here: https://github.com/vlovich/Optional<br><br>I've updated =
test_optional to show what it might look like.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1462_1961587948.1435269410376--
------=_Part_1461_232919426.1435269410375--
.
Author: vlovich@gmail.com
Date: Thu, 25 Jun 2015 15:18:48 -0700 (PDT)
Raw View
------=_Part_1403_1405183621.1435270728420
Content-Type: multipart/alternative;
boundary="----=_Part_1404_1043452088.1435270728420"
------=_Part_1404_1043452088.1435270728420
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, June 25, 2015 at 2:54:06 PM UTC-7, vlo...@gmail.com wrote:
>
>
>
> On Thursday, June 25, 2015 at 12:59:58 PM UTC-7, Nevin ":-)" Liber wrote:
>>
>> On 25 June 2015 at 14:22, <vlo...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thursday, June 25, 2015 at 11:54:07 AM UTC-7, Nevin ":-)" Liber wrot=
e:
>>>>
>>>> On 25 June 2015 at 12:58, <vlo...@gmail.com> wrote:
>>>>
>>>>> I=E2=80=99m not as familiar with the issues so I=E2=80=99m probably m=
isunderstanding=20
>>>>> your concern. Is it that every custom specialization of optional mus=
t be=20
>>>>> able to no-throw construct the disengaged state?
>>>>>
>>>>
>>>> No, but you weren't proposing to specialize optional. You were=20
>>>> proposing to add a second policy-like template parameter to optional. =
=20
>>>> Those are two very different things.
>>>>
>>>> If you are specializing it, I really have to question why it has to be=
=20
>>>> spelled o-p-t-i-o-n-a-l, as it really isn't substitutable in generic=
=20
>>>> constructs (which is the main reason to have them spelled the same way=
). =20
>>>> Shades of vector<bool> all over again...
>>>>
>>> Well to get an optimized policy, the user would have to specialize it=
=20
>>> with their user-defined policy object. Is that not the right terminolo=
gy?
>>>
>>
>> vector<bool> is a specialization of vector, and has a different interfac=
e=20
>> than vector. That is very different than, say, providing an allocator=
=20
>> (which is basically a policy) to a vector.
>> =20
>>
>>> In any case what I meant to say is that does every possible policy=20
>>> need to meet these criteria?=20
>>>
>>
>> It is in the interface for optional, so either it does or you change the=
=20
>> interface. You get to explore the design space.
>> =20
>>
>>> The disengaged state is smaller than every state of T, in both=20
>>>> homogeneous (optional<T> vs optional<T>) and heterogeneous (optional<T=
> vs=20
>>>> T) comparisons. Do you intend for that to hold, in which case compari=
ng=20
>>>> two engaged optionals now behaves differently than comparing the value=
s=20
>>>> they hold.
>>>>
>>> I'm probably being a little thick. Can you clarify with the following=
=20
>>> implementation of equality where you would see a problem with the=20
>>> implementation?
>>>
>>> bool operator=3D=3D(const optional<T, P1>& lhs, const optional<T, P2>& =
rhs)
>>> {
>>> if (!lhs.is_initialized() ^ rhs.is_initialized()) {
>>> return false;
>>> }
>>>
>>> if (lhs.is_initialized() && rhs.is_initialized()) {
>>> return *lhs =3D=3D *rhs;
>>> }
>>>
>>> return true;
>>> }
>>>
>>>
>> Say you use NaN for your disengaged value.
>>
>> float f =3D std::numeric_limits<float>::quiet_NaN();
>> assert(!(f=3D=3Df));
>> assert(!(optional<float>(f) =3D=3D optional<float>(f))); // fails
>>
> This is actually still true. I'm assuming you meant if you include a=20
> policy where it's folded into the nan:
> assert (!(optional<float, nan_sentinel>(f) =3D=3D optional<float,=20
> nan_sentinel>(f))); // fails because both are disengaged as per the polic=
y
> assert (!(optional<float, nan_sentinel>(f) =3D=3D optional<float>(f))); /=
/=20
> fails because lhs is disengaged.
>
> assert(!(optional<float>(f) =3D=3D f)); // fails
>>
> This still passes. However:
> assert (!(optional<float, nan_seninel>(f) =3D=3D f))) // fails because lh=
s is=20
> disengaged.
>
Oh. I misread this. So actually in the current implementation I=20
prototyped (https://github.com/vlovich/Optional), this would still hold.
The problem is that disengaged is false & so disengaged !=3D "engaged". =20
However, for consistency this should actually be true. I need to fix the=
=20
comparison operators
to understand comparison against a sentinel.
If NaN is a valid value, then you either need to find a different sentinel=
=20
> or realize that an optimized policy won't work for you.
>
> assert(!(f =3D=3D optional<float>(f))); // fails
>>
>> Now, I'm perfectly willing (although others on the committee are not) to=
=20
>> say that non-regular types such as float are insane, and equality=20
>> comparisons aren't a problem for regular types.
>>
>> However, ordered comparisons are different. Using string("Geronimo") as=
=20
>> the disengaged value:
>>
>> string s =3D "Geronimo";
>> string t =3D "Geronim";
>>
>> assert(t < s);
>> assert(optional<string>(t) < optional<string>(s)); // fails
>> assert(optional<string>(t) < s); // fails
>> assert(t < optional<string>(s)); // fails
>>
>> Is that the desired behavior? As part of your proposal, you explore the=
=20
>> design space, pick something, and then LEWG will debate it if they reall=
y=20
>> want the feature.
>>
> Yes it is. The sentinel value is defined to be the disengaged state &=20
> cannot be represented as a valid value. If the above assertions are=20
> unexpected then the policy
> is incorrectly implemented.
> =20
>
>> I have nothing against coming to Kona. I would certainly be interested=
=20
>>> in presenting it but I can also work to get champions too. I haven't e=
ven=20
>>> presented a draft of a proposal so perhaps discussing Kona is a bit=20
>>> premature?
>>> For all I know there are intractable problems that come up when I flush=
=20
>>> it out fully.
>>>
>>
>> My general advice is that people attend a meeting or two before making a=
=20
>> proposal, so that can see what they are in for. Roughly speaking, it's=
=20
>> like defending a dissertation in front of a panel of people who don't=20
>> really care if you graduate. You are the domain expert fielding tough=
=20
>> questions from other (domain and non-domain) experts, as well as from=20
>> people like me.
>>
>> I do realize that it sometimes takes a proposal to get an employer to=20
>> send someone to a meeting, in which case I advise not picking something =
too=20
>> ambitious. IMO, this is a very ambitious proposal. Of course, other=20
>> committee members may feel otherwise and be willing to put in the=20
>> preparatory effort so that it gets a fair chance. We are all volunteers=
=20
>> and speak only for ourselves or those we represent, as no one speaks for=
=20
>> the committee.
>> --=20
>> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> (847) 691-1404
>> =20
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1404_1043452088.1435270728420
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Thursday, June 25, 2015 at 2:54:06 PM UTC-7, vlo...@gmail.com wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Thursday, June =
25, 2015 at 12:59:58 PM UTC-7, Nevin ":-)" Liber wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On 25 =
June 2015 at 14:22, <span dir=3D"ltr"><<a rel=3D"nofollow">vlo...@gmail=
..com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><br><br>On Thursday, June 25=
, 2015 at 11:54:07 AM UTC-7, Nevin ":-)" Liber wrote:<span><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><div dir=3D"ltr"><div><div class=3D"gmail_quote">On 25 June 2015 at 12:58,=
<span dir=3D"ltr"><<a rel=3D"nofollow">vlo...@gmail.com</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div dir=3D"ltr"><div>I=E2=80=99m not as famili=
ar with the issues so I=E2=80=99m probably misunderstanding
your concern. Is it that every custom specialization of optional mus=
t=20
be able to no-throw construct the disengaged state?</div></div></blockquote=
><div><br></div><div>No, but you weren't proposing to specialize optional.&=
nbsp; You were proposing to add a second policy-like template parameter to =
optional. Those are two very different things.</div><div><br></div><d=
iv>If you are specializing it, I really have to question why it has to be s=
pelled o-p-t-i-o-n-a-l, as it really isn't substitutable in generic constru=
cts (which is the main reason to have them spelled the same way). Sha=
des of vector<bool> all over again...</div></div></div></div></blockq=
uote></span><div>Well to get an optimized policy, the user would have to sp=
ecialize it with their user-defined policy object. Is that not the ri=
ght terminology?</div></blockquote><div><br></div><div>vector<bool> i=
s a specialization of vector, and has a different interface than vector.&nb=
sp; That is very different than, say, providing an allocator (which is basi=
cally a policy) to a vector.</div><div> </div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>&n=
bsp; In any case what I meant to say is that does every possible policy nee=
d to meet these criteria? </div></blockquote><div><br></div><div>It is=
in the interface for optional, so either it does or you change the interfa=
ce. You get to explore the design space.</div><div> </div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex"><span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote"><div>The disengaged state is smaller than every state of T, in both=
homogeneous (optional<T> vs optional<T>) and heterogeneous (op=
tional<T> vs T) comparisons. Do you intend for that to hold, in=
which case comparing two engaged optionals now behaves differently than co=
mparing the values they hold.</div></div></div></div></blockquote></span><d=
iv>I'm probably being a little thick. Can you clarify with the follow=
ing implementation of equality where you would see a problem with the imple=
mentation?<br><br><div style=3D"border:1px solid rgb(187,187,187);word-wrap=
:break-word;background-color:rgb(250,250,250)"><code><div><span style=3D"co=
lor:rgb(0,0,136)">bool</span><span style=3D"color:rgb(0,0,0)"> </span><span=
style=3D"color:rgb(0,0,136)">operator</span><span style=3D"color:rgb(102,1=
02,0)">=3D=3D(</span><span style=3D"color:rgb(0,0,136)">const</span><span s=
tyle=3D"color:rgb(0,0,0)"> optional</span><span style=3D"color:rgb(102,102,=
0)"><</span><span style=3D"color:rgb(0,0,0)">T</span><span style=3D"colo=
r:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> P1</span><span =
style=3D"color:rgb(102,102,0)">>&</span><span style=3D"color:rgb(0,0=
,0)"> lhs</span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D=
"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">const</span><=
span style=3D"color:rgb(0,0,0)"> optional</span><span style=3D"color:rgb(10=
2,102,0)"><</span><span style=3D"color:rgb(0,0,0)">T</span><span style=
=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> P2</spa=
n><span style=3D"color:rgb(102,102,0)">>&</span><span style=3D"color=
:rgb(0,0,0)"> rhs</span><span style=3D"color:rgb(102,102,0)">)</span><span =
style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">=
{</span><span style=3D"color:rgb(0,0,0)"><br> </span><span sty=
le=3D"color:rgb(0,0,136)">if</span><span style=3D"color:rgb(0,0,0)"> </span=
><span style=3D"color:rgb(102,102,0)">(!</span><span style=3D"color:rgb(0,0=
,0)">lhs</span><span style=3D"color:rgb(102,102,0)">.</span><span style=3D"=
color:rgb(0,0,0)">is_initialized</span><span style=3D"color:rgb(102,102,0)"=
>()</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb=
(102,102,0)">^</span><span style=3D"color:rgb(0,0,0)"> rhs</span><span styl=
e=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)">is_init=
ialized</span><span style=3D"color:rgb(102,102,0)">())</span><span style=3D=
"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</span><sp=
an style=3D"color:rgb(0,0,0)"><br> </span><span =
style=3D"color:rgb(0,0,136)">return</span><span style=3D"color:rgb(0,0,0)">=
</span><span style=3D"color:rgb(0,0,136)">false</span><span style=3D"color=
:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br> =
</span><span style=3D"color:rgb(102,102,0)">}</span><span style=3D"color:r=
gb(0,0,0)"><br><br> </span><span style=3D"color:rgb(0,0,136)">=
if</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(=
102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">lhs</span><span style=
=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)">is_initi=
alized</span><span style=3D"color:rgb(102,102,0)">()</span><span style=3D"c=
olor:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">&&</s=
pan><span style=3D"color:rgb(0,0,0)"> rhs</span><span style=3D"color:rgb(10=
2,102,0)">.</span><span style=3D"color:rgb(0,0,0)">is_initialized</span><sp=
an style=3D"color:rgb(102,102,0)">())</span><span style=3D"color:rgb(0,0,0)=
"> </span><span style=3D"color:rgb(102,102,0)">{</span><span style=3D"color=
:rgb(0,0,0)"><br> </span><span style=3D"color:rg=
b(0,0,136)">return</span><span style=3D"color:rgb(0,0,0)"> </span><span sty=
le=3D"color:rgb(102,102,0)">*</span><span style=3D"color:rgb(0,0,0)">lhs </=
span><span style=3D"color:rgb(102,102,0)">=3D=3D</span><span style=3D"color=
:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">*</span><span sty=
le=3D"color:rgb(0,0,0)">rhs</span><span style=3D"color:rgb(102,102,0)">;</s=
pan><span style=3D"color:rgb(0,0,0)"><br> </span><span style=
=3D"color:rgb(102,102,0)">}</span><span style=3D"color:rgb(0,0,0)"><br><br>=
</span><span style=3D"color:rgb(0,0,136)">return</span><span =
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">true<=
/span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb=
(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">}</span><span styl=
e=3D"color:rgb(0,0,0)"><br></span></div></code></div><br></div></blockquote=
><div><br></div><div>Say you use NaN for your disengaged value.</div><div><=
br></div><div>float f =3D std::numeric_limits<float>::<wbr>quiet_NaN(=
);<br></div><div>assert(!(f=3D=3Df));</div><div><div>assert(!(optional<f=
loat>(f) =3D=3D optional<float>(f))); // fails</div></div></div></=
div></div></blockquote><div>This is actually still true. I'm assuming=
you meant if you include a policy where it's folded into the nan:<br>asser=
t (!(optional<float, nan_sentinel>(f) =3D=3D optional<float, nan_s=
entinel>(f))); // fails because both are disengaged as per the policy<br=
>assert (!(optional<float, nan_sentinel>(f) =3D=3D optional<float&=
gt;(f))); // fails because lhs is disengaged.<br><br></div><blockquote clas=
s=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"><d=
iv><div><div>assert(!(optional<float>(f) =3D=3D f)); // fails</div></=
div></div></div></div></div></blockquote><div>This still passes. Howe=
ver:<br>assert (!(optional<float, nan_seninel>(f) =3D=3D f))) // fail=
s because lhs is disengaged.<br></div></blockquote><div>Oh. I misread=
this. So actually in the current implementation I prototyped (<a hre=
f=3D"https://github.com/vlovich/Optional" target=3D"_blank" rel=3D"nofollow=
">https://github.com/vlovich/<wbr>Optional</a>), this would still hold.<br>=
The problem is that disengaged is false & so disengaged !=3D "engaged".=
However, for consistency this should actually be true. I need =
to fix the comparison operators<br>to understand comparison against a senti=
nel.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>If NaN =
is a valid value, then you either need to find a different sentinel or real=
ize that an optimized policy won't work for you.<br><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"=
><div><div>assert(!(f =3D=3D optional<float>(f))); // fails</div></di=
v><div><br></div><div>Now, I'm perfectly willing (although others on the co=
mmittee are not) to say that non-regular types such as float are insane, an=
d equality comparisons aren't a problem for regular types.</div><div><br></=
div><div>However, ordered comparisons are different. Using string("Ge=
ronimo") as the disengaged value:</div><div><br></div><div>string s =3D "Ge=
ronimo";</div><div>string t =3D "Geronim";</div><div><br></div><div>assert(=
t < s);</div><div>assert(optional<string>(t) < optional<stri=
ng>(s)); // fails</div><div>assert(optional<string>(t) < s); //=
fails</div><div>assert(t < optional<string>(s)); // fails</div><d=
iv><br></div><div>Is that the desired behavior? As part of your propo=
sal, you explore the design space, pick something, and then LEWG will debat=
e it if they really want the feature.</div></div></div></div></blockquote><=
div>Yes it is. The sentinel value is defined to be the disengaged sta=
te & cannot be represented as a valid value. If the above asserti=
ons are unexpected then the policy<br>is incorrectly implemented.<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"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div>I have nothing against coming=
to Kona. I would certainly be interested in presenting it but I can =
also work to get champions too. I haven't even presented a draft of a=
proposal so perhaps discussing Kona is a bit premature?<br>For all I know =
there are intractable problems that come up when I flush it out fully.<br><=
/div></blockquote><div><br></div><div>My general advice is that people atte=
nd a meeting or two before making a proposal, so that can see what they are=
in for. Roughly speaking, it's like defending a dissertation in fron=
t of a panel of people who don't really care if you graduate. You are=
the domain expert fielding tough questions from other (domain and non-doma=
in) experts, as well as from people like me.</div><div><br></div><div>I do =
realize that it sometimes takes a proposal to get an employer to send someo=
ne to a meeting, in which case I advise not picking something too ambitious=
.. IMO, this is a very ambitious proposal. Of course, other comm=
ittee members may feel otherwise and be willing to put in the preparatory e=
ffort so that it gets a fair chance. We are all volunteers and speak =
only for ourselves or those we represent, as no one speaks for the committe=
e.</div></div>-- <br><div> Nevin ":-)" Liber <mailto:<a rel=
=3D"nofollow">ne...@eviloverlord.com</a><wbr>> (847) 691-1404</div=
>
</div></div>
</blockquote></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1404_1043452088.1435270728420--
------=_Part_1403_1405183621.1435270728420--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 25 Jun 2015 16:20:54 -0700
Raw View
On Wed, Jun 24, 2015 at 6:47 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 24 June 2015 at 17:58, 'Jeffrey Yasskin' via ISO C++ Standard - Future
> Proposals <std-proposals@isocpp.org> wrote:
>>
>> I'd be happy to see a paper fleshing this out. I don't think anyone
>> was opposed to the idea, but it would have slowed down the initial
>> optional<> proposal if it had been included.
>
>
> Ahem. I was strongly against it when it came up on this list two years ago,
> and I'm still strongly against it now. This could be slightly tapered by
> proposing a separate type instead of shoehorning it into optional. If it
> were to be shoehorned into optional, I'd be strongly against optional going
> into C++17, and that would make me sad.
Ah, here are the old threads:
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/cXneqUj-5oo/jszGOPPXK1cJ
and https://groups.google.com/a/isocpp.org/d/msg/std-proposals/WBkQCiKXEZc/nLE4jQGYEfgJ.
> Either way, I believe that it would take a significant amount of committee
> time to discuss. You have to revisit every issue that optional and variant
> touched, including the issues with the empty state of variant, because now
> you may not be able to no throw construct the disengaged state.
It depends on the decisions the paper makes, and how well it justifies
them. Several folks have now suggested ways around the disengaged
constructor throwing, but there are clearly other issues to work
through.
> It isn't fair to encourage someone to write up a paper and fly to Kona if we
> aren't going to spend enough time to give useful feedback. Do you really
> think we'll have that light a load in Kona?
It's worth getting the paper just so there's something concrete to
talk about. We can run it around the LEWG mailing list to see if
there's enough interest to ask someone to come to Kona to present it,
or we can talk it over in Kona without the author present, as long as
someone's enthusiastic enough to explain it to everyone.
--
---
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/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 26 Jun 2015 15:54:08 -0400
Raw View
--001a11348cbe6268740519711a0d
Content-Type: text/plain; charset=UTF-8
On Thu, Jun 25, 2015 at 2:53 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 25 June 2015 at 12:58, <vlovich@gmail.com> wrote:
>
> Are you planning on coming to Kona to present it? If not, my advice is to
> get someone who was involved with the discussions around optional to do a
> deep dive into your proposal and champion it. Jeffrey and Tony are two
> good candidates, if they are going and you can convince them.
>
Nothing beats presenting a paper yourself!
I'm hoping to go, if I can manage funding (click here to donate?:-).
If I go, I'd gladly champion it - whether I agree or not with the
particular proposal, I've spent a lot of time thinking about optional, so I
think I could present it. (And present it fairly. I tend to see all sides
of a discussion, to the point of not being able to decide myself.)
For this proposal in particular:
- it does bother the "old C coder" inside me that sometimes optional won't
be as efficient as it could be if I could tell it what the empty value was
- I don't want to delay optional (at least not for this reason :-)
- I don't think this need delay optional, but every paper does take
committee time, so it does have a cost regardless
--
---
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/.
--001a11348cbe6268740519711a0d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Jun 25, 2015 at 2:53 PM, Nevin Liber <span dir=3D"ltr"><<a h=
ref=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.=
com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On=
25 June 2015 at 12:58, <span dir=3D"ltr"><<a href=3D"mailto:vlovich@gm=
ail.com" target=3D"_blank">vlovich@gmail.com</a>></span> wrote:<br></spa=
n><span class=3D""></span><div></div></div></div></div></blockquote><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><div>Are you planning on coming to K=
ona to present it?=C2=A0 If not, my advice is to get someone who was involv=
ed with the discussions around optional to do a deep dive into your proposa=
l and champion it.=C2=A0 Jeffrey and Tony are two good candidates, if they =
are going and you can convince them.</div><span class=3D""><div></div></spa=
n></div></div></div></blockquote><div><br><br></div></div>Nothing beats pre=
senting a paper yourself!<br></div><div class=3D"gmail_extra">I'm hopin=
g to go, if I can manage funding (click here to donate?:-).<br></div><div c=
lass=3D"gmail_extra">If I go, I'd gladly champion it - whether I agree =
or not with the particular proposal, I've spent a lot of time thinking =
about optional, so I think I could present it.=C2=A0 (And present it fairly=
.. I tend to see all sides of a discussion, to the point of not being able t=
o decide myself.)<br><br></div><div class=3D"gmail_extra">For this proposal=
in particular:<br></div><div class=3D"gmail_extra">- it does bother the &q=
uot;old C coder" inside me that sometimes optional won't be as eff=
icient as it could be if I could tell it what the empty value was<br></div>=
<div class=3D"gmail_extra">- I don't want to delay optional (at least n=
ot for this reason :-)<br></div><div class=3D"gmail_extra">- I don't th=
ink this need delay optional, but every paper does take committee time, so =
it does have a cost regardless<br><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11348cbe6268740519711a0d--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 26 Jun 2015 15:58:27 -0400
Raw View
--089e01176f0bdfa4cd05197129b4
Content-Type: text/plain; charset=UTF-8
>
>
>
> However, ordered comparisons are different. Using string("Geronimo") as
> the disengaged value:
>
> string s = "Geronimo";
> string t = "Geronim";
>
> assert(t < s);
> assert(optional<string>(t) < optional<string>(s)); // fails
> assert(optional<string>(t) < s); // fails
> assert(t < optional<string>(s)); // fails
>
> Is that the desired behavior? As part of your proposal, you explore the
> design space, pick something, and then LEWG will debate it if they really
> want the feature.
>
Yes it is. The sentinel value is defined to be the disengaged state &
> cannot be represented as a valid value. If the above assertions are
> unexpected then the policy
> is incorrectly implemented.
>
A more realistic example might be "<insert name here>".
You just assume no one has that name, and the rest of your code treats it
like it treats other optionals.
Yes that is different behaviour than string, and different behaviour than
the default optional<string>, but it is also a different type, so that's OK.
And I can see the value in it.
Devil may be in the details, however.
--
---
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/.
--089e01176f0bdfa4cd05197129b4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span class=3D""><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"><br><div><br></div><div>H=
owever, ordered comparisons are different.=C2=A0 Using string("Geronim=
o") as the disengaged value:</div><div><br></div><div>string s =3D &qu=
ot;Geronimo";</div><div>string t =3D "Geronim";</div><div><b=
r></div><div>assert(t < s);</div><div>assert(optional<string>(t) &=
lt; optional<string>(s)); // fails</div><div>assert(optional<strin=
g>(t) < s); // fails</div><div>assert(t < optional<string>(s=
)); // fails</div><div><br></div><div>Is that the desired behavior?=C2=A0 A=
s part of your proposal, you explore the design space, pick something, and =
then LEWG will debate it if they really want the feature.</div></div></div>=
</div></blockquote></span><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div>Yes it is.=C2=A0 The sentinel valu=
e is defined to be the disengaged state & cannot be represented as a va=
lid value.=C2=A0 If the above assertions are unexpected then the policy<br>=
is incorrectly implemented. <br></div></blockquote></div><br><br></div><div=
class=3D"gmail_extra">A more realistic example might be "<insert n=
ame here>".<br></div><div class=3D"gmail_extra">You just assume no =
one has that name, and the rest of your code treats it like it treats other=
optionals.<br><br></div><div class=3D"gmail_extra">Yes that is different b=
ehaviour than string, and different behaviour than the default optional<=
string>, but it is also a different type, so that's OK.<br>And I can=
see the value in it.<br><br></div><div class=3D"gmail_extra">Devil may be =
in the details, however.<br></div><div class=3D"gmail_extra"><br></div></di=
v>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01176f0bdfa4cd05197129b4--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 26 Jun 2015 13:14:14 -0700 (PDT)
Raw View
------=_Part_2239_1452474547.1435349655055
Content-Type: multipart/alternative;
boundary="----=_Part_2240_1293095980.1435349655056"
------=_Part_2240_1293095980.1435349655056
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu =C5=9Broda, 24 czerwca 2015 18:55:50 UTC+2 u=C5=BCytkownik vlo...@gm=
ail.com=20
napisa=C5=82:
>
> Hi,
>
> I'd like to bring up this topic again. I know Andrzej brought it up a=20
> couple of years ago for tr2 but I think I have a different take.
> First, I'd like to motivate the discussion with the limitations of the=20
> current approach.
>
> - For small types optional can double the size of storage
> - Overhead can add up when stored in arrays (& most of it due to=20
> padding if the sizeof(T) > 1).
> - Cannot be used as a drop-in in a memory-mapped structure. In these=
=20
> scenarios it's not uncommon to have a sentinel value.
> - Cannot be used in as a drop-in in existing code that uses a sentinel=
=20
> (i.e type-safety)
> - Lots of overhead when a struct contains lots of optionals. For=20
> example, protobuf uses bit-packing for this.
>
> The main limitation, at least as I see it, of the Andrzej's traits=20
> implementation is that it cannot be customized per-instance of optional. =
=20
> This is probably fine for user-defined types but makes this optimization=
=20
> not possible for built-in types. It's not uncommon to have only certain=
=20
> instances of built-in types have invalid bit-patterns (e.g. NaN for doubl=
e,=20
> maximum value for size_t as reported by std::string).
>
>
> To that end, my proposal to accomplish something like this would require=
=20
> adding a secondary template parameter that defines the storage of the=20
> initialization state. Here is a straw-man skeleton example of what the=
=20
> std::optional class interface might look like. constexpr omitted for=20
> simplicity but I don't see anything preventing it & optional_storage is t=
he=20
> hypothetical :
>
>
> template <typename T, typename S =3D default_optional_initialization_stor=
age
> >
> class optional {
> public:
> optional(std::nullopt_t)
> {
> std::get<0>(_data).set_initialized(reinterpret_cast<T*>(&std::get=
<
> 1>(_data)), false);
> }
>
> optional(const T&)
> {
> std::get<0>(_data).set_initialized(reinterpret_cast<T*>(&std::get=
<
> 1>(_data)), true);
> }
> ...
> bool is_initialized() const
> {
> return std::get<0>(_data).is_initialized();
> }
> ...
> private:
> std::tuple<S, aligned_storage_t<sizeof(T)>> _data;
> };
>
> default_optional_initialization_storage would comply with the interface=
=20
> for optional_initialization_storage & look something like:
>
>
> struct default_optional_initialization_storage {
> template <typename T>
> bool is_initialized(T*) const
> {
> return _initialized;
> }
>
> template <typename T>
> void set_initialized(T*, bool initialized)
> {
> _initialized =3D initialized;
> }
>
> bool _initialized =3D false;
> };
>
>
> An example for hiding the state as via NaN for double:
>
> struct nan_optional_storage {
> bool is_initialized(double* value) const
> {
> return !std::isnan(*value)
> }
>
> void set_initialized(double* value, bool initialized)
> {
> if (!initialized) {
> *value =3D std::numeric_limits<double>::quite_NaN();
> }
> }
> };
>
>
> The main criticism of this proposal was that it affects the optional's=20
semantics:
optional<double, nan_optional_storage> od {2.3};
double d =3D compute_val();
assert (od); // contains value
*od =3D d;
assert (od); // contains value?
The second assertion always holds in normal optional. In the "optimized"=20
version, it depends on the value of d.
=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_2240_1293095980.1435349655056
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu =C5=9Broda, 24 czerwca 2015 18:55:50 UTC+2 u=C5=BCytkownik v=
lo...@gmail.com napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">Hi,<br><br>I'd like to bring up this topic again. I k=
now Andrzej brought it up a couple of years ago for tr2 but I think I have =
a different take.<br>First, I'd like to motivate the discussion with the li=
mitations of the current approach.<br><ul><li>For small types optional can =
double the size of storage</li><li>Overhead can add up when stored in array=
s (& most of it due to padding if the sizeof(T) > 1).</li><li>Cannot=
be used as a drop-in in a memory-mapped structure. In these scenario=
s it's not uncommon to have a sentinel value.</li><li>Cannot be used in as =
a drop-in in existing code that uses a sentinel (i.e type-safety)</li><li>L=
ots of overhead when a struct contains lots of optionals. For example=
, protobuf uses bit-packing for this.</li></ul><p>The main limitation, at l=
east as I see it, of the Andrzej's traits implementation is that it cannot =
be customized per-instance of optional. This is probably fine for use=
r-defined types but makes this optimization not possible for built-in types=
.. It's not uncommon to have only certain instances of built-in types =
have invalid bit-patterns (e.g. NaN for double, maximum value for size_t as=
reported by std::string).<br></p><p><br></p><p>To that end, my proposal to=
accomplish something like this would require adding a secondary template p=
arameter that defines the storage of the initialization state. Here i=
s a straw-man skeleton example of what the std::optional class interface mi=
ght look like. constexpr omitted for simplicity but I don't see anything pr=
eventing it & optional_storage is the hypothetical :</p><p><br></p><p><=
/p><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187=
,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div>=
<span style=3D"color:#008">template</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660"><</span><span style=3D"color:#008">typename=
</span><span style=3D"color:#000"> T</span><span style=3D"color:#660">,</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#008">typename</=
span><span style=3D"color:#000"> S </span><span style=3D"color:#660">=3D</s=
pan><span style=3D"color:#000"> default_optional_<wbr>initialization_storag=
e</span><span style=3D"color:#660">></span><span style=3D"color:#000"><b=
r></span><span style=3D"color:#008">class</span><span style=3D"color:#000">=
optional </span><span style=3D"color:#660">{</span><span style=3D"color:#0=
00"><br></span><span style=3D"color:#008">public</span><span style=3D"color=
:#660">:</span><span style=3D"color:#000"><br> optional</span>=
<span style=3D"color:#660">(</span><span style=3D"color:#000">std</span><sp=
an style=3D"color:#660">::</span><span style=3D"color:#000">nullopt_t</span=
><span style=3D"color:#660">)</span><span style=3D"color:#000"><br> &=
nbsp; </span><span style=3D"color:#660">{</span><span style=3D"color:#000">=
<br> std</span><span style=3D"color:#660">::</sp=
an><span style=3D"color:#008">get</span><span style=3D"color:#660"><</sp=
an><span style=3D"color:#066">0</span><span style=3D"color:#660">>(</spa=
n><span style=3D"color:#000">_data</span><span style=3D"color:#660">).</spa=
n><span style=3D"color:#000">set_<wbr>initialized</span><span style=3D"colo=
r:#660">(</span><span><span style=3D"color:#008">reinterpret_cast</span></s=
pan><span><span style=3D"color:#660"><</span></span><span style=3D"color=
:#000">T</span><span><span style=3D"color:#660"><wbr>*</span></span><span><=
span style=3D"color:#660">>(</span></span><span style=3D"color:#000">&am=
p;std</span><span style=3D"color:#660">::</span><span style=3D"color:#008">=
get</span><span style=3D"color:#660"><</span><span style=3D"color:#066">=
1</span><span style=3D"color:#660">>(</span><span style=3D"color:#000">_=
data</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><span style=3D"=
color:#660">}</span><span style=3D"color:#000"><br><br> option=
al</span><span style=3D"color:#660">(</span><span style=3D"color:#008">cons=
t</span><span style=3D"color:#000"> T</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> &n=
bsp; std</span><span style=3D"color:#660">::</span><span style=3D"color:#00=
8">get</span><span style=3D"color:#660"><</span><span style=3D"color:#06=
6">0</span><span style=3D"color:#660">>(</span><span style=3D"color:#000=
">_data</span><span style=3D"color:#660">).</span><span style=3D"color:#000=
">set_<wbr>initialized</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000"><code><span><span style=3D"color:#008">reinterpret_cast</sp=
an></span><span><span style=3D"color:#660"><</span></span><span style=3D=
"color:#000">T</span><span><span style=3D"color:#660"><wbr>*</span></span><=
span><span style=3D"color:#660">>(&</span></span></code>std</span><s=
pan style=3D"color:#660">::</span><span style=3D"color:#008">get</span><spa=
n style=3D"color:#660"><</span><span style=3D"color:#066">1</span><span =
style=3D"color:#660">>(</span><span style=3D"color:#000">_data</span><sp=
an style=3D"color:#660">)),</span><span style=3D"color:#000"> </span><span =
style=3D"color:#008">true</span><span style=3D"color:#660">);</span><span s=
tyle=3D"color:#000"><br> </span><span style=3D"color:#660">}</=
span><span style=3D"color:#000"><br> ...<br> =
</span><span style=3D"color:#008">bool</span><span style=3D"color:#000"> i=
s_initialized</span><span style=3D"color:#660">()</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#008">const</span><span style=3D"color=
:#000"><br> </span><span style=3D"color:#660">{</span><span st=
yle=3D"color:#000"><br> </span><span style=3D"co=
lor:#008">return</span><span style=3D"color:#000"> std</span><span style=3D=
"color:#660">::</span><span style=3D"color:#008">get</span><span style=3D"c=
olor:#660"><</span><span style=3D"color:#066">0</span><span style=3D"col=
or:#660">>(</span><span style=3D"color:#000">_data</span><span style=3D"=
color:#660">).</span><span style=3D"color:#000">is_<wbr>initialized</span><=
span style=3D"color:#660">();</span><span style=3D"color:#000"><br> &=
nbsp; </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><span style=3D"color:#008">private</span><span s=
tyle=3D"color:#660">:</span><span style=3D"color:#000"><br> st=
d</span><span style=3D"color:#660">::</span><span style=3D"color:#000">tupl=
e</span><span style=3D"color:#660"><</span><span style=3D"color:#000">S<=
/span><span style=3D"color:#660">,</span><span style=3D"color:#000"> aligne=
d_storage_t</span><span style=3D"color:#660"><</span><span style=3D"colo=
r:#008">sizeof</span><span style=3D"color:#660">(</span><span style=3D"colo=
r:#000">T</span><span style=3D"color:#660">)>></span><span style=3D"c=
olor:#000"> _data</span><span style=3D"color:#660">;</span><span style=3D"c=
olor:#000"><br></span><span style=3D"color:#660">};</span></div></code></di=
v><br><p></p><p>default_optional_<wbr>initialization_storage would comply w=
ith the interface for optional_initialization_<wbr>storage & look somet=
hing like:<code><span style=3D"color:#000"><br></span></code></p><p><br><co=
de><span style=3D"color:#000"></span></code></p><p><code><span style=3D"col=
or:#000"></span></code></p><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><code><div><span style=3D"color:#008">struct</span><span=
style=3D"color:#000"> default_optional_<wbr>initialization_storage</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span =
style=3D"color:#000"><br> template <typename T><br>=
</span><span style=3D"color:#008">bool</span><span style=3D"c=
olor:#000"> is_initialized</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#660"><code><span style=3D"color:#000"><code><span style=3D"c=
olor:#660"><code><span style=3D"color:#000">T*</span><span style=3D"color:#=
660"></span></code></span></code></span></code>)</span><span style=3D"color=
:#000"> </span><span style=3D"color:#008">const</span><span style=3D"color:=
#000"><br> </span><span style=3D"color:#660">{</span><span sty=
le=3D"color:#000"><br> return _initialized;</spa=
n><span style=3D"color:#000"><br> </span><span style=3D"color:=
#660">}</span><span style=3D"color:#000"><br><br> templat=
e <typename T><br> </span><span style=3D"color:#008">voi=
d</span><span style=3D"color:#000"> set_initialized</span><span style=3D"co=
lor:#660">(</span><span style=3D"color:#660"><code><code><span style=3D"col=
or:#660"></span><span style=3D"color:#660"><code><span style=3D"color:#000"=
><code><span style=3D"color:#660"></span><span style=3D"color:#660"><code><=
span style=3D"color:#000">T*, </span></code></span></code></span></code></s=
pan></code></code></span><span style=3D"color:#660"><code><code><span style=
=3D"color:#660"><code><span style=3D"color:#000"><code><span style=3D"color=
:#660"><code><span style=3D"color:#000"><code><code><span style=3D"color:#0=
00"></span><span style=3D"color:#008">bool</span><span style=3D"color:#000"=
></span></code></code> initialized</span></code></span></code></span></code=
></span></code></code></span><span style=3D"color:#000">)<br> &n=
bsp; {<br> _initialized =3D </spa=
n><span style=3D"color:#000"><code><code><span style=3D"color:#660"><code><=
code><span style=3D"color:#660"><code><span style=3D"color:#000"><code><spa=
n style=3D"color:#660"><code><span style=3D"color:#000">initialized</span><=
/code></span></code></span></code></span></code></code></span><span style=
=3D"color:#000"></span></code></code>;<br> }</span><span =
style=3D"color:#000"><br><br> </span><span style=3D"color=
:#000"><code><code><span style=3D"color:#000"></span><span style=3D"color:#=
008">bool</span><span style=3D"color:#000"></span></code></code> _initializ=
ed =3D false;</span><code><span style=3D"color:#000"><code><span style=3D"c=
olor:#000"><br></span></code></span></code><span style=3D"color:#660">};</s=
pan><span style=3D"color:#000"><br></span></div></code></code></div><span s=
tyle=3D"color:#660"></span><p></p><p><br><code><span style=3D"color:#660"><=
/span></code></p>An example for hiding the state as via NaN for double:<br>=
<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div=
><span style=3D"color:#008">struct</span><span style=3D"color:#000"> nan_op=
tional_storage </span><span style=3D"color:#660">{</span><span style=3D"col=
or:#000"></span><span style=3D"color:#000"><br> </span><span s=
tyle=3D"color:#008">bool</span><span style=3D"color:#000"> is_initialized</=
span><span style=3D"color:#660">(</span><span style=3D"color:#660"><code><c=
ode><span style=3D"color:#660"><code><code><span style=3D"color:#660"><code=
><span style=3D"color:#000"><code><span style=3D"color:#660"><code><span st=
yle=3D"color:#000">double* value</span></code></span></code></span></code><=
/span></code></code></span></code></code>) </span><code><code><span style=
=3D"color:#008">const</span><span style=3D"color:#000"><br> &nbs=
p; {<br> return !std::isnan(*valu=
e)<br> }<br></span></code></code><span style=3D"color:#00=
0"><br> void set_initialized(double* value, bool initiali=
zed)<br> {<br> =
if (!initialized) {<br> &nbs=
p; *value =3D std::numeric_limits<double>::<wbr>quite_NaN=
();<br> }<br> }=
<br></span><span style=3D"color:#660">}</span><span style=3D"color:#000">;<=
br><br></span></div></code></div><code></code><br></div></blockquote><div>T=
he main criticism of this proposal was that it affects the optional's seman=
tics:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250,=
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-w=
idth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">optional</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">doubl=
e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> nan_optional_stor=
age</span><span style=3D"color: #660;" class=3D"styled-by-prettify">></s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> od </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">2.3</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">double</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> d </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> compute_val</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">assert</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">od</span><span styl=
e=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: #800;=
" class=3D"styled-by-prettify">// contains value</span><span style=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: #000;" class=
=3D"styled-by-prettify">od </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> d</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: #008;" class=3D"styled-by-prettify">assert</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">od</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">// contains value?</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><code><span style=3D"=
color:#000"><br><span style=3D"font-family: arial,sans-serif;">The second a=
ssertion always holds in normal optional. In the "optimized" version, it de=
pends on the value of</span> d.<br><br></span></code> </div><div> </di=
v>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2240_1293095980.1435349655056--
------=_Part_2239_1452474547.1435349655055--
.
Author: Christopher Jefferson <chris@bubblescope.net>
Date: Fri, 26 Jun 2015 21:20:00 +0100
Raw View
On 26 June 2015 at 21:14, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wro=
te:
> The main criticism of this proposal was that it affects the optional's
> semantics:
>
> optional<double, nan_optional_storage> od {2.3};
> double d =3D compute_val();
>
> assert (od); // contains value
> *od =3D d;
> assert (od); // contains value?
>
> The second assertion always holds in normal optional. In the "optimized"
> version, it depends on the value of d.
I have used an 'optimised optional' of the type suggested in this
paper for years. At some point I decided to forbid this case -- a user
should be completely unable to tell any space optimisation is being
performed (except the object is smaller obviously). That does mean you
can't compress types such as int or double.
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/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 26 Jun 2015 16:22:05 -0400
Raw View
--001a11c3f5be58f1b10519717e23
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Jun 26, 2015 at 4:20 PM, Christopher Jefferson <
chris@bubblescope.net> wrote:
> On 26 June 2015 at 21:14, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> w=
rote:
>
> > The main criticism of this proposal was that it affects the optional's
> > semantics:
> >
> > optional<double, nan_optional_storage> od {2.3};
> > double d =3D compute_val();
> >
> > assert (od); // contains value
> > *od =3D d;
> > assert (od); // contains value?
> >
> > The second assertion always holds in normal optional. In the "optimized=
"
> > version, it depends on the value of d.
>
> I have used an 'optimised optional' of the type suggested in this
> paper for years. At some point I decided to forbid this case -- a user
> should be completely unable to tell any space optimisation is being
> performed (except the object is smaller obviously). That does mean you
> can't compress types such as int or double.
>
> Chris
>
In what cases *can* you compress then?
--=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/.
--001a11c3f5be58f1b10519717e23
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Jun 26, 2015 at 4:20 PM, Christopher Jefferson <span dir=3D"ltr=
"><<a href=3D"mailto:chris@bubblescope.net" target=3D"_blank">chris@bubb=
lescope.net</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">On 26 June 2015 at 21:14, Andrzej Krzemie=C5=84ski <<a href=3D=
"mailto:akrzemi1@gmail.com">akrzemi1@gmail.com</a>> wrote:<br>
<br>
> The main criticism of this proposal was that it affects the optional&#=
39;s<br>
> semantics:<br>
><br>
> optional<double, nan_optional_storage> od {2.3};<br>
> double d =3D compute_val();<br>
><br>
> assert (od); // contains value<br>
> *od =3D d;<br>
> assert (od); // contains value?<br>
><br>
> The second assertion always holds in normal optional. In the "opt=
imized"<br>
> version, it depends on the value of d.<br>
<br>
</span>I have used an 'optimised optional' of the type suggested in=
this<br>
paper for years. At some point I decided to forbid this case -- a user<br>
should be completely unable to tell any space optimisation is being<br>
performed (except the object is smaller obviously). That does mean you<br>
can't compress types such as int or double.<br>
<br>
Chris<br></blockquote></div><br></div><div class=3D"gmail_extra">In what ca=
ses *can* you compress then?<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c3f5be58f1b10519717e23--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 26 Jun 2015 16:26:54 -0400
Raw View
--089e01493b949648f50519718f1d
Content-Type: text/plain; charset=UTF-8
>
>
> The main criticism of this proposal was that it affects the optional's
> semantics:
>
> optional<double, nan_optional_storage> od {2.3};
> double d = compute_val();
>
> assert (od); // contains value
> *od = d;
> assert (od); // contains value?
>
> The second assertion always holds in normal optional. In the "optimized"
> version, it depends on the value of d.
>
>
I see that as both a criticism and a feature.
Feature:
I suspect it is often the behaviour requested.
ie compute_val() is an old (maybe 3rd party) function documented to return
NaN when there is no valid value.
Now newer code wants to use a more formal optional<>. Either it does
if (is_nan(d))
od = {};
else
od = d;
or it just does
od = d;
and it magically works.
Criticism:
vector<bool>
I'm not sure it rises to the level of vector<bool>, but that is the spectre.
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/.
--089e01493b949648f50519718f1d
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><br><div>The main criticism of this proposal was=
that it affects the optional's semantics:<br><br><div style=3D"backgro=
und-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:#00=
0">optional</span><span style=3D"color:#660"><</span><span style=3D"colo=
r:#008">double</span><span style=3D"color:#660">,</span><span style=3D"colo=
r:#000"> nan_optional_storage</span><span style=3D"color:#660">></span><=
span style=3D"color:#000"> od </span><span style=3D"color:#660">{</span><sp=
an style=3D"color:#066">2.3</span><span style=3D"color:#660">};</span><span=
style=3D"color:#000"><br></span><span style=3D"color:#008">double</span><s=
pan style=3D"color:#000"> d </span><span style=3D"color:#660">=3D</span><sp=
an style=3D"color:#000"> compute_val</span><span style=3D"color:#660">();</=
span><span style=3D"color:#000"><br><br></span><span style=3D"color:#008">a=
ssert</span><span style=3D"color:#000"> </span><span style=3D"color:#660">(=
</span><span style=3D"color:#000">od</span><span style=3D"color:#660">);</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#800">// contai=
ns value</span><span style=3D"color:#000"><br></span><span style=3D"color:#=
660">*</span><span style=3D"color:#000">od </span><span style=3D"color:#660=
">=3D</span><span style=3D"color:#000"> d</span><span style=3D"color:#660">=
;</span><span style=3D"color:#000"><br></span><span style=3D"color:#008">as=
sert</span><span style=3D"color:#000"> </span><span style=3D"color:#660">(<=
/span><span style=3D"color:#000">od</span><span style=3D"color:#660">);</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#800">// contain=
s value?</span><span style=3D"color:#000"><br></span></div></code></div><co=
de><span style=3D"color:#000"><br><span style=3D"font-family:arial,sans-ser=
if">The second assertion always holds in normal optional. In the "opti=
mized" version, it depends on the value of</span> d.<br><br></span></c=
ode> </div><div class=3D"HOEnZb"><div class=3D"h5"><div></div></div></div><=
/blockquote><div><br></div><div>I see that as both a criticism and a featur=
e.<br></div></div><br></div><div class=3D"gmail_extra">Feature:<br>I suspec=
t it is often the behaviour requested.<br>ie compute_val() is an old (maybe=
3rd party) function documented to return NaN when there is no valid value.=
<br></div><div class=3D"gmail_extra">Now newer code wants to use a more for=
mal optional<>.=C2=A0 Either it does<br><br></div><div class=3D"gmail=
_extra">if (is_nan(d))<br></div><div class=3D"gmail_extra">=C2=A0=C2=A0 od =
=3D {};<br></div><div class=3D"gmail_extra">else<br></div><div class=3D"gma=
il_extra">=C2=A0=C2=A0 od =3D d;<br><br></div><div class=3D"gmail_extra">or=
it just does<br><br></div><div class=3D"gmail_extra">od =3D d;<br><br></di=
v><div class=3D"gmail_extra">and it magically works.<br><br></div><div clas=
s=3D"gmail_extra">Criticism:<br></div><div class=3D"gmail_extra">vector<=
bool><br></div><div class=3D"gmail_extra">I'm not sure it rises to t=
he level of vector<bool>, but that is the spectre.<br><br></div><div =
class=3D"gmail_extra">Tony<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01493b949648f50519718f1d--
.
Author: Christopher Jefferson <chris@bubblescope.net>
Date: Fri, 26 Jun 2015 21:49:24 +0100
Raw View
On 26 June 2015 at 21:22, Tony V E <tvaneerd@gmail.com> wrote:
>
>
> On Fri, Jun 26, 2015 at 4:20 PM, Christopher Jefferson
> <chris@bubblescope.net> wrote:
>>
>> On 26 June 2015 at 21:14, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> =
wrote:
>>
>> > The main criticism of this proposal was that it affects the optional's
>> > semantics:
>> >
>> > optional<double, nan_optional_storage> od {2.3};
>> > double d =3D compute_val();
>> >
>> > assert (od); // contains value
>> > *od =3D d;
>> > assert (od); // contains value?
>> >
>> > The second assertion always holds in normal optional. In the "optimize=
d"
>> > version, it depends on the value of d.
>>
>> I have used an 'optimised optional' of the type suggested in this
>> paper for years. At some point I decided to forbid this case -- a user
>> should be completely unable to tell any space optimisation is being
>> performed (except the object is smaller obviously). That does mean you
>> can't compress types such as int or double.
>>
>> Chris
>
>
> In what cases *can* you compress then?
Any type where at least one bit pattern isn't used in a valid object.
Personally, I mainly compress containers (std::vector, std::list,
std::map, etc.).
I know on any system I care about malloc is never going to return
(void*)1, so any object which contains a pointer can assign that value
to a pointer to represent disengaged.
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/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 26 Jun 2015 17:25:45 -0400
Raw View
--047d7bd7648e0ab36705197262d4
Content-Type: text/plain; charset=UTF-8
> >> I have used an 'optimised optional' of the type suggested in this
> >> paper for years. At some point I decided to forbid this case -- a user
> >> should be completely unable to tell any space optimisation is being
> >> performed (except the object is smaller obviously). That does mean you
> >> can't compress types such as int or double.
> >>
> >> Chris
> >
> >
> > In what cases *can* you compress then?
>
> Any type where at least one bit pattern isn't used in a valid object.
>
> Personally, I mainly compress containers (std::vector, std::list,
> std::map, etc.).
>
> I know on any system I care about malloc is never going to return
> (void*)1, so any object which contains a pointer can assign that value
> to a pointer to represent disengaged.
>
> Chris
>
but how do you know that in my usage of optional<void*>, I also use
(void*)1 for special meaning (besides the use inside optional).
ie I can still have:
void * some_function(); // returns (void*)1 in some case
optional<void *> ov = some_function();
assert( ! ov.empty() );
ie you still need to know the problem domain. Same as using NaN or 0 or
whatever.
The user can still "tell" the optimization exists. Or, more likely, trip
over in some rare case.
I think it is valuable to hear that you have experience with a compressed
optional, but I wonder if the eventual answer is that you would abandon it
completely.
And/or although it may be reasonable to assume your code base need not
worry about (void *)1, the standard has a larger codebase to consider.
--
---
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/.
--047d7bd7648e0ab36705197262d4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">
>> I have used an 'optimised optional' of the type suggested =
in this<br>
>> paper for years. At some point I decided to forbid this case -- a =
user<br>
>> should be completely unable to tell any space optimisation is bein=
g<br>
>> performed (except the object is smaller obviously). That does mean=
you<br>
>> can't compress types such as int or double.<br>
>><br>
>> Chris<br>
><br>
><br>
> In what cases *can* you compress then?<br>
<br>
</div></div>Any type where at least one bit pattern isn't used in a val=
id object.<br>
<br>
Personally, I mainly compress containers (std::vector, std::list,<br>
std::map, etc.).<br>
<br>
I know on any system I care about malloc is never going to return<br>
(void*)1, so any object which contains a pointer can assign that value<br>
to a pointer to represent disengaged.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
Chris<br></div></div></blockquote></div><br></div><div class=3D"gmail_extra=
">but how do you know that in my usage of optional<void*>, I also use=
(void*)1 for special meaning (besides the use inside optional).<br></div><=
div class=3D"gmail_extra">ie I can still have:<br><br></div><div class=3D"g=
mail_extra">void * some_function(); // returns (void*)1 in some case<br><br=
></div><div class=3D"gmail_extra">optional<void *> ov =3D some_functi=
on();<br><br></div><div class=3D"gmail_extra">assert( ! ov.empty() );<br><b=
r></div><div class=3D"gmail_extra">ie you still need to know the problem do=
main.=C2=A0 Same as using NaN or 0 or whatever.<br></div><div class=3D"gmai=
l_extra">The user can still "tell" the optimization exists.=C2=A0=
Or, more likely, trip over in some rare case.<br><br></div><div class=3D"g=
mail_extra">I think it is valuable to hear that you have experience with a =
compressed optional, but I wonder if the eventual answer is that you would =
abandon it completely.<br><br></div><div class=3D"gmail_extra">And/or altho=
ugh it may be reasonable to assume your code base need not worry about (voi=
d *)1, the standard has a larger codebase to consider.<br></div><div class=
=3D"gmail_extra"><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bd7648e0ab36705197262d4--
.
Author: Christopher Jefferson <chris@bubblescope.net>
Date: Fri, 26 Jun 2015 23:41:38 +0100
Raw View
--001a113496d0737a2b0519737111
Content-Type: text/plain; charset=UTF-8
On 26 Jun 2015 10:25 pm, "Tony V E" <tvaneerd@gmail.com> wrote:
>
>
>> >> I have used an 'optimised optional' of the type suggested in this
>> >> paper for years. At some point I decided to forbid this case -- a user
>> >> should be completely unable to tell any space optimisation is being
>> >> performed (except the object is smaller obviously). That does mean you
>> >> can't compress types such as int or double.
>> >>
>> >> Chris
>> >
>> >
>> > In what cases *can* you compress then?
>>
>> Any type where at least one bit pattern isn't used in a valid object.
>>
>> Personally, I mainly compress containers (std::vector, std::list,
>> std::map, etc.).
>>
>> I know on any system I care about malloc is never going to return
>> (void*)1, so any object which contains a pointer can assign that value
>> to a pointer to represent disengaged.
>>
>> Chris
>
>
> but how do you know that in my usage of optional<void*>, I also use
(void*)1 for special meaning (besides the use inside optional).
> ie I can still have:
>
> void * some_function(); // returns (void*)1 in some case
>
> optional<void *> ov = some_function();
>
> assert( ! ov.empty() );
>
> ie you still need to know the problem domain. Same as using NaN or 0 or
whatever.
> The user can still "tell" the optimization exists. Or, more likely, trip
over in some rare case.
>
> I think it is valuable to hear that you have experience with a compressed
optional, but I wonder if the eventual answer is that you would abandon it
completely.
>
> And/or although it may be reasonable to assume your code base need not
worry about (void *)1, the standard has a larger codebase to consider.
I certainly wouldn't compress optional<void*> for the reasons you outline,
but within STD::vector, I might know more, such as promises about the
alignment of memory, or knowledge of STD::allocator.
In the case of vector, in GCC there are 3 pointers start, end, capacity
which satisfy start <= end <= capacity. I can therefore easily make a never
occurring state by assigning start > end.
I am going to think more carefully about the nan-compression case given
earlier. I would not put it in the standard, but I can see the benefit of
letting users write it -- if they then assign a nan they are in trouble,
but that is their own fault!
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113496d0737a2b0519737111
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On 26 Jun 2015 10:25 pm, "Tony V E" <<a href=3D"mailto:tvaneer=
d@gmail.com">tvaneerd@gmail.com</a>> wrote:<br>
><br>
><br>
>> >> I have used an 'optimised optional' of the type s=
uggested in this<br>
>> >> paper for years. At some point I decided to forbid this c=
ase -- a user<br>
>> >> should be completely unable to tell any space optimisatio=
n is being<br>
>> >> performed (except the object is smaller obviously). That =
does mean you<br>
>> >> can't compress types such as int or double.<br>
>> >><br>
>> >> Chris<br>
>> ><br>
>> ><br>
>> > In what cases *can* you compress then?<br>
>><br>
>> Any type where at least one bit pattern isn't used in a valid =
object.<br>
>><br>
>> Personally, I mainly compress containers (std::vector, std::list,<=
br>
>> std::map, etc.).<br>
>><br>
>> I know on any system I care about malloc is never going to return<=
br>
>> (void*)1, so any object which contains a pointer can assign that v=
alue<br>
>> to a pointer to represent disengaged.<br>
>><br>
>> Chris<br>
><br>
><br>
> but how do you know that in my usage of optional<void*>, I also =
use (void*)1 for special meaning (besides the use inside optional).<br>
> ie I can still have:<br>
><br>
> void * some_function(); // returns (void*)1 in some case<br>
><br>
> optional<void *> ov =3D some_function();<br>
><br>
> assert( ! ov.empty() );<br>
><br>
> ie you still need to know the problem domain.=C2=A0 Same as using NaN =
or 0 or whatever.<br>
> The user can still "tell" the optimization exists.=C2=A0 Or,=
more likely, trip over in some rare case.<br>
><br>
> I think it is valuable to hear that you have experience with a compres=
sed optional, but I wonder if the eventual answer is that you would abandon=
it completely.<br>
><br>
> And/or although it may be reasonable to assume your code base need not=
worry about (void *)1, the standard has a larger codebase to consider.</p>
<p dir=3D"ltr">I certainly wouldn't compress optional<void*> for =
the reasons you outline, but within STD::vector, I might know more, such as=
promises about the alignment of memory, or knowledge of STD::allocator.</p=
>
<p dir=3D"ltr">In the case of vector, in GCC there are 3 pointers start, en=
d, capacity which satisfy start <=3D end <=3D capacity. I can therefo=
re easily make a never occurring state by assigning start > end.</p>
<p dir=3D"ltr">I am going to think more carefully about the nan-compression=
case given earlier. I would not put it in the standard, but I can see the =
benefit of letting users write it -- if they then assign a nan they are in =
trouble, but that is their own fault!</p>
<p dir=3D"ltr">> -- <br>
><br>
> --- <br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113496d0737a2b0519737111--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 27 Jun 2015 11:27:13 +0800
Raw View
--Apple-Mail=_7403ABAA-F00B-4BB6-88D8-477BEE461418
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9327, at 4:22 AM, Tony V E <tvaneerd@gmail.com> =
wrote:
>=20
> On Fri, Jun 26, 2015 at 4:20 PM, Christopher Jefferson <chris@bubblescope=
..net <mailto:chris@bubblescope.net>> wrote:
> I have used an 'optimised optional' of the type suggested in this
> paper for years. At some point I decided to forbid this case -- a user
> should be completely unable to tell any space optimisation is being
> performed (except the object is smaller obviously). That does mean you
> can't compress types such as int or double.
>=20
> Chris
>=20
> In what cases *can* you compress then?
Any time the underlying type has unused states that can be inspected after =
destruction. For example, enumerations and standard-layout classes with con=
structors. The underlying type needs to cooperate.
Bit-patterns are tricky. Here=E2=80=99s an approach that might be valid =E2=
=80=94 discuss:
struct small_fsm {
char state;
small_fsm() : state( 0 ) {}
};
void invalidate_representation( small_fsm * invalid_ptr )
{ * reinterpret_cast< char * >( invalid_ptr ) =3D 42; } // not a member=
access!
bool is_valid_representation( small_fsm const * questionable_ptr )
{ return * reinterpret_cast< char const * >( questionable_ptr ) !=3D 42=
; }
I used a small_fsm * parameter instead of void * here so the mechanism can =
accommodate enumeration types. Using a member function would exclude enumer=
ations and using a void * would prevent overloading non-member functions. (=
Enumerations don=E2=80=99t have constructors, but value-initialization soun=
ds good enough.)
Anyway, the functions operating on potentially unconstructed objects can=E2=
=80=99t use member accesses and need to leverage the shaky POD lifetime rul=
es.
The optimization is useful, but any proposal would need to set it on a good=
foundation. numeric_limits::quiet_NaN is not a good foundation. Some NaN c=
ould perhaps be, but only if the platform reserves it specifically to use b=
y std::optional. This isn=E2=80=99t something the user can do.
Besides object lifetime issues, please, don=E2=80=99t let ever let speciali=
zations behave differently from the primary template. I=E2=80=99m not clear=
how that issue crept in, but this extension should be completely within th=
e as-if rule, except for inspection of some traits class or ADL function. A=
nd adding a traits template parameter needs really good justification. Why =
shouldn=E2=80=99t the payload be encapsulated instead? (E.g., use std::opti=
onal< never_quiet_nan< double > >. The payload is not a complete double. St=
rong typedefs might come in handy here.)
On a related note, implementations should already be free to compress optio=
nal< polymorphic_class_type >, by nulling the vtable pointer. The user can=
=E2=80=99t do this, but the implementation can and probably should. Likewis=
e for std::vector=E2=80=A6 there=E2=80=99s plenty of room inside the as-if =
rule for this optimization. The extension should only be about helping the =
user to work within the as-if rule too.
But, bear in mind that you=E2=80=99re already allowed to specialize std::op=
tional for your own types, according to [namespace.std] =C2=A717.6.4.2.1. T=
he niche could very well be filled by a third-party base class, say boost::=
basic_optional, containing ADL function calls like the above. Such a utilit=
y could well be more usable than one designed to fit within standard librar=
y conventions.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_7403ABAA-F00B-4BB6-88D8-477BEE461418
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9327, at 4:22 AM, Tony V E <<a href=3D"mailto:tvaneerd@gmail.com"=
class=3D"">tvaneerd@gmail.com</a>> wrote:</div><div class=3D""><div dir=
=3D"ltr" class=3D""><br class=3D""><div class=3D"gmail_extra"><div class=3D=
"gmail_quote">On Fri, Jun 26, 2015 at 4:20 PM, Christopher Jefferson <span =
dir=3D"ltr" class=3D""><<a href=3D"mailto:chris@bubblescope.net" target=
=3D"_blank" class=3D"">chris@bubblescope.net</a>></span> wrote:<br class=
=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">I have used an 'optimised optional' of=
the type suggested in this<br class=3D"">
paper for years. At some point I decided to forbid this case -- a user<br c=
lass=3D"">
should be completely unable to tell any space optimisation is being<br clas=
s=3D"">
performed (except the object is smaller obviously). That does mean you<br c=
lass=3D"">
can't compress types such as int or double.<br class=3D"">
<br class=3D"">
Chris<br class=3D""></blockquote></div><br class=3D""></div><div class=3D"g=
mail_extra">In what cases *can* you compress then?<br class=3D""></div></di=
v></div></blockquote><br class=3D""></div><div>Any time the underlying type=
has unused states that can be inspected after destruction. For example, en=
umerations and standard-layout classes with constructors. The underlying ty=
pe needs to cooperate.</div><div><br class=3D""></div><div>Bit-patterns are=
tricky. Here=E2=80=99s an approach that might be valid =E2=80=94 discuss:<=
/div><div><br class=3D""></div><div><font face=3D"Courier" class=3D"">struc=
t small_fsm {</font></div><div><font face=3D"Courier" class=3D""> &nb=
sp; char state;</font></div><div><font face=3D"Courier" class=3D""><br clas=
s=3D""></font></div><div><font face=3D"Courier" class=3D""> &nb=
sp;</font><span style=3D"font-family: Courier;" class=3D"">small_fsm</span>=
<font face=3D"Courier" class=3D"">() : </font><span style=3D"font-fami=
ly: Courier;" class=3D"">state</span><font face=3D"Courier" class=3D"">( 0 =
) {}</font></div><div><span style=3D"font-family: Courier;" class=3D"">};</=
span></div><div><br class=3D""></div><div><div><font face=3D"Courier" class=
=3D"">void invalidate_representation( </font><span style=3D"font-famil=
y: Courier;" class=3D"">small_fsm</span><font face=3D"Courier" class=3D"">&=
nbsp;* invalid_ptr )</font></div><div><font face=3D"Courier" class=3D"">&nb=
sp; { * reinterpret_cast< char * >( </font><span style=3D=
"font-family: Courier;" class=3D"">invalid_ptr</span><font face=3D"Courier"=
class=3D""> ) =3D 42; } // not a member access!</font></div><div clas=
s=3D""><div><font face=3D"Courier" class=3D""><br class=3D""></font></div><=
div><font face=3D"Courier" class=3D"">bool is_valid_representation( </=
font><span style=3D"font-family: Courier;" class=3D"">small_fsm</span><font=
face=3D"Courier" class=3D""> const * questionable_ptr )</font></div><=
div><font face=3D"Courier" class=3D""> { return * reinterpret_=
cast< char const * >( </font><span style=3D"font-family: Courier=
;" class=3D"">questionable_ptr</span><font face=3D"Courier" class=3D"">&nbs=
p;) !=3D 42; }</font></div></div><div class=3D""><font face=3D"Courier" cla=
ss=3D""><br class=3D""></font></div></div><div>I used a <span style=3D=
"font-family: Courier;" class=3D"">small_fsm</span><font face=3D"Courier" c=
lass=3D""> *</font> parameter instead of <font face=3D"Courier" c=
lass=3D"">void *</font> here so the mechanism can accommodate enumeration t=
ypes. Using a member function would exclude enumerations and using a <=
span style=3D"font-family: Courier;" class=3D"">void *</span> would pr=
event overloading non-member functions. (Enumerations don=E2=80=99t have co=
nstructors, but value-initialization sounds good enough.)</div><div><br cla=
ss=3D""></div><div>Anyway, the functions operating on potentially unconstru=
cted objects can=E2=80=99t use member accesses and need to leverage the sha=
ky POD lifetime rules.</div><div><br class=3D""></div><div>The optimization=
is useful, but any proposal would need to set it on a good foundation. <fo=
nt face=3D"Courier" class=3D"">numeric_limits::quiet_NaN</font> is not a go=
od foundation. Some NaN could perhaps be, but only if the platform reserves=
it specifically to use by <font face=3D"Courier" class=3D"">std::optional<=
/font>. This isn=E2=80=99t something the user can do.</div><div><br class=
=3D""></div><div>Besides object lifetime issues, please, don=E2=80=99t let =
ever let specializations behave differently from the primary template. I=E2=
=80=99m not clear how that issue crept in, but this extension should be com=
pletely within the as-if rule, except for inspection of some traits class o=
r ADL function. And adding a traits template parameter needs really good ju=
stification. Why shouldn=E2=80=99t the payload be encapsulated instead? (E.=
g., use <font face=3D"Courier" class=3D"">std::optional< never_quiet_nan=
< double > ></font>. The payload is not a complete <font face=3D"C=
ourier" class=3D"">double</font>. Strong typedefs might come in handy here.=
)</div><div><br class=3D""></div><div><div>On a related note, implementatio=
ns should already be free to compress <font face=3D"Courier" class=3D"">opt=
ional< polymorphic_class_type ></font>, by nulling the vtable pointer=
.. The user can=E2=80=99t do this, but the implementation can and probably s=
hould. Likewise for <font face=3D"Courier" class=3D"">std::vector</font>=E2=
=80=A6 there=E2=80=99s plenty of room inside the as-if rule for this optimi=
zation. The extension should only be about helping the user to work within =
the as-if rule too.</div><div><br class=3D""></div><div>But, bear in mind t=
hat you=E2=80=99re already allowed to specialize <font face=3D"Courier" cla=
ss=3D"">std::optional</font> for your own types, according to [namespace.st=
d] =C2=A717.6.4.2.1. The niche could very well be filled by a third-party b=
ase class, say <font face=3D"Courier" class=3D"">boost::basic_optional</fon=
t>, containing ADL function calls like the above. Such a utility could well=
be more usable than one designed to fit within standard library convention=
s.</div><div class=3D""><br class=3D""></div></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_7403ABAA-F00B-4BB6-88D8-477BEE461418--
.
Author: vlovich@gmail.com
Date: Sat, 27 Jun 2015 12:47:38 -0700 (PDT)
Raw View
------=_Part_3830_507803265.1435434458862
Content-Type: multipart/alternative;
boundary="----=_Part_3831_549461677.1435434458862"
------=_Part_3831_549461677.1435434458862
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hey David, I really like the idea of a basic_optional a lot better & can=20
provide a better foundation for doing something like compressing the=20
optional state for many optionals into a bit-field (e.g. protobuf) which is=
=20
one the problems left unsolved.
I also like the idea of encapsulating the sentinel'ness as you propose=20
(e.g. std::optional<never_quiet_nan<double>>) instead of having a separate=
=20
traits. Can you elaborate a bit on how this could be accomplished? Right=
=20
now optional has a boolean
field. My original design moved that boolean field into the policy/traits=
=20
& used the empty base-class optimization to get rid of it when=20
unnecessary. In the std::optional<never_quiet_nan<double>> example, would=
=20
never_quiet_nan have a static constexpr member
boolean that said "I understand how to read/write my state from the=20
value"? Or would there be an ADL traits class that parametrized this?
The std::vector & polymorphism cases I think are less compelling for as-if=
=20
as I can't imagine a use-case where you would store either in optional. =20
std::vector has a natural empty state & using optional<vector<X>> seems=20
more likely to be a poor design
than anything else. Polymorphic classes tend to be prone to slicing when=
=20
used as a value-type. optional for enum classes (enums too?) would be=20
possible if there were reflection so that you could query for an=20
out-of-range value to use as a sentinel.
As you say, an implementation would be free to optimize these if it felt=20
important under the as-if rule so there would be no need to specify it in=
=20
the proposal.
I was hoping to get to writing up the proposal this weekend but it looks=20
like probably it will end up next weekend. If you have any more thoughts=
=20
on the matter feel free to email me directly.
On Friday, June 26, 2015 at 8:27:25 PM UTC-7, David Krauss wrote:
>
>
> On 2015=E2=80=9306=E2=80=9327, at 4:22 AM, Tony V E <tvan...@gmail.com <j=
avascript:>>=20
> wrote:
>
> On Fri, Jun 26, 2015 at 4:20 PM, Christopher Jefferson <
> ch...@bubblescope.net <javascript:>> wrote:
>
>> I have used an 'optimised optional' of the type suggested in this
>> paper for years. At some point I decided to forbid this case -- a user
>> should be completely unable to tell any space optimisation is being
>> performed (except the object is smaller obviously). That does mean you
>> can't compress types such as int or double.
>>
>> Chris
>>
>
> In what cases *can* you compress then?
>
>
> Any time the underlying type has unused states that can be inspected afte=
r=20
> destruction. For example, enumerations and standard-layout classes with=
=20
> constructors. The underlying type needs to cooperate.
>
> Bit-patterns are tricky. Here=E2=80=99s an approach that might be valid =
=E2=80=94 discuss:
>
> struct small_fsm {
> char state;
>
> small_fsm() : state( 0 ) {}
> };
>
> void invalidate_representation( small_fsm * invalid_ptr )
> { * reinterpret_cast< char * >( invalid_ptr ) =3D 42; } // not a memb=
er=20
> access!
>
> bool is_valid_representation( small_fsm const * questionable_ptr )
> { return * reinterpret_cast< char const * >( questionable_ptr ) !=3D=
=20
> 42; }
>
> I used a small_fsm * parameter instead of void * here so the mechanism=20
> can accommodate enumeration types. Using a member function would exclude=
=20
> enumerations and using a void * would prevent overloading non-member=20
> functions. (Enumerations don=E2=80=99t have constructors, but value-initi=
alization=20
> sounds good enough.)
>
> Anyway, the functions operating on potentially unconstructed objects can=
=E2=80=99t=20
> use member accesses and need to leverage the shaky POD lifetime rules.
>
> The optimization is useful, but any proposal would need to set it on a=20
> good foundation. numeric_limits::quiet_NaN is not a good foundation. Some=
=20
> NaN could perhaps be, but only if the platform reserves it specifically t=
o=20
> use by std::optional. This isn=E2=80=99t something the user can do.
>
> Besides object lifetime issues, please, don=E2=80=99t let ever let specia=
lizations=20
> behave differently from the primary template. I=E2=80=99m not clear how t=
hat issue=20
> crept in, but this extension should be completely within the as-if rule,=
=20
> except for inspection of some traits class or ADL function. And adding a=
=20
> traits template parameter needs really good justification. Why shouldn=E2=
=80=99t=20
> the payload be encapsulated instead? (E.g., use std::optional<=20
> never_quiet_nan< double > >. The payload is not a complete double. Strong=
=20
> typedefs might come in handy here.)
>
> On a related note, implementations should already be free to compress opt=
ional<=20
> polymorphic_class_type >, by nulling the vtable pointer. The user can=E2=
=80=99t=20
> do this, but the implementation can and probably should. Likewise for=20
> std::vector=E2=80=A6 there=E2=80=99s plenty of room inside the as-if rule=
for this=20
> optimization. The extension should only be about helping the user to work=
=20
> within the as-if rule too.
>
> But, bear in mind that you=E2=80=99re already allowed to specialize std::=
optional=20
> for your own types, according to [namespace.std] =C2=A717.6.4.2.1. The ni=
che=20
> could very well be filled by a third-party base class, say=20
> boost::basic_optional, containing ADL function calls like the above. Such=
=20
> a utility could well be more usable than one designed to fit within=20
> standard library conventions.
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_3831_549461677.1435434458862
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hey David, I really like the idea of a basic_optional a lo=
t better & can provide a better foundation for doing something like com=
pressing the optional state for many optionals into a bit-field (e.g. proto=
buf) which is one the problems left unsolved.<br>I also like the idea of en=
capsulating the sentinel'ness as you propose (e.g. std::optional<never_q=
uiet_nan<double>>) instead of having a separate traits. Can =
you elaborate a bit on how this could be accomplished? Right now opti=
onal has a boolean<br>field. My original design moved that boolean fi=
eld into the policy/traits & used the empty base-class optimization to =
get rid of it when unnecessary. In the std::optional<never_quiet_n=
an<double>> example, would never_quiet_nan have a static constexpr=
member<br>boolean that said "I understand how to read/write my state from =
the value"? Or would there be an ADL traits class that parametrized t=
his?<br><br>The std::vector & polymorphism cases I think are less compe=
lling for as-if as I can't imagine a use-case where you would store either =
in optional. std::vector has a natural empty state & using option=
al<vector<X>> seems more likely to be a poor design<br>than any=
thing else. Polymorphic classes tend to be prone to slicing when used=
as a value-type. optional for enum classes (enums too?) would be pos=
sible if there were reflection so that you could query for an out-of-range =
value to use as a sentinel.<br>As you say, an implementation would be free =
to optimize these if it felt important under the as-if rule so there would =
be no need to specify it in the proposal.<br><br>I was hoping to get to wri=
ting up the proposal this weekend but it looks like probably it will end up=
next weekend. If you have any more thoughts on the matter feel free =
to email me directly.<br><br>On Friday, June 26, 2015 at 8:27:25 PM UTC-7, =
David Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=
=3D"word-wrap:break-word"><br><div><blockquote type=3D"cite"><div>On 2015=
=E2=80=9306=E2=80=9327, at 4:22 AM, Tony V E <<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"qJiy76RM73AJ" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">tvan...@gmail.com</a>> wrote:</div><div><div=
dir=3D"ltr"><br><div><div class=3D"gmail_quote">On Fri, Jun 26, 2015 at 4:=
20 PM, Christopher Jefferson <span dir=3D"ltr"><<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"qJiy76RM73AJ" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">ch...@bubblescope.net</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">I have used an 'optimised optional' of th=
e type suggested in this<br>
paper for years. At some point I decided to forbid this case -- a user<br>
should be completely unable to tell any space optimisation is being<br>
performed (except the object is smaller obviously). That does mean you<br>
can't compress types such as int or double.<br>
<br>
Chris<br></blockquote></div><br></div><div>In what cases *can* you compress=
then?<br></div></div></div></blockquote><br></div><div>Any time the underl=
ying type has unused states that can be inspected after destruction. For ex=
ample, enumerations and standard-layout classes with constructors. The unde=
rlying type needs to cooperate.</div><div><br></div><div>Bit-patterns are t=
ricky. Here=E2=80=99s an approach that might be valid =E2=80=94 discuss:</d=
iv><div><br></div><div><font face=3D"Courier">struct small_fsm {</font></di=
v><div><font face=3D"Courier"> char state;</font></div><div><f=
ont face=3D"Courier"><br></font></div><div><font face=3D"Courier"> &n=
bsp; </font><span style=3D"font-family:Courier">small_fsm</span><font =
face=3D"Courier">() : </font><span style=3D"font-family:Courier">state=
</span><font face=3D"Courier">( 0 ) {}</font></div><div><span style=3D"font=
-family:Courier">};</span></div><div><br></div><div><div><font face=3D"Cour=
ier">void invalidate_representation( </font><span style=3D"font-family=
:Courier">sma<wbr>ll_fsm</span><font face=3D"Courier"> * invalid_ptr )=
</font></div><div><font face=3D"Courier"> { * reinterpret_cast=
< char * >( </font><span style=3D"font-family:Courier">invalid_p=
tr</span><font face=3D"Courier"> ) =3D 42; } // not a member access!</=
font></div><div><div><font face=3D"Courier"><br></font></div><div><font fac=
e=3D"Courier">bool is_valid_representation( </font><span style=3D"font=
-family:Courier">small<wbr>_fsm</span><font face=3D"Courier"> const * =
questionable_ptr )</font></div><div><font face=3D"Courier"> { =
return * reinterpret_cast< char const * >( </font><span style=3D=
"font-family:Courier">questionable_ptr</span><font face=3D"Courier"> )=
!=3D 42; }</font></div></div><div><font face=3D"Courier"><br></font></div>=
</div><div>I used a <span style=3D"font-family:Courier">small_fsm</spa=
n><font face=3D"Courier"> *</font> parameter instead of <font fac=
e=3D"Courier">void *</font> here so the mechanism can accommodate enumerati=
on types. Using a member function would exclude enumerations and using a&nb=
sp;<span style=3D"font-family:Courier">void *</span> would prevent ove=
rloading non-member functions. (Enumerations don=E2=80=99t have constructor=
s, but value-initialization sounds good enough.)</div><div><br></div><div>A=
nyway, the functions operating on potentially unconstructed objects can=E2=
=80=99t use member accesses and need to leverage the shaky POD lifetime rul=
es.</div><div><br></div><div>The optimization is useful, but any proposal w=
ould need to set it on a good foundation. <font face=3D"Courier">numeric_li=
mits::quiet_NaN</font> is not a good foundation. Some NaN could perhaps be,=
but only if the platform reserves it specifically to use by <font face=3D"=
Courier">std::optional</font>. This isn=E2=80=99t something the user can do=
..</div><div><br></div><div>Besides object lifetime issues, please, don=E2=
=80=99t let ever let specializations behave differently from the primary te=
mplate. I=E2=80=99m not clear how that issue crept in, but this extension s=
hould be completely within the as-if rule, except for inspection of some tr=
aits class or ADL function. And adding a traits template parameter needs re=
ally good justification. Why shouldn=E2=80=99t the payload be encapsulated =
instead? (E.g., use <font face=3D"Courier">std::optional< never_quiet_na=
n< double > ></font>. The payload is not a complete <font face=3D"=
Courier">double</font>. Strong typedefs might come in handy here.)</div><di=
v><br></div><div><div>On a related note, implementations should already be =
free to compress <font face=3D"Courier">optional< polymorphic_class_type=
></font>, by nulling the vtable pointer. The user can=E2=80=99t do this=
, but the implementation can and probably should. Likewise for <font face=
=3D"Courier">std::vector</font>=E2=80=A6 there=E2=80=99s plenty of room ins=
ide the as-if rule for this optimization. The extension should only be abou=
t helping the user to work within the as-if rule too.</div><div><br></div><=
div>But, bear in mind that you=E2=80=99re already allowed to specialize <fo=
nt face=3D"Courier">std::optional</font> for your own types, according to [=
namespace.std] =C2=A717.6.4.2.1. The niche could very well be filled by a t=
hird-party base class, say <font face=3D"Courier">boost::basic_optional</fo=
nt>, containing ADL function calls like the above. Such a utility could wel=
l be more usable than one designed to fit within standard library conventio=
ns.</div><div><br></div></div></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3831_549461677.1435434458862--
------=_Part_3830_507803265.1435434458862--
.
Author: David Krauss <potswa@mac.com>
Date: Sun, 28 Jun 2015 22:38:48 +0800
Raw View
--Apple-Mail=_FF0C88BD-155B-4F8E-88ED-69612CC6E9BB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9328, at 3:47 AM, vlovich@gmail.com wrote:
>=20
> Hey David, I really like the idea of a basic_optional a lot better & can =
provide a better foundation for doing something like compressing the option=
al state for many optionals into a bit-field (e.g. protobuf) which is one t=
he problems left unsolved.
> I also like the idea of encapsulating the sentinel'ness as you propose (e=
..g. std::optional<never_quiet_nan<double>>) instead of having a separate tr=
aits. Can you elaborate a bit on how this could be accomplished? Right no=
w optional has a boolean
> field. My original design moved that boolean field into the policy/trait=
s & used the empty base-class optimization to get rid of it when unnecessar=
y. In the std::optional<never_quiet_nan<double>> example, would never_quie=
t_nan have a static constexpr member
> boolean that said "I understand how to read/write my state from the value=
"? Or would there be an ADL traits class that parametrized this?
I=E2=80=99m thinking like this:
// Thin wrapper:
template< typename float_t >
struct never_quiet_nan {
float_t value =3D 0;
operator float_t & () { return value; }
operator float_t const & () const { return value; }
};
// ADL object representation functions:
template< typename float_t >
void invalidate_representation( never_quiet_nan< float_t > * invalid_ptr )
{ * reinterpret_cast< float_t * >( invalid_ptr ) =3D std::numeric_limit=
s< float_t >::quiet_NaN; }
template< typename float_t >
bool is_valid_representation( never_quiet_nan< float_t > const * questionab=
le_ptr )
{ return std::isnan( * reinterpret_cast< float_t const * >( questionabl=
e_ptr ) ); }
> The std::vector & polymorphism cases I think are less compelling for as-i=
f as I can't imagine a use-case where you would store either in optional. =
std::vector has a natural empty state & using optional<vector<X>> seems mor=
e likely to be a poor design
> than anything else.=20
One use-case of std::optional is for output parameters. Those are already a=
n anti-pattern per se, but still I think a blanket statement that optional<=
vector> should never happen is too strong.
Under as-if, it=E2=80=99s a question of how many priorities a standard libr=
ary can implement before they need to freeze their ABI.
> Polymorphic classes tend to be prone to slicing when used as a value-type=
.. optional for enum classes (enums too?) would be possible if there were r=
eflection so that you could query for an out-of-range value to use as a sen=
tinel.
Just ask the user for invalidate_representation and is_valid_representation=
.. Enumerations aren=E2=80=99t closed so reflection can=E2=80=99t really dis=
cover invalid values.
> As you say, an implementation would be free to optimize these if it felt =
important under the as-if rule so there would be no need to specify it in t=
he proposal.
>=20
> I was hoping to get to writing up the proposal this weekend but it looks =
like probably it will end up next weekend. If you have any more thoughts o=
n the matter feel free to email me directly.
My hands are full=E2=80=A6 I=E2=80=99m procrastinating here already :P .
Good luck!
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_FF0C88BD-155B-4F8E-88ED-69612CC6E9BB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9328, at 3:47 AM, <a href=3D"mailto:vlovich@gmail.com" class=3D"">vl=
ovich@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><di=
v class=3D""><div dir=3D"ltr" style=3D"font-family: Helvetica; font-size: 1=
2px; font-style: normal; font-variant: normal; font-weight: normal; letter-=
spacing: normal; line-height: normal; orphans: auto; text-align: start; tex=
t-indent: 0px; text-transform: none; white-space: normal; widows: auto; wor=
d-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">Hey David, I re=
ally like the idea of a basic_optional a lot better & can provide a bet=
ter foundation for doing something like compressing the optional state for =
many optionals into a bit-field (e.g. protobuf) which is one the problems l=
eft unsolved.<br class=3D"">I also like the idea of encapsulating the senti=
nel'ness as you propose (e.g. std::optional<never_quiet_nan<double>=
;>) instead of having a separate traits. Can you elaborate a bit o=
n how this could be accomplished? Right now optional has a boolean<br=
class=3D"">field. My original design moved that boolean field into t=
he policy/traits & used the empty base-class optimization to get rid of=
it when unnecessary. In the std::optional<never_quiet_nan<doub=
le>> example, would never_quiet_nan have a static constexpr member<br=
class=3D"">boolean that said "I understand how to read/write my state from=
the value"? Or would there be an ADL traits class that parametrized =
this?<br class=3D""></div></div></blockquote><div><br class=3D""></div><div=
>I=E2=80=99m thinking like this:</div><div><br class=3D""></div><div><font =
face=3D"Courier" class=3D"">// Thin wrapper:</font></div><div><font face=3D=
"Courier" class=3D""><br class=3D""></font></div><div><span style=3D"font-f=
amily: Courier;" class=3D"">template< typename float_t ></span></div>=
<div><font face=3D"Courier" class=3D"">struct never_quiet_nan {</font></div=
><div><font face=3D"Courier" class=3D""> float_t value =3D 0;<=
/font></div><div><font face=3D"Courier" class=3D""><br class=3D""></font></=
div><div><font face=3D"Courier" class=3D""> operator float_t &=
amp; () { return value; }</font></div><font face=3D"Courier" class=3D"">&nb=
sp; operator float_t const & () const { return value; }</font></=
div><div class=3D""><font face=3D"Courier" class=3D"">};</font></div><div c=
lass=3D""><font face=3D"Courier" class=3D""><br class=3D""></font></div><di=
v class=3D""><font face=3D"Courier" class=3D"">// ADL object representation=
functions:</font></div><div class=3D""><font face=3D"Courier" class=3D""><=
br class=3D""></font></div><div><font face=3D"Courier" class=3D"">template&=
lt; typename float_t ></font></div><div class=3D""><font face=3D"Courier=
" class=3D"">void invalidate_representation( </font><span style=3D"fon=
t-family: Courier;" class=3D"">never_quiet_nan< float_t ></span><font=
face=3D"Courier" class=3D""> * invalid_ptr )<br class=3D""> &nb=
sp; { * reinterpret_cast< </font><span style=3D"font-family: Courie=
r;" class=3D"">float_t</span><font face=3D"Courier" class=3D""> * >=
( invalid_ptr ) =3D std::numeric_limits< float_t >::quiet_N=
aN; }<br class=3D""><br class=3D""></font><div><font face=3D"Courier" class=
=3D"">template< typename float_t ></font></div><font face=3D"Courier"=
class=3D"">bool is_valid_representation( </font><span style=3D"font-f=
amily: Courier;" class=3D"">never_quiet_nan< float_t ></span><font fa=
ce=3D"Courier" class=3D""> const * questionable_ptr )<br class=3D"">&n=
bsp; { return std::isnan( * reinterpret_cast< </font><span s=
tyle=3D"font-family: Courier;" class=3D"">float_t</span><font face=3D"Couri=
er" class=3D""> const * >( questionable_ptr ) ); }<br cla=
ss=3D""></font><br class=3D""><blockquote type=3D"cite" class=3D""><div cla=
ss=3D""><div dir=3D"ltr" style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; letter-spaci=
ng: normal; line-height: normal; orphans: auto; text-align: start; text-ind=
ent: 0px; text-transform: none; white-space: normal; widows: auto; word-spa=
cing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">The std::vector &=
; polymorphism cases I think are less compelling for as-if as I can't imagi=
ne a use-case where you would store either in optional. std::vector h=
as a natural empty state & using optional<vector<X>> seems =
more likely to be a poor design<br class=3D"">than anything else. </d=
iv></div></blockquote><div class=3D""><br class=3D""></div><div class=3D"">=
One use-case of <font face=3D"Courier" class=3D"">std::optional</font> is f=
or output parameters. Those are already an anti-pattern per se, but still I=
think a blanket statement that <font face=3D"Courier" class=3D"">optional&=
lt;vector></font> should never happen is too strong.</div><div class=3D"=
"><br class=3D""></div><div class=3D"">Under as-if, it=E2=80=99s a question=
of how many priorities a standard library can implement before they need t=
o freeze their ABI.</div><br class=3D""><blockquote type=3D"cite" class=3D"=
"><div class=3D""><div dir=3D"ltr" style=3D"font-family: Helvetica; font-si=
ze: 12px; font-style: normal; font-variant: normal; font-weight: normal; le=
tter-spacing: normal; line-height: normal; orphans: auto; text-align: start=
; text-indent: 0px; text-transform: none; white-space: normal; widows: auto=
; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">Polymorphi=
c classes tend to be prone to slicing when used as a value-type. opti=
onal for enum classes (enums too?) would be possible if there were reflecti=
on so that you could query for an out-of-range value to use as a sentinel.<=
br class=3D""></div></div></blockquote><div class=3D""><br class=3D""></div=
><div class=3D"">Just ask the user for <font face=3D"Courier" class=3D"">in=
validate_representation</font> and <font face=3D"Courier" class=3D"">is_val=
id_representation</font>. Enumerations aren=E2=80=99t closed so reflection =
can=E2=80=99t really discover invalid values.</div><br class=3D""><blockquo=
te type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" style=3D"font-=
family: Helvetica; font-size: 12px; font-style: normal; font-variant: norma=
l; font-weight: normal; letter-spacing: normal; line-height: normal; orphan=
s: auto; text-align: start; text-indent: 0px; text-transform: none; white-s=
pace: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0=
px;" class=3D"">As you say, an implementation would be free to optimize the=
se if it felt important under the as-if rule so there would be no need to s=
pecify it in the proposal.<br class=3D""><br class=3D"">I was hoping to get=
to writing up the proposal this weekend but it looks like probably it will=
end up next weekend. If you have any more thoughts on the matter fee=
l free to email me directly.<br class=3D""></div></div></blockquote></div><=
br class=3D""><div class=3D"">My hands are full=E2=80=A6 I=E2=80=99m procra=
stinating here already :P .</div><div class=3D""><br class=3D""></div><div =
class=3D"">Good luck!</div><div class=3D""><br class=3D""></div></body></ht=
ml>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_FF0C88BD-155B-4F8E-88ED-69612CC6E9BB--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 28 Jun 2015 17:49:48 +0200
Raw View
Le 26/06/15 22:14, Andrzej Krzemie=C5=84ski a =C3=A9crit :
>
> W dniu =C5=9Broda, 24 czerwca 2015 18:55:50 UTC+2 u=C5=BCytkownik vlo...@=
gmail.com
> napisa=C5=82:
>> Hi,
>>
>> I'd like to bring up this topic again. I know Andrzej brought it up a
>> couple of years ago for tr2 but I think I have a different take.
>> First, I'd like to motivate the discussion with the limitations of the
>> current approach.
>>
>> - For small types optional can double the size of storage
>> - Overhead can add up when stored in arrays (& most of it due to
>> padding if the sizeof(T) > 1).
>> - Cannot be used as a drop-in in a memory-mapped structure. In thes=
e
>> scenarios it's not uncommon to have a sentinel value.
>> - Cannot be used in as a drop-in in existing code that uses a sentin=
el
>> (i.e type-safety)
>> - Lots of overhead when a struct contains lots of optionals. For
>> example, protobuf uses bit-packing for this.
>>
>> The main limitation, at least as I see it, of the Andrzej's traits
>> implementation is that it cannot be customized per-instance of optional.
>> This is probably fine for user-defined types but makes this optimization
>> not possible for built-in types. It's not uncommon to have only certain
>> instances of built-in types have invalid bit-patterns (e.g. NaN for doub=
le,
>> maximum value for size_t as reported by std::string).
>>
>>
>> To that end, my proposal to accomplish something like this would require
>> adding a secondary template parameter that defines the storage of the
>> initialization state. Here is a straw-man skeleton example of what the
>> std::optional class interface might look like. constexpr omitted for
>> simplicity but I don't see anything preventing it & optional_storage is =
the
>> hypothetical :
>>
>>
>> template <typename T, typename S =3D default_optional_initialization_sto=
rage
>> class optional {
>> public:
>> optional(std::nullopt_t)
>> {
>> std::get<0>(_data).set_initialized(reinterpret_cast<T*>(&std::g=
et<
>> 1>(_data)), false);
>> }
>>
>> optional(const T&)
>> {
>> std::get<0>(_data).set_initialized(reinterpret_cast<T*>(&std::g=
et<
>> 1>(_data)), true);
>> }
>> ...
>> bool is_initialized() const
>> {
>> return std::get<0>(_data).is_initialized();
>> }
>> ...
>> private:
>> std::tuple<S, aligned_storage_t<sizeof(T)>> _data;
>> };
>>
>> default_optional_initialization_storage would comply with the interface
>> for optional_initialization_storage & look something like:
>>
>>
>> struct default_optional_initialization_storage {
>> template <typename T>
>> bool is_initialized(T*) const
>> {
>> return _initialized;
>> }
>>
>> template <typename T>
>> void set_initialized(T*, bool initialized)
>> {
>> _initialized =3D initialized;
>> }
>>
>> bool _initialized =3D false;
>> };
>>
>>
>> An example for hiding the state as via NaN for double:
>>
>> struct nan_optional_storage {
>> bool is_initialized(double* value) const
>> {
>> return !std::isnan(*value)
>> }
>>
>> void set_initialized(double* value, bool initialized)
>> {
>> if (!initialized) {
>> *value =3D std::numeric_limits<double>::quite_NaN();
>> }
>> }
>> };
>>
>>
>> The main criticism of this proposal was that it affects the optional's
> semantics:
>
> optional<double, nan_optional_storage> od {2.3};
> double d =3D compute_val();
>
> assert (od); // contains value
> *od =3D d;
> assert (od); // contains value?
>
> The second assertion always holds in normal optional. In the "optimized"
> version, it depends on the value of d.
>
> =20
>
Andrzej is right
*od =3D d;
is odd and can only be caught if operator* returns a proxy :( This proxy=20
could check for the value and throw an exception.
Clearly this is another possibly null type, with different space and=20
time constraints.
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 28 Jun 2015 23:55:23 +0800
Raw View
--Apple-Mail=_9C392A6C-E71C-44B8-8B37-CDADD5E5226B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
This discussion should already be steered clear of that problem. Perhaps re=
ply to a newer post?
> On 2015=E2=80=9306=E2=80=9328, at 11:49 PM, Vicente J. Botet Escriba <vic=
ente.botet@wanadoo.fr> wrote:
>=20
> Andrzej is right
>=20
> *od =3D d;
>=20
>=20
> is odd and can only be caught if operator* returns a proxy :( This proxy =
could check for the value and throw an exception.
>=20
>=20
> Clearly this is another possibly null type, with different space and time=
constraints.
>=20
> 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/.
--Apple-Mail=_9C392A6C-E71C-44B8-8B37-CDADD5E5226B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D"">This discussion sh=
ould already be steered clear of that problem. Perhaps reply to a newer pos=
t?<div class=3D""><br class=3D""><div class=3D""><br class=3D""><div><block=
quote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=E2=80=932=
8, at 11:49 PM, Vicente J. Botet Escriba <<a href=3D"mailto:vicente.bote=
t@wanadoo.fr" class=3D"">vicente.botet@wanadoo.fr</a>> wrote:</div><br c=
lass=3D"Apple-interchange-newline"><div class=3D""><span style=3D"font-fami=
ly: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; line-height: normal; orphans: a=
uto; text-align: start; text-indent: 0px; text-transform: none; white-space=
: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
float: none; display: inline !important;" class=3D"">Andrzej is right</span=
><br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; line-hei=
ght: normal; orphans: auto; text-align: start; text-indent: 0px; text-trans=
form: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-t=
ext-stroke-width: 0px;" class=3D""><br style=3D"font-family: Helvetica; fon=
t-size: 12px; font-style: normal; font-variant: normal; font-weight: normal=
; letter-spacing: normal; line-height: normal; orphans: auto; text-align: s=
tart; text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-=
variant: normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; text-transform:=
none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-s=
troke-width: 0px; float: none; display: inline !important;" class=3D"">*od =
=3D d;</span><br style=3D"font-family: Helvetica; font-size: 12px; font-sty=
le: normal; font-variant: normal; font-weight: normal; letter-spacing: norm=
al; line-height: normal; orphans: auto; text-align: start; text-indent: 0px=
; text-transform: none; white-space: normal; widows: auto; word-spacing: 0p=
x; -webkit-text-stroke-width: 0px;" class=3D""><br style=3D"font-family: He=
lvetica; font-size: 12px; font-style: normal; font-variant: normal; font-we=
ight: normal; letter-spacing: normal; line-height: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=
=3D""><br style=3D"font-family: Helvetica; font-size: 12px; font-style: nor=
mal; font-variant: normal; font-weight: normal; letter-spacing: normal; lin=
e-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-=
transform: none; white-space: normal; widows: auto; word-spacing: 0px; -web=
kit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helveti=
ca; font-size: 12px; font-style: normal; font-variant: normal; font-weight:=
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-a=
lign: start; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none=
; display: inline !important;" class=3D"">is odd and can only be caught if =
operator* returns a proxy :( This proxy could check for the value and throw=
an exception.</span><br style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; letter-spaci=
ng: normal; line-height: normal; orphans: auto; text-align: start; text-ind=
ent: 0px; text-transform: none; white-space: normal; widows: auto; word-spa=
cing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
;" class=3D""><br style=3D"font-family: Helvetica; font-size: 12px; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: nor=
mal; line-height: normal; orphans: auto; text-align: start; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: auto; word-spacing: 0=
px; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family:=
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font=
-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto=
; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; flo=
at: none; display: inline !important;" class=3D"">Clearly this is another p=
ossibly null type, with different space and time constraints.</span><br sty=
le=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-var=
iant: normal; font-weight: normal; letter-spacing: normal; line-height: nor=
mal; orphans: auto; text-align: start; text-indent: 0px; text-transform: no=
ne; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stro=
ke-width: 0px;" class=3D""><br style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D=
"font-family: Helvetica; font-size: 12px; font-style: normal; font-variant:=
normal; font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: none; w=
hite-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-wi=
dth: 0px; float: none; display: inline !important;" class=3D"">Vicente</spa=
n><br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal;=
font-variant: normal; font-weight: normal; letter-spacing: normal; line-he=
ight: normal; orphans: auto; text-align: start; text-indent: 0px; text-tran=
sform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-=
text-stroke-width: 0px;" class=3D""></div></blockquote></div><br class=3D""=
></div></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_9C392A6C-E71C-44B8-8B37-CDADD5E5226B--
.
Author: Vitali Lovich <vlovich@gmail.com>
Date: Sun, 28 Jun 2015 09:19:51 -0700
Raw View
--Apple-Mail-1951A2E4-13C5-493F-9A54-81594CA59B73
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> On Jun 28, 2015, at 7:38 AM, David Krauss <potswa@mac.com> wrote:
>=20
>=20
>> On 2015=E2=80=9306=E2=80=9328, at 3:47 AM, vlovich@gmail.com wrote:
>>=20
>> Hey David, I really like the idea of a basic_optional a lot better & can=
provide a better foundation for doing something like compressing the optio=
nal state for many optionals into a bit-field (e.g. protobuf) which is one =
the problems left unsolved.
>> I also like the idea of encapsulating the sentinel'ness as you propose (=
e.g. std::optional<never_quiet_nan<double>>) instead of having a separate t=
raits. Can you elaborate a bit on how this could be accomplished? Right n=
ow optional has a boolean
>> field. My original design moved that boolean field into the policy/trai=
ts & used the empty base-class optimization to get rid of it when unnecessa=
ry. In the std::optional<never_quiet_nan<double>> example, would never_qui=
et_nan have a static constexpr member
>> boolean that said "I understand how to read/write my state from the valu=
e"? Or would there be an ADL traits class that parametrized this?
>=20
> I=E2=80=99m thinking like this:
>=20
> // Thin wrapper:
>=20
> template< typename float_t >
> struct never_quiet_nan {
> float_t value =3D 0;
>=20
> operator float_t & () { return value; }
> operator float_t const & () const { return value; }
> };
>=20
> // ADL object representation functions:
>=20
> template< typename float_t >
> void invalidate_representation( never_quiet_nan< float_t > * invalid_ptr =
)
> { * reinterpret_cast< float_t * >( invalid_ptr ) =3D std::numeric_lim=
its< float_t >::quiet_NaN; }
>=20
> template< typename float_t >
> bool is_valid_representation( never_quiet_nan< float_t > const * question=
able_ptr )
> { return std::isnan( * reinterpret_cast< float_t const * >( questiona=
ble_ptr ) ); }
Hmmm... And how would optional decide what state it needs to store?
>> The std::vector & polymorphism cases I think are less compelling for as-=
if as I can't imagine a use-case where you would store either in optional. =
std::vector has a natural empty state & using optional<vector<X>> seems mo=
re likely to be a poor design
>> than anything else.=20
>=20
> One use-case of std::optional is for output parameters. Those are already=
an anti-pattern per se, but still I think a blanket statement that optiona=
l<vector> should never happen is too strong.
>=20
> Under as-if, it=E2=80=99s a question of how many priorities a standard li=
brary can implement before they need to freeze their ABI.
>=20
>> Polymorphic classes tend to be prone to slicing when used as a value-typ=
e. optional for enum classes (enums too?) would be possible if there were =
reflection so that you could query for an out-of-range value to use as a se=
ntinel.
>=20
> Just ask the user for invalidate_representation and is_valid_representati=
on. Enumerations aren=E2=80=99t closed so reflection can=E2=80=99t really d=
iscover invalid values.
>=20
>> As you say, an implementation would be free to optimize these if it felt=
important under the as-if rule so there would be no need to specify it in =
the proposal.
>>=20
>> I was hoping to get to writing up the proposal this weekend but it looks=
like probably it will end up next weekend. If you have any more thoughts =
on the matter feel free to email me directly.
>=20
> My hands are full=E2=80=A6 I=E2=80=99m procrastinating here already :P .
>=20
> Good luck!
>=20
> --=20
>=20
> ---=20
> You received this message because you are subscribed to a topic in the Go=
ogle Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.=
org/d/topic/std-proposals/46J1onhWJ-s/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to std-p=
roposals+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-propo=
sals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail-1951A2E4-13C5-493F-9A54-81594CA59B73
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div></div><div><br></div><div><br>On J=
un 28, 2015, at 7:38 AM, David Krauss <<a href=3D"mailto:potswa@mac.com"=
>potswa@mac.com</a>> wrote:<br><br></div><blockquote type=3D"cite"><div>=
<meta http-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf-8"><br=
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On 20=
15=E2=80=9306=E2=80=9328, at 3:47 AM, <a href=3D"mailto:vlovich@gmail.com" =
class=3D"">vlovich@gmail.com</a> wrote:</div><br class=3D"Apple-interchange=
-newline"><div class=3D""><div dir=3D"ltr" style=3D"font-family: Helvetica;=
font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">He=
y David, I really like the idea of a basic_optional a lot better & can =
provide a better foundation for doing something like compressing the option=
al state for many optionals into a bit-field (e.g. protobuf) which is one t=
he problems left unsolved.<br class=3D"">I also like the idea of encapsulat=
ing the sentinel'ness as you propose (e.g. std::optional<never_quiet_nan=
<double>>) instead of having a separate traits. Can you elab=
orate a bit on how this could be accomplished? Right now optional has=
a boolean<br class=3D"">field. My original design moved that boolean=
field into the policy/traits & used the empty base-class optimization =
to get rid of it when unnecessary. In the std::optional<never_quie=
t_nan<double>> example, would never_quiet_nan have a static conste=
xpr member<br class=3D"">boolean that said "I understand how to read/write =
my state from the value"? Or would there be an ADL traits class that =
parametrized this?<br class=3D""></div></div></blockquote><div><br class=3D=
""></div><div>I=E2=80=99m thinking like this:</div><div><br class=3D""></di=
v><div><font face=3D"Courier" class=3D"">// Thin wrapper:</font></div><div>=
<font face=3D"Courier" class=3D""><br class=3D""></font></div><div><span st=
yle=3D"font-family: Courier;" class=3D"">template< typename float_t >=
</span></div><div><font face=3D"Courier" class=3D"">struct never_quiet_nan =
{</font></div><div><font face=3D"Courier" class=3D""> float_t =
value =3D 0;</font></div><div><font face=3D"Courier" class=3D""><br class=
=3D""></font></div><div><font face=3D"Courier" class=3D""> ope=
rator float_t & () { return value; }</font></div><font face=3D"Courier"=
class=3D""> operator float_t const & () const { return va=
lue; }</font></div><div class=3D""><font face=3D"Courier" class=3D"">};</fo=
nt></div><div class=3D""><font face=3D"Courier" class=3D""><br class=3D""><=
/font></div><div class=3D""><font face=3D"Courier" class=3D"">// ADL object=
representation functions:</font></div><div class=3D""><font face=3D"Courie=
r" class=3D""><br class=3D""></font></div><div><font face=3D"Courier" class=
=3D"">template< typename float_t ></font></div><div class=3D""><font =
face=3D"Courier" class=3D"">void invalidate_representation( </font><sp=
an style=3D"font-family: Courier;" class=3D"">never_quiet_nan< float_t &=
gt;</span><font face=3D"Courier" class=3D""> * invalid_ptr )<br class=
=3D""> { * reinterpret_cast< </font><span style=3D"fon=
t-family: Courier;" class=3D"">float_t</span><font face=3D"Courier" class=
=3D""> * >( invalid_ptr ) =3D std::numeric_limits< flo=
at_t >::quiet_NaN; }<br class=3D""><br class=3D""></font><div><font face=
=3D"Courier" class=3D"">template< typename float_t ></font></div><fon=
t face=3D"Courier" class=3D"">bool is_valid_representation( </font><sp=
an style=3D"font-family: Courier;" class=3D"">never_quiet_nan< float_t &=
gt;</span><font face=3D"Courier" class=3D""> const * questionable_ptr =
)<br class=3D""> { return std::isnan( * reinterpret_cast<&n=
bsp;</font><span style=3D"font-family: Courier;" class=3D"">float_t</span><=
font face=3D"Courier" class=3D""> const * >( questionable_ptr&=
nbsp;) ); }</font><br class=3D""></div></div></blockquote>Hmmm... And how w=
ould optional decide what state it needs to store?<div><br><blockquote type=
=3D"cite"><div><div class=3D""><blockquote type=3D"cite" class=3D""><div cl=
ass=3D""><div dir=3D"ltr" style=3D"font-family: Helvetica; font-size: 12px;=
font-style: normal; font-variant: normal; font-weight: normal; letter-spac=
ing: normal; line-height: normal; orphans: auto; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: auto; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">The std::vector &am=
p; polymorphism cases I think are less compelling for as-if as I can't imag=
ine a use-case where you would store either in optional. std::vector =
has a natural empty state & using optional<vector<X>> seems=
more likely to be a poor design<br class=3D"">than anything else. </=
div></div></blockquote><div class=3D""><br class=3D""></div><div class=3D""=
>One use-case of <font face=3D"Courier" class=3D"">std::optional</font> is =
for output parameters. Those are already an anti-pattern per se, but still =
I think a blanket statement that <font face=3D"Courier" class=3D"">optional=
<vector></font> should never happen is too strong.</div><div class=3D=
""><br class=3D""></div><div class=3D"">Under as-if, it=E2=80=99s a questio=
n of how many priorities a standard library can implement before they need =
to freeze their ABI.</div><br class=3D""><blockquote type=3D"cite" class=3D=
""><div class=3D""><div dir=3D"ltr" style=3D"font-family: Helvetica; font-s=
ize: 12px; font-style: normal; font-variant: normal; font-weight: normal; l=
etter-spacing: normal; line-height: normal; orphans: auto; text-align: star=
t; text-indent: 0px; text-transform: none; white-space: normal; widows: aut=
o; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">Polymorph=
ic classes tend to be prone to slicing when used as a value-type. opt=
ional for enum classes (enums too?) would be possible if there were reflect=
ion so that you could query for an out-of-range value to use as a sentinel.=
<br class=3D""></div></div></blockquote><div class=3D""><br class=3D""></di=
v><div class=3D"">Just ask the user for <font face=3D"Courier" class=3D"">i=
nvalidate_representation</font> and <font face=3D"Courier" class=3D"">is_va=
lid_representation</font>. Enumerations aren=E2=80=99t closed so reflection=
can=E2=80=99t really discover invalid values.</div><br class=3D""><blockqu=
ote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" style=3D"font=
-family: Helvetica; font-size: 12px; font-style: normal; font-variant: norm=
al; font-weight: normal; letter-spacing: normal; line-height: normal; orpha=
ns: auto; text-align: start; text-indent: 0px; text-transform: none; white-=
space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;" class=3D"">As you say, an implementation would be free to optimize th=
ese if it felt important under the as-if rule so there would be no need to =
specify it in the proposal.<br class=3D""><br class=3D"">I was hoping to ge=
t to writing up the proposal this weekend but it looks like probably it wil=
l end up next weekend. If you have any more thoughts on the matter fe=
el free to email me directly.<br class=3D""></div></div></blockquote></div>=
<br class=3D""><div class=3D"">My hands are full=E2=80=A6 I=E2=80=99m procr=
astinating here already :P .</div><div class=3D""><br class=3D""></div><div=
class=3D"">Good luck!</div><div class=3D""><br class=3D""></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/46J1onhWJ-s/unsubscribe">https://groups.=
google.com/a/isocpp.org/d/topic/std-proposals/46J1onhWJ-s/unsubscribe</a>.<=
br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@=
isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br>
</div></blockquote></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail-1951A2E4-13C5-493F-9A54-81594CA59B73--
.
Author: David Krauss <potswa@mac.com>
Date: Mon, 29 Jun 2015 00:22:33 +0800
Raw View
--Apple-Mail=_77B7ABA9-3924-4B46-B3C4-4D48D3BCAD48
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9329, at 12:19 AM, Vitali Lovich <vlovich@gmail.=
com> wrote:
>=20
> Hmmm... And how would optional decide what state it needs to store?
Initialize the disengaged state with invalidate_representation. Construct t=
he object to engage. Query engagement with is_valid_representation.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_77B7ABA9-3924-4B46-B3C4-4D48D3BCAD48
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9329, at 12:19 AM, Vitali Lovich <<a href=3D"mailto:vlovich@gmail=
..com" class=3D"">vlovich@gmail.com</a>> wrote:</div><br class=3D"Apple-i=
nterchange-newline"><div class=3D""><span style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: nor=
mal; letter-spacing: normal; line-height: normal; orphans: auto; text-align=
: start; text-indent: 0px; text-transform: none; white-space: normal; widow=
s: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; di=
splay: inline !important;" class=3D"">Hmmm... And how would optional decide=
what state it needs to store?</span><br class=3D"Apple-interchange-newline=
"></div></blockquote></div><br class=3D""><div class=3D"">Initialize the di=
sengaged state with <font face=3D"Courier" class=3D"">invalidate_representa=
tion</font>. Construct the object to engage. Query engagement with <fo=
nt face=3D"Courier" class=3D"">is_valid_representation</font>.</div><div cl=
ass=3D""><br class=3D""></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_77B7ABA9-3924-4B46-B3C4-4D48D3BCAD48--
.