------=_Part_7013_211394815.1513612287580
Content-Type: multipart/alternative;
 boundary="----=_Part_7014_1230538305.1513612287580"

------=_Part_7014_1230538305.1513612287580
Content-Type: text/plain; charset="UTF-8"

I have written the draft of a proposal for a universally unique identifier
(uuid) library. The draft is available here:
https://github.com/mariusbancila/stduuid/blob/master/paper.md.

I have also written an implementation of the proposed library, that is
available on Github here: https://github.com/mariusbancila/stduuid.

I did not submit this proposal yet. I am looking for feedback first, both
on the library design and the proposal document itself (I know is not the
best possible, but it's my first attempt).

*Note*: Although the proposal specifies that the library should be provided
as part of a new namespace called *std::uuids*, the implementation on
Github uses the namespace *uuids* so that it can actually be used as it is
today.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6fe22d73-3f3a-4096-ac3e-9e6a5d1ec6ba%40isocpp.org.

------=_Part_7014_1230538305.1513612287580
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I have written the draft of a proposal for a=C2=A0universa=
lly unique identifier (uuid) library. The draft is available here:=C2=A0<a =
href=3D"https://github.com/mariusbancila/stduuid/blob/master/paper.md">http=
s://github.com/mariusbancila/stduuid/blob/master/paper.md</a>.<div><br></di=
v><div>I have also written an implementation of the proposed library, that =
is available on Github here:=C2=A0<a href=3D"https://github.com/mariusbanci=
la/stduuid">https://github.com/mariusbancila/stduuid</a>.</div><div><br></d=
iv><div>I did not submit this proposal yet. I am looking for feedback first=
, both on the library design and the proposal document itself (I know is no=
t the best possible, but it&#39;s my=C2=A0first attempt).</div><div><br></d=
iv><div><i>Note</i>: Although the proposal specifies that the library shoul=
d be provided as part of a new namespace called <i>std::uuids</i>, the impl=
ementation on Github uses the namespace <i>uuids</i> so that it can actuall=
y be used as it is today.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6fe22d73-3f3a-4096-ac3e-9e6a5d1ec6ba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6fe22d73-3f3a-4096-ac3e-9e6a5d1ec6ba=
%40isocpp.org</a>.<br />

------=_Part_7014_1230538305.1513612287580--

------=_Part_7013_211394815.1513612287580--

.

--001a114089d6aa1f2305609f80f8
Content-Type: text/plain; charset="UTF-8"

Hi Marius,

I'm not an expert on proposals, nor on uuid's so I'm not sure I'm qualified
to judge here, but, looking at the proposal, this came to my mind:

1) you have an implementation, great!  On what compilers was it tested?
2) is there a way to use it without dynamic memory allocation?

ps. minor typo "to and *frmo* strings,"

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADtNNhgzm%2Bk5NWuB73E5uer254X%3DBE0Q9%2BYqKYxAOjQ0R7ZgUA%40mail.gmail.com.

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

<div dir=3D"ltr">Hi Marius,<div><br></div><div>I&#39;m not an expert on pro=
posals, nor on uuid&#39;s so I&#39;m not sure I&#39;m qualified to judge he=
re, but, looking at the proposal, this came to my mind:</div><div><br></div=
><div>1) you have an implementation, great!=C2=A0 On what compilers was it =
tested?</div><div>2) is there a way to use it without dynamic memory alloca=
tion?=C2=A0</div><div><span style=3D"font-size:12.8px"><br></span></div><di=
v><span style=3D"font-size:12.8px">ps. minor typo &quot;</span><span style=
=3D"color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,&quot;=
Segoe UI&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&qu=
ot;Segoe UI Emoji&quot;,&quot;Segoe UI Symbol&quot;;font-size:16px">to and =
<b>frmo</b> strings,&quot;</span></div><div><br></div><div class=3D"gmail_e=
xtra">
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADtNNhgzm%2Bk5NWuB73E5uer254X%3DBE0Q=
9%2BYqKYxAOjQ0R7ZgUA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADtNNhgzm%=
2Bk5NWuB73E5uer254X%3DBE0Q9%2BYqKYxAOjQ0R7ZgUA%40mail.gmail.com</a>.<br />

--001a114089d6aa1f2305609f80f8--

.

------=_Part_7039_1621216289.1513614380997
Content-Type: multipart/alternative;
 boundary="----=_Part_7040_419474076.1513614380997"

------=_Part_7040_419474076.1513614380997
Content-Type: text/plain; charset="UTF-8"

Didn't we agree that nested namespaces in std should be abolished? I can't
find the paper proposing it, and I don't know whether it was accepted or
not, but I completely agree. Having to write `std::uuids::make_uuid()` is a
bit repetitive. No need for a nested namespace IMO.

The library proposed on this paper is a lite one
>
Did you mean "light" instead of "lite"?

For the sake of consistency, I propose you name the two string conversion
functions `to_string` and template it like std::bitset::to_string did. The
constructor of uuid for the two string types should also be templated.

Shouldn't you be using std::byte instead of std::uint8_t?

If you add iterator support, I think it would be nice to also allow
construction from a pair of iterators.

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

------=_Part_7040_419474076.1513614380997
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Didn&#39;t we agree that nested namespaces in std should b=
e abolished? I can&#39;t find the paper proposing it, and I don&#39;t know =
whether it was accepted or not, but I completely agree. Having to write `st=
d::uuids::make_uuid()` is a bit repetitive. No need for a nested namespace =
IMO.<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;=
">The library proposed on this paper is a lite one<br></blockquote><div>Did=
 you mean &quot;light&quot; instead of &quot;lite&quot;?</div><div><br></di=
v><div>For the sake of consistency, I propose you name the two string conve=
rsion functions `to_string` and template it like std::bitset::to_string did=
.. The constructor of uuid for the two string types should also be templated=
..</div><div>=C2=A0</div><div>Shouldn&#39;t you be using std::byte instead o=
f std::uint8_t?</div><div><br></div><div>If you add iterator support, I thi=
nk it would be nice to also allow construction from a pair of iterators.</d=
iv></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fd675def-9047-4f01-a461-a3c390b3ae68%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fd675def-9047-4f01-a461-a3c390b3ae68=
%40isocpp.org</a>.<br />

------=_Part_7040_419474076.1513614380997--

------=_Part_7039_1621216289.1513614380997--

.

On 12/18/17 18:51, Marius Bancila wrote:
> I have written the draft of a proposal for a=C2=A0universally unique=20
> identifier (uuid) library. The draft is available here:=20
> https://github.com/mariusbancila/stduuid/blob/master/paper.md.
>=20
> I have also written an implementation of the proposed library, that is=20
> available on Github here: https://github.com/mariusbancila/stduuid.
>=20
> I did not submit this proposal yet. I am looking for feedback first,=20
> both on the library design and the proposal document itself (I know is=20
> not the best possible, but it's my=C2=A0first attempt).
>=20
> /Note/: Although the proposal specifies that the library should be=20
> provided as part of a new namespace called /std::uuids/, the=20
> implementation on Github uses the namespace /uuids/ so that it can=20
> actually be used as it is today.

I've been thinking about writing a proposal for std::uuid myself one=20
day, so I'm glad someone did this sooner. :)

I have a few comments:

1. I'd rather remove any mention of std::wstring and only deal with=20
narrow strings.

2. Parsing string representation should accept std::string_view instead=20
of std::string.

3. I think, parsing should be a separate algorithm rather than a=20
constructor. I think, the current convention is std::from_chars.

http://en.cppreference.com/w/cpp/utility/from_chars

4. Conversion to string should probably be a free function std::to_string.

http://en.cppreference.com/w/cpp/string/basic_string/to_string

Although I could be convinced of having a member function as well.

The reason of having free functions instead of member functions is that=20
it can be useful in generic code that could work with different types,=20
including uuids (think of generic parsing/formatting libraries, like=20
Boost.Spirit).

5. This constructor:

   explicit uuid(uint8_t const * const bytes);

is potentially unsafe. Yes, we know `bytes` should point to 16 bytes,=20
but this interface makes it not obvious and not enforceable. I would=20
rather replace this constructor and std::array-based one with this:

   template< typename ForwardIterator >
   explicit uuid(ForwardIterator bytes_begin, ForwardIterator bytes_end);

This also follows the conventions of other sequences/containers in the=20
standard library.

6. The default constructor should not be explicit. It should be=20
constexpr and noexcept.

7. Where does uuid_variant come from and why is it necessary? I may be=20
forgetting, but I don't remember RFC4122 mentioning variants.

8. Random UUID generation algorithm should accept the random number=20
generator. The proposal should not require the implementation to use=20
some pre-defined, possibly global RNG. It should allow reusing the RNG=20
to generate multiple UUIDs. I would also name the algorithm something=20
like `generate_random_uuid`.

9. I still think the proposal should include other means of generating=20
UUIDs, such as generating UUID from a name. When generating from a name,=20
the algorithm should also accept the hashing function to use.

10. I would like the proposal to explicitly mention that the alignment=20
of the `uuid` type is allowed and encouraged to be higher than 1, if it=20
allows for a faster implementation (read: using vector instructions).=20
Also, the proposal should make clear that the internal representation=20
may not be a straightforward array of bytes and may have arbitrary=20
endianness. This means that iterators should not be defined as pointers.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/57303c84-2692-316d-4d93-05b1926ad9c9%40gmail.com=
..

.

------=_Part_20968_1528765947.1513620466253
Content-Type: multipart/alternative;
 boundary="----=_Part_20969_1544995646.1513620466253"

------=_Part_20969_1544995646.1513620466253
Content-Type: text/plain; charset="UTF-8"

On Monday, December 18, 2017 at 11:26:21 AM UTC-5, Nicolas Lesser wrote:
>
> Didn't we agree that nested namespaces in std should be abolished? I can't
> find the paper proposing it, and I don't know whether it was accepted or
> not, but I completely agree.
>

There was a paper discussing it, but that doesn't mean there was* agreement*
with that paper.

That being said, the proposal contains 1 class, 2 enums, and a small number
of functions. That's* hardly* a good reason to stick them in a namespace,
regardless of the question of nested namespaces in `std`.


> Having to write `std::uuids::make_uuid()` is a bit repetitive. No need for
> a nested namespace IMO.
>
> The library proposed on this paper is a lite one
>>
> Did you mean "light" instead of "lite"?
>
> For the sake of consistency, I propose you name the two string conversion
> functions `to_string` and template it like std::bitset::to_string did. The
> constructor of uuid for the two string types should also be templated.
>
> Shouldn't you be using std::byte instead of std::uint8_t?
>

Especially since `uint8_t` is not required to be implemented.


>
> If you add iterator support, I think it would be nice to also allow
> construction from a pair of iterators.
>

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

------=_Part_20969_1544995646.1513620466253
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, December 18, 2017 at 11:26:21 AM UTC-5, Nicolas=
 Lesser wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>Didn&#39;t we agree that nested namespaces in std should be abolished? I c=
an&#39;t find the paper proposing it, and I don&#39;t know whether it was a=
ccepted or not, but I completely agree.</div></blockquote><div><br></div><d=
iv>There was a paper discussing it, but that doesn&#39;t mean there was<i> =
agreement</i> with that paper.</div><div><br></div><div>That being said, th=
e proposal contains 1 class, 2 enums, and a small number of functions. That=
&#39;s<i> hardly</i> a good reason to stick them in a namespace, regardless=
 of the question of nested namespaces in `std`.</div><div><i></i><i></i>=C2=
=A0</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">Havi=
ng to write `std::uuids::make_uuid()` is a bit repetitive. No need for a ne=
sted namespace IMO.<div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">The library proposed on this paper is a lite one<br></blockquote=
><div>Did you mean &quot;light&quot; instead of &quot;lite&quot;?</div><div=
><br></div><div>For the sake of consistency, I propose you name the two str=
ing conversion functions `to_string` and template it like std::bitset::to_s=
tring did. The constructor of uuid for the two string types should also be =
templated.</div><div>=C2=A0</div><div>Shouldn&#39;t you be using std::byte =
instead of std::uint8_t?</div></div></blockquote><div><br></div><div>Especi=
ally since `uint8_t` is not required to be implemented.</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br><=
/div><div>If you add iterator support, I think it would be nice to also all=
ow construction from a pair of iterators.</div></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4eaedd85-d3ff-4b9f-a357-ac2ebe8d9bd6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4eaedd85-d3ff-4b9f-a357-ac2ebe8d9bd6=
%40isocpp.org</a>.<br />

------=_Part_20969_1544995646.1513620466253--

------=_Part_20968_1528765947.1513620466253--

.

--94eb2c18a606eb86540560af5099
Content-Type: text/plain; charset="UTF-8"

Thank you all for the good feedback so far. Let me try to answer to your
comments.

you have an implementation, great!  On what compilers was it tested?


Visual C++ 2017 15.4.5 on Windows and Clang Apple LLVM version 9.0.0
(clang-900.0.39.2) on Mac.

is there a way to use it without dynamic memory allocation?


What sort of dynamic memory allocation? Apologizes, but not sure I get the
question.

Didn't we agree that nested namespaces in std should be abolished? I can't
> find the paper proposing it, and I don't know whether it was accepted or
> not, but I completely agree. Having to write `std::uuids::make_uuid()` is a
> bit repetitive. No need for a nested namespace IMO.



> There was a paper discussing it, but that doesn't mean there was agreement
> with that paper.

That being said, the proposal contains 1 class, 2 enums, and a small number
> of functions. That's hardly a good reason to stick them in a namespace,
> regardless of the question of nested namespaces in `std`.


I was not aware of such agreement. My personal opinion is that there should
be separate namespaces for different libraries, not just a big bloated
namespace (to bring them all and in the darkness bind them). But if that is
the agreement, or you believe the library is too small to have its own
namespace I'm fine with std too.

Shouldn't you be using std::byte instead of std::uint8_t?


My thoughts were that I want to make it simply constructible from an array
of unsigned chars, without having to explicitly convert every single one to
std::byte. But I see there is a consensus std::byte should be the one to go
with, so I will do that.

For the sake of consistency, I propose you name the two string conversion
> functions `to_string` and template it like std::bitset::to_string did. The
> constructor of uuid for the two string types should also be templated.


Conversion to string should probably be a free function std::to_string.
> http://en.cppreference.com/w/cpp/string/basic_string/to_string


I have considered that myself and after some thoughts I decided to go with
member functions string()/wstring(). The reason for that was I have seen
the same thing was done for filesystem::path, which is the newest library
to the standard, so I though that should be a good model. You seem to think
that is not the case.

I'd rather remove any mention of std::wstring and only deal with narrow
> strings.]


Can you please explain why?

Parsing string representation should accept std::string_view instead of
> std::string.


Right. I have changed that.

I think, parsing should be a separate algorithm rather than a constructor.
> I think, the current convention is std::from_chars.
> http://en.cppreference.com/w/cpp/utility/from_chars


I think that in the end some thing are all about preferences and style. I
rather prefer simply constructing an object by passing an argument to its
constructor and not call a free function to do so. Again, filesystem::path
supports constructing paths from strings without relying on free functions.
Should the parsing be a free function and not a member one, I would rather
call it make_uuid() and not from_chars, from_string, to_uuid or others. I
would prefer to have overloads for make_uuid(), for the simplicity of the
API.

This constructor:
>   explicit uuid(uint8_t const * const bytes);
> is potentially unsafe. Yes, we know `bytes` should point to 16 bytes, but
> this interface makes it not obvious and not enforceable. I would rather
> replace this constructor and std::array-based one with this:
>   template< typename ForwardIterator >
>   explicit uuid(ForwardIterator bytes_begin, ForwardIterator bytes_end);
> This also follows the conventions of other sequences/containers in the
> standard library.


I was having my own doubts about that particular constructor. I followed
your suggestion and removed it and added an iterator based constructor.

The default constructor should not be explicit. It should be constexpr and
> noexcept.


Done.

Where does uuid_variant come from and why is it necessary? I may be
> forgetting, but I don't remember RFC4122 mentioning variants.


It does under section 4.1.1 (
https://tools.ietf.org/html/rfc4122#section-4.1.1), although three of the
four variants are reserved either for backwards compatibility or future
use. Therefore, in practice we only get uuid_variant::rfc UUIDs, variant 2
(i.e. uuid_variant::microsoft) was used for early GUIDs on the Windows
platform. For instance, 00000000-0000-0000-C000-000000000046 is the uuid
for the IUknown COM interface. This is a variant 2 uuid.

8. Random UUID generation algorithm should accept the random number
> generator. The proposal should not require the implementation to use some
> pre-defined, possibly global RNG. It should allow reusing the RNG to
> generate multiple UUIDs. I would also name the algorithm something like
> `generate_random_uuid`.
> 9. I still think the proposal should include other means of generating
> UUIDs, such as generating UUID from a name. When generating from a name,
> the algorithm should also accept the hashing function to use.
> 10. I would like the proposal to explicitly mention that the alignment of
> the `uuid` type is allowed and encouraged to be higher than 1, if it allows
> for a faster implementation (read: using vector instructions). Also, the
> proposal should make clear that the internal representation may not be a
> straightforward array of bytes and may have arbitrary endianness. This
> means that iterators should not be defined as pointers.


I need a bit more time to think about those ones.

Thank you again,
Marius

On Mon, Dec 18, 2017 at 8:07 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Monday, December 18, 2017 at 11:26:21 AM UTC-5, Nicolas Lesser wrote:
>>
>> Didn't we agree that nested namespaces in std should be abolished? I
>> can't find the paper proposing it, and I don't know whether it was accepted
>> or not, but I completely agree.
>>
>
> There was a paper discussing it, but that doesn't mean there was*
> agreement* with that paper.
>
> That being said, the proposal contains 1 class, 2 enums, and a small
> number of functions. That's* hardly* a good reason to stick them in a
> namespace, regardless of the question of nested namespaces in `std`.
>
>
>> Having to write `std::uuids::make_uuid()` is a bit repetitive. No need
>> for a nested namespace IMO.
>>
>> The library proposed on this paper is a lite one
>>>
>> Did you mean "light" instead of "lite"?
>>
>> For the sake of consistency, I propose you name the two string conversion
>> functions `to_string` and template it like std::bitset::to_string did. The
>> constructor of uuid for the two string types should also be templated.
>>
>> Shouldn't you be using std::byte instead of std::uint8_t?
>>
>
> Especially since `uint8_t` is not required to be implemented.
>
>
>>
>> If you add iterator support, I think it would be nice to also allow
>> construction from a pair of iterators.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/4eaedd85-d3ff-4b9f-
> a357-ac2ebe8d9bd6%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4eaedd85-d3ff-4b9f-a357-ac2ebe8d9bd6%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

--94eb2c18a606eb86540560af5099
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you all for the good feedback so far. Let me try to =
answer to your comments.<div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">you have an implementation, great!=C2=A0 On what compilers wa=
s it tested?</blockquote><div><br></div><div>Visual C++ 2017 15.4.5 on Wind=
ows and Clang=C2=A0Apple LLVM version 9.0.0 (clang-900.0.39.2) on Mac.</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">is there =
a way to use it without dynamic memory allocation?</blockquote><div><br></d=
iv><div>What sort of dynamic memory allocation? Apologizes, but not sure I =
get the question.</div><div><br></div><div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">Didn&#39;t we agree that nested namespaces in std should =
be abolished? I can&#39;t find the paper proposing it, and I don&#39;t know=
 whether it was accepted or not, but I completely agree. Having to write `s=
td::uuids::make_uuid()` is a bit repetitive. No need for a nested namespace=
 IMO.</blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">There was a paper discussing it, but that doesn&#39;t mean there=
 was agreement with that paper.</blockquote><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">That being said, the proposal contains 1 class, 2 enums,=
 and a small number of functions. That&#39;s hardly a good reason to stick =
them in a namespace, regardless of the question of nested namespaces in `st=
d`.</blockquote></div><div><br></div><div>I was not aware of such agreement=
.. My personal opinion is that there should be separate namespaces for diffe=
rent libraries, not just a big bloated namespace (to bring them all and in =
the darkness bind them). But if that is the agreement, or you believe the l=
ibrary is too small to have its own namespace I&#39;m fine with std too.</d=
iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Shouldn=
&#39;t you be using std::byte instead of std::uint8_t?</blockquote><div><br=
></div><div>My thoughts were that I want to make it simply constructible fr=
om an array of unsigned chars, without having to explicitly convert every s=
ingle one to std::byte. But I see there is a consensus std::byte should be =
the one to go with, so I will do that.</div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">For the sake of consistency, I propose yo=
u name the two string conversion functions `to_string` and template it like=
 std::bitset::to_string did. The constructor of uuid for the two string typ=
es should also be templated.</blockquote><div><br></div><div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">Conversion to string should probably be=
 a free function std::to_string.<br><a href=3D"http://en.cppreference.com/w=
/cpp/string/basic_string/to_string">http://en.cppreference.com/w/cpp/string=
/basic_string/to_string</a></blockquote></div><div><br></div><div>I have co=
nsidered that myself and after some thoughts I decided to go with member fu=
nctions string()/wstring(). The reason for that was I have seen the same th=
ing was done for filesystem::path, which is the newest library to the stand=
ard, so I though that should be a good model. You seem to think that is not=
 the case.=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">I&#39;d rather remove any mention of std::wstring and only deal=
 with narrow strings.]</blockquote><div><br></div><div>Can you please expla=
in why?</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">Parsing string representation should accept std::string_view instead of =
std::string.</blockquote><div><br></div><div>Right. I have changed that.</d=
iv><div><br></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I =
think, parsing should be a separate algorithm rather than a constructor. I =
think, the current convention is std::from_chars.<br><a href=3D"http://en.c=
ppreference.com/w/cpp/utility/from_chars">http://en.cppreference.com/w/cpp/=
utility/from_chars</a></blockquote></div><div><br></div><div>I think that i=
n the end some thing are all about preferences and style. I rather prefer s=
imply constructing an object by passing an argument to its constructor and =
not call a free function to do so. Again, filesystem::path supports constru=
cting paths from strings without relying on free functions. Should the pars=
ing be a free function and not a member one, I would rather call it make_uu=
id() and not from_chars, from_string, to_uuid or others. I would prefer to =
have overloads for make_uuid(), for the simplicity of the API.</div><div><b=
r></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This constru=
ctor:<br>=C2=A0 explicit uuid(uint8_t const * const bytes);<br>is potential=
ly unsafe. Yes, we know `bytes` should point to 16 bytes, but this interfac=
e makes it not obvious and not enforceable. I would rather replace this con=
structor and std::array-based one with this:<br>=C2=A0 template&lt; typenam=
e ForwardIterator &gt;<br>=C2=A0 explicit uuid(ForwardIterator bytes_begin,=
 ForwardIterator bytes_end);<br>This also follows the conventions of other =
sequences/containers in the standard library.</blockquote></div><div><br></=
div><div>I was having my own doubts about that particular constructor. I fo=
llowed your suggestion and removed it and added an iterator based construct=
or.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">T=
he default constructor should not be explicit. It should be constexpr and n=
oexcept.</blockquote><div><br></div><div>Done.</div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">Where does uuid_variant come from=
 and why is it necessary? I may be forgetting, but I don&#39;t remember RFC=
4122 mentioning variants.</blockquote><div><br></div><div>It does under sec=
tion 4.1.1 (<a href=3D"https://tools.ietf.org/html/rfc4122#section-4.1.1">h=
ttps://tools.ietf.org/html/rfc4122#section-4.1.1</a>), although three of th=
e four variants are reserved either for backwards compatibility or future u=
se. Therefore, in practice we only get uuid_variant::rfc UUIDs, variant 2 (=
i.e. uuid_variant::microsoft) was used for early GUIDs on the Windows platf=
orm. For instance,=C2=A000000000-0000-0000-C000-000000000046 is the uuid fo=
r the IUknown COM interface. This is a variant 2 uuid.</div><div><br></div>=
<div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">8. Random UUID gener=
ation algorithm should accept the random number generator. The proposal sho=
uld not require the implementation to use some pre-defined, possibly global=
 RNG. It should allow reusing the RNG to generate multiple UUIDs. I would a=
lso name the algorithm something like `generate_random_uuid`.<br>9. I still=
 think the proposal should include other means of generating UUIDs, such as=
 generating UUID from a name. When generating from a name, the algorithm sh=
ould also accept the hashing function to use.<br>10. I would like the propo=
sal to explicitly mention that the alignment of the `uuid` type is allowed =
and encouraged to be higher than 1, if it allows for a faster implementatio=
n (read: using vector instructions). Also, the proposal should make clear t=
hat the internal representation may not be a straightforward array of bytes=
 and may have arbitrary endianness. This means that iterators should not be=
 defined as pointers.</blockquote><div><br></div><div>I need a bit more tim=
e to think about those ones.</div></div><div><br></div><div>Thank you again=
,</div><div>Marius</div></div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On Mon, Dec 18, 2017 at 8:07 PM, Nicol Bolas <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><span class=3D"">On Monday, December 18, 2017 at 11:26:21 AM UTC-5, Ni=
colas Lesser wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>Didn&#39;t we agree that nested namespaces in std should be abolished? I c=
an&#39;t find the paper proposing it, and I don&#39;t know whether it was a=
ccepted or not, but I completely agree.</div></blockquote><div><br></div></=
span><div>There was a paper discussing it, but that doesn&#39;t mean there =
was<i> agreement</i> with that paper.</div><div><br></div><div>That being s=
aid, the proposal contains 1 class, 2 enums, and a small number of function=
s. That&#39;s<i> hardly</i> a good reason to stick them in a namespace, reg=
ardless of the question of nested namespaces in `std`.</div><span class=3D"=
"><div><i></i><i></i>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">Having to write `std::uuids::make_uuid()` is a bit repetitiv=
e. No need for a nested namespace IMO.<div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">The library proposed on this paper is a lite on=
e<br></blockquote><div>Did you mean &quot;light&quot; instead of &quot;lite=
&quot;?</div><div><br></div><div>For the sake of consistency, I propose you=
 name the two string conversion functions `to_string` and template it like =
std::bitset::to_string did. The constructor of uuid for the two string type=
s should also be templated.</div><div>=C2=A0</div><div>Shouldn&#39;t you be=
 using std::byte instead of std::uint8_t?</div></div></blockquote><div><br>=
</div></span><div>Especially since `uint8_t` is not required to be implemen=
ted.</div><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><br></div><div>If you add iterator support, =
I think it would be nice to also allow construction from a pair of iterator=
s.</div></div></blockquote></span></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4eaedd85-d3ff-4b9f-a357-ac2ebe8d9bd6%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4eae=
dd85-d3ff-4b9f-<wbr>a357-ac2ebe8d9bd6%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASyoQ4OeRznfNk_0zyVgE9HJG9vErq=
uLO6W1WNxQzgyczw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASyoQ4Oe=
RznfNk_0zyVgE9HJG9vErquLO6W1WNxQzgyczw%40mail.gmail.com</a>.<br />

--94eb2c18a606eb86540560af5099--

.

On 12/19/17 13:55, Marius Bancila wrote:
>=20
>     Shouldn't you be using std::byte instead of std::uint8_t?
>=20
>=20
> My thoughts were that I want to make it simply constructible from an=20
> array of unsigned chars, without having to explicitly convert every=20
> single one to std::byte. But I see there is a consensus std::byte should=
=20
> be the one to go with, so I will do that.

My personal preference is to keep the support for interpreting `unsigned=20
char`s and `std::uint8_t`s. There are a lot of instances where UUIDs are=20
obtained from external sources, including C code, which has no idea of=20
`std::byte`. Also, `std::byte` requires explicit conversion from=20
integers, which clutters UUID constant initialization for no reason. You=20
can see that in the examples presented in the paper.

As a side note, I'm not that fond of `std::byte` as its use is=20
unnecessarily complicated in real programs. You never ever get or pass=20
pointers to `std::byte`, and `std::byte` constants always require=20
casting. Seems too much effort to use this type for no gain.

>     For the sake of consistency, I propose you name the two string
>     conversion functions `to_string` and template it like
>     std::bitset::to_string did. The constructor of uuid for the two
>     string types should also be templated.
>=20
>=20
>     Conversion to string should probably be a free function std::to_strin=
g.
>     http://en.cppreference.com/w/cpp/string/basic_string/to_string
>=20
>=20
> I have considered that myself and after some thoughts I decided to go=20
> with member functions string()/wstring(). The reason for that was I have=
=20
> seen the same thing was done for filesystem::path, which is the newest=20
> library to the standard, so I though that should be a good model. You=20
> seem to think that is not the case.
>=20
>     I'd rather remove any mention of std::wstring and only deal with
>     narrow strings.]
>=20
> Can you please explain why?

First, the type should not deal with character code conversion. Note=20
that wchar_t encoding is not defined by the standard. Second, if you=20
intend to support wchar_t, then the next question is why not char16_t=20
and char32_t as well? This would unnecessarily complicate the=20
implementation and interface of the component. Third, this is the=20
current convention with respect to other types in the standard library.

>     I think, parsing should be a separate algorithm rather than a
>     constructor. I think, the current convention is std::from_chars.
>     http://en.cppreference.com/w/cpp/utility/from_chars
>=20
> I think that in the end some thing are all about preferences and style.=
=20
> I rather prefer simply constructing an object by passing an argument to=
=20
> its constructor and not call a free function to do so. Again,=20
> filesystem::path supports constructing paths from strings without=20
> relying on free functions.=20

filesystem::path is not an adequate comparison because it mostly wraps a=20
string. It is natural for the path to be constructible from a string -=20
it may not even require any parsing. UUIDs are not strings though, and=20
constructing from a string is not a mere conversion and definitely=20
requires parsing. Such action should better be more explicit and not=20
tied to the type itself.

> Should the parsing be a free function and not=20
> a member one, I would rather call it make_uuid() and not from_chars,=20
> from_string, to_uuid or others. I would prefer to have overloads for=20
> make_uuid(), for the simplicity of the API.

make_uuid is ambiguous. In your proposal you used this name to generate=20
random UUIDs. You could also use this function to generate UUID from=20
names. It goes in conflict with the use of this function to parse an=20
UUID from string.

I would prefer a separate name for each algorithm, a name that describes=20
the behavior most clearly. So generating a random UUID should be=20
something like `generate_random_uuid`, generating from name -=20
`generate_name_uuid` and parsing UUID from a string - `from_chars` or=20
`from_string` - preferably, sonething that has a set convention for this=20
purpose.

>     Where does uuid_variant come from and why is it necessary? I may be
>     forgetting, but I don't remember RFC4122 mentioning variants.
>=20
> It does under section 4.1.1=20
> (https://tools.ietf.org/html/rfc4122#section-4.1.1), although three of=20
> the four variants are reserved either for backwards compatibility or=20
> future use. Therefore, in practice we only get uuid_variant::rfc UUIDs,=
=20
> variant 2 (i.e. uuid_variant::microsoft) was used for early GUIDs on the=
=20
> Windows platform. For instance,=C2=A000000000-0000-0000-C000-000000000046=
 is=20
> the uuid for the IUknown COM interface. This is a variant 2 uuid.

I see. Although I doubt there's practical need in this field.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/916ab47d-df0b-3760-bde6-885d6d95c427%40gmail.com=
..

.

On 12/18/17 21:07, Nicol Bolas wrote:
> On Monday, December 18, 2017 at 11:26:21 AM UTC-5, Nicolas Lesser wrote:
>
>     Shouldn't you be using std::byte instead of std::uint8_t?
>
> Especially since `uint8_t` is not required to be implemented.

UUIDs are defined as 128-bit values. The RFC also defines contents of
specific bits of the value. So, it might make sense precondition UUIDs
on the support for `std::uint8_t`.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/36527ecd-1a3b-750c-2963-980756ed1368%40gmail.com.

.

--94eb2c058af649f5150560b0e60e
Content-Type: text/plain; charset="UTF-8"

>
> is there a way to use it without dynamic memory allocation?
>
>
> What sort of dynamic memory allocation? Apologizes, but not sure I get the
> question.
>

Well, this is not really a specific remark on the proposal itself, but more
on any proposal to come.

In the recent discussions of outcome  <https://github.com/ned14/outcome>
 and/or expected
<https://github.com/viboes/std-make/blob/master/doc/proposal/expected/DXXXXR0_expected.pdf>
I'm
not sure it makes sense to standardize more libraries that support
exceptions as their only error-handling mechanism.
Also the work on the freestanding
<https://github.com/ben-craig/freestanding_proposal/blob/eef741b6b1b8960e9e2e53d59df90e94872f7fb0/freestanding.pdf>proposal
is ongoing (discussed in the december telco of SG14).

I would argue, it also does not make sense to standardize any more
libraries that are not freestanding, that _could_ be made freestanding.
(and const-expr
<http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0202r2.html>, for
that matter)

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

--94eb2c058af649f5150560b0e60e
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:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">is there a way to use it withou=
t dynamic memory allocation?</blockquote><div><br></div></span><div>What so=
rt of dynamic memory allocation? Apologizes, but not sure I get the questio=
n.</div></div></blockquote><div><br></div><div>Well, this is not really a s=
pecific remark on the proposal itself, but more on any proposal to come.</d=
iv><div><br></div><div><div>In the recent discussions of=C2=A0<a href=3D"ht=
tps://github.com/ned14/outcome">outcome=C2=A0</a>=C2=A0and/or=C2=A0<a href=
=3D"https://github.com/viboes/std-make/blob/master/doc/proposal/expected/DX=
XXXR0_expected.pdf">expected=C2=A0</a>=C2=A0I&#39;m not sure it makes sense=
 to standardize more libraries that support exceptions as their only error-=
handling mechanism.</div></div><div>Also the work on the <a href=3D"https:/=
/github.com/ben-craig/freestanding_proposal/blob/eef741b6b1b8960e9e2e53d59d=
f90e94872f7fb0/freestanding.pdf">freestanding </a>proposal is ongoing (disc=
ussed in the december telco of SG14).=C2=A0</div><div><br></div><div>I woul=
d argue, it also does not make sense to standardize any more libraries that=
 are not freestanding, that _could_ be made freestanding. (and <a href=3D"h=
ttp://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0202r2.html">const-expr=
</a>, for that matter)</div><div><br></div><div><br></div><div><br></div><d=
iv><br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADtNNhhG3fJXwWs-t5HNger0Mdy1iWm0U3hq=
%3D7Zg20hsOyin3g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADtNNhhG3fJXwW=
s-t5HNger0Mdy1iWm0U3hq%3D7Zg20hsOyin3g%40mail.gmail.com</a>.<br />

--94eb2c058af649f5150560b0e60e--

.

On ter=C3=A7a-feira, 19 de dezembro de 2017 04:38:06 PST Andrey Semashev wr=
ote:
> On 12/18/17 21:07, Nicol Bolas wrote:
> > On Monday, December 18, 2017 at 11:26:21 AM UTC-5, Nicolas Lesser wrote=
:
> >     Shouldn't you be using std::byte instead of std::uint8_t?
> >=20
> > Especially since `uint8_t` is not required to be implemented.
>=20
> UUIDs are defined as 128-bit values. The RFC also defines contents of
> specific bits of the value. So, it might make sense precondition UUIDs
> on the support for `std::uint8_t`.

Why can't you store 128 bits in a type that is 144 bits long?

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

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/24029574.QojuhPkK4D%40tjmaciei-mobl1.

.

On 12/19/17 20:40, Thiago Macieira wrote:
> On ter=C3=A7a-feira, 19 de dezembro de 2017 04:38:06 PST Andrey Semashev =
wrote:
>> On 12/18/17 21:07, Nicol Bolas wrote:
>>> On Monday, December 18, 2017 at 11:26:21 AM UTC-5, Nicolas Lesser wrote=
:
>>>      Shouldn't you be using std::byte instead of std::uint8_t?
>>>
>>> Especially since `uint8_t` is not required to be implemented.
>>
>> UUIDs are defined as 128-bit values. The RFC also defines contents of
>> specific bits of the value. So, it might make sense precondition UUIDs
>> on the support for `std::uint8_t`.
>=20
> Why can't you store 128 bits in a type that is 144 bits long?

You can, but you will have problems importing/exporting the value as=20
exactly 128 bits with no padding because that is the format defined by=20
the RFC.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/29374397-4080-9082-84cd-97b506e84309%40gmail.com=
..

.

------=_Part_32042_1689606517.1513721114375
Content-Type: multipart/alternative;
 boundary="----=_Part_32043_260970833.1513721114376"

------=_Part_32043_260970833.1513721114376
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tuesday, December 19, 2017 at 2:56:19 AM UTC-8, Marius Bancila wrote:
>
>
> is there a way to use it without dynamic memory allocation?
>
>
> What sort of dynamic memory allocation? Apologizes, but not sure I get th=
e=20
> question.
>

The then-current version had a hard dependency on std::string, which you've=
=20
now fixed, except that I'm still not sure there's any way to extract the=20
"string representation" of a std::uuid object without using std::string.=20
One not-really-solution =E2=80=94 which is probably a good idea anyway =E2=
=80=94 is to=20
provide a stream operator

    ostream& operator<<(ostream&, const uuid&);

that streams the result directly into the ostream rather than needing=20
dynamic memory allocation to convert it to std::string first. Of course,=20
people who want to avoid memory allocation often want to avoid iostreams as=
=20
well; that's why I say this is a not-really-solution.  I have more comments=
=20
on I/O below.


Shouldn't you be using std::byte instead of std::uint8_t?
>
>
> My thoughts were that I want to make it simply constructible from an arra=
y=20
> of unsigned chars, without having to explicitly convert every single one =
to=20
> std::byte. But I see there is a consensus std::byte should be the one to =
go=20
> with, so I will do that.
>

I don't think there's consensus. std::byte is for bytes, not for an array=
=20
that really boils down to a single __uint128_t anyway. The obvious way to=
=20
represent a UUID in memory is as a __uint128_t. The second most obvious way=
=20
is as a pair of uint64_ts, or a set-of-16 uint8_ts. I don't see why=20
std::byte should be relevant at all.

Also, you should remove the begin() and end() methods from class uuid.=20
Iterators are used to enable algorithms over sequences, and a UUID is not a=
=20
sequence. Now, it *can be serialized into* a sequence of 16 bytes, or 2=20
uint64_ts, or ~35 characters, but it is not *itself* a sequence of=20
anything. It's just an object.

=20

> For the sake of consistency, I propose you name the two string conversion=
=20
>> functions `to_string` and template it like std::bitset::to_string did. T=
he=20
>> constructor of uuid for the two string types should also be templated.
>
>
For consistency with std::filesystem::path, I recommend leaving .string()=
=20
and .wstring() alone at least for now.
http://en.cppreference.com/w/cpp/filesystem/path/string
I might equally well bikeshed them to .str() and .wstr(), or suggest=20
implementing operator<< and not providing *any* other stringification API,=
=20
but these are minor details and changing them will not improve the=20
"consistency" of the C++ standard library, which is fundamentally=20
inconsistent in this area.


Conversion to string should probably be a free function std::to_string.
>> http://en.cppreference.com/w/cpp/string/basic_string/to_string=20
>> <http://www.google.com/url?q=3Dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcp=
p%2Fstring%2Fbasic_string%2Fto_string&sa=3DD&sntz=3D1&usg=3DAFQjCNE_1B1Xcm7=
KOvuTgx8xs6Drc_t5sQ>
>
>
> I have considered that myself and after some thoughts I decided to go wit=
h=20
> member functions string()/wstring(). The reason for that was I have seen=
=20
> the same thing was done for filesystem::path, which is the newest library=
=20
> to the standard, so I though that should be a good model. You seem to thi=
nk=20
> that is not the case.
>

The massive overload set of std::to_string() was a mistake in=20
standardization that should never have happened.
What should exist, and does exist in every codebase AFAICT, is

template<class T>
auto to_string(T&& t) {
    std::ostringstream oss;
    oss << std::forward<T>(t);
    return oss.str();
}

Adding overloads to deal with primitive types as special cases is *possible=
*=20
but definitely not *necessary*.


=20

> I'd rather remove any mention of std::wstring and only deal with narrow=
=20
>> strings.]
>
>
> Can you please explain why?
>

wchar_t is not useful in portable code; whereas plain old `char`=20
effectively is portable, because most people "just know" that char is 8-bit=
=20
ASCII or a superset thereof, and std::string works with plain `char`, and=
=20
so on. So the question is really just whether it's worth all the=20
"administrative overhead" =E2=80=94 extra verbiage in the standard, and the=
 entry=20
for .wstring() on cppreference, and so on =E2=80=94 to deal with a case (wc=
har_t)=20
that nobody is going to care about in practice.
However, if you go with operator<<, you don't have to worry as much about=
=20
the administrative overhead. Wide streams and regular streams work pretty=
=20
much the same at the high level, which is all you need in this case. Take a=
=20
look at the one-line specifications of operator<< in=20
[syserr.errcode.nonmembers], [util.smartptr.shared.io], etc.
=20

> I think, parsing should be a separate algorithm rather than a constructor=
..=20
>> I think, the current convention is std::from_chars.
>> http://en.cppreference.com/w/cpp/utility/from_chars
>
>
std::from_chars / std::to_chars should not be used as a model of how to do=
=20
things. They're very low-level and difficult to use correctly.  Marius's=20
intuition is correct here.


This constructor:
>>   explicit uuid(uint8_t const * const bytes);
>> is potentially unsafe. Yes, we know `bytes` should point to 16 bytes, bu=
t=20
>> this interface makes it not obvious and not enforceable. I would rather=
=20
>> replace this constructor and std::array-based one with this:
>>   template< typename ForwardIterator >
>>   explicit uuid(ForwardIterator bytes_begin, ForwardIterator bytes_end);
>> This also follows the conventions of other sequences/containers in the=
=20
>> standard library.
>
>
> I was having my own doubts about that particular constructor. I followed=
=20
> your suggestion and removed it and added an iterator based constructor.
>

Well, you definitely need a way to construct a UUID from a string. I would=
=20
expect that to be spelled

    explicit uuid(char const *);

though, rather than

    explicit uuid(uint8_t const *);

It's just a cosmetic difference (assuming your platform's uint8_t is a=20
typedef for plain char and not unsigned char), but it would make it clearer=
=20
what you expect to happen when this constructor is called.


8. Random UUID generation algorithm should accept the random number=20
>> generator. The proposal should not require the implementation to use som=
e=20
>> pre-defined, possibly global RNG. It should allow reusing the RNG to=20
>> generate multiple UUIDs. I would also name the algorithm something like=
=20
>> `generate_random_uuid`.
>>
>
If you mean make_uuid(), I believe the problem there is that make_uuid() is=
=20
specified to create a "version 1" UUID using the platform's own=20
OS-dependent method of generating UUIDs. This is not going to be=20
parameterizable with anything like a C++ random number engine. (Nor should=
=20
it be.)
It would be possible to provide another factory for "version 4" RNG-based=
=20
UUIDs, parameterized on the RNG engine.

Speaking of versions, why do you have
    uuid_variant::future
    uuid_version::none
I would naively expect to see "uuid_foo::unknown" for both of these. In=20
particular, "future" seems like a bad name because it collides with=20
"std::future" and because it implies something about historical time which=
=20
might or might not be accurate by the time programmers start using this=20
library.  The name "unknown" would be accurate and easy to remember, if=20
used consistently.


9. I still think the proposal should include other means of generating=20
>> UUIDs, such as generating UUID from a name. When generating from a name,=
=20
>> the algorithm should also accept the hashing function to use.
>>
>
Sadly, RFC 4122 defines "version" numbers 3 and 5 for the relatively=20
obsolete MD5 and SHA-1 hashes respectively, and does not define any=20
"version" numbers for present-day hashes such as SHA-256. I'd say it's very=
=20
important to make sure that such UUID-generating functions *can be written =
*using=20
the primitives this library provides; but it is not important to provide=20
those UUID-generating functions out of the box as *part* of this library.
=20

> 10. I would like the proposal to explicitly mention that the alignment of=
=20
>> the `uuid` type is allowed and encouraged to be higher than 1, if it all=
ows=20
>> for a faster implementation (read: using vector instructions). Also, the=
=20
>> proposal should make clear that the internal representation may not be a=
=20
>> straightforward array of bytes and may have arbitrary endianness. This=
=20
>> means that iterators should not be defined as pointers.
>
>
> I need a bit more time to think about those ones.
>

Iterators should not be provided at all, because a UUID is not a container=
=20
or sequence of objects.
But yes, I would expect the natural alignment of `class uuid` on, say, a=20
RISC machine, to be the same as the alignment of `__uint128_t` or=20
`uint64_t`.

my $.02,
Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/704c7dc2-1fd1-42fa-bca3-545ccc3b55e1%40isocpp.or=
g.

------=_Part_32043_260970833.1513721114376
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, December 19, 2017 at 2:56:19 AM UTC-8, Marius =
Bancila wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">is there =
a way to use it without dynamic memory allocation?</blockquote><div><br></d=
iv><div>What sort of dynamic memory allocation? Apologizes, but not sure I =
get the question.</div></div></blockquote><div><br></div><div>The then-curr=
ent version had a hard dependency on std::string, which you&#39;ve now fixe=
d, except that I&#39;m still not sure there&#39;s any way to extract the &q=
uot;string representation&quot; of a std::uuid object without using std::st=
ring. One not-really-solution =E2=80=94 which is probably a good idea anywa=
y =E2=80=94 is to provide a stream operator</div><div><br></div><div>=C2=A0=
 =C2=A0 ostream&amp; operator&lt;&lt;(ostream&amp;, const uuid&amp;);</div>=
<div><br></div><div>that streams the result directly into the ostream rathe=
r than needing dynamic memory allocation to convert it to std::string first=
.. Of course, people who want to avoid memory allocation often want to avoid=
 iostreams as well; that&#39;s why I say this is a not-really-solution. =C2=
=A0I have more comments on I/O below.</div><div><br></div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">Shouldn&#39;t you be using std::byte ins=
tead of std::uint8_t?</blockquote><div><br></div><div>My thoughts were that=
 I want to make it simply constructible from an array of unsigned chars, wi=
thout having to explicitly convert every single one to std::byte. But I see=
 there is a consensus std::byte should be the one to go with, so I will do =
that.</div></div></blockquote><div><br></div><div>I don&#39;t think there&#=
39;s consensus. std::byte is for bytes, not for an array that really boils =
down to a single __uint128_t anyway. The obvious way to represent a UUID in=
 memory is as a __uint128_t. The second most obvious way is as a pair of ui=
nt64_ts, or a set-of-16 uint8_ts. I don&#39;t see why std::byte should be r=
elevant at all.</div><div><br></div><div>Also, you should remove the begin(=
) and end() methods from class uuid. Iterators are used to enable algorithm=
s over sequences, and a UUID is not a sequence. Now, it <i>can be serialize=
d=C2=A0into</i> a sequence of 16 bytes, or 2 uint64_ts, or ~35 characters, =
but it is not <i>itself</i> a sequence of anything. It&#39;s just an object=
..</div><div><br></div><div>=C2=A0<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><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">For the sake of consistency, I propose you name the two str=
ing conversion functions `to_string` and template it like std::bitset::to_s=
tring did. The constructor of uuid for the two string types should also be =
templated.</blockquote></div></blockquote><div><br></div><div>For consisten=
cy with std::filesystem::path, I recommend leaving .string() and .wstring()=
 alone at least for now.</div><div><a href=3D"http://en.cppreference.com/w/=
cpp/filesystem/path/string">http://en.cppreference.com/w/cpp/filesystem/pat=
h/string</a><br></div><div>I might equally well bikeshed them to .str() and=
 .wstr(), or suggest implementing operator&lt;&lt; and not providing <i>any=
</i> other stringification API, but these are minor details and changing th=
em will not improve the &quot;consistency&quot; of the C++ standard library=
, which is fundamentally inconsistent in this area.</div><div><br></div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">Conversion to string =
should probably be a free function std::to_string.<br><a href=3D"http://www=
..google.com/url?q=3Dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fstring%2Fb=
asic_string%2Fto_string&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNE_1B1Xcm7KO=
vuTgx8xs6Drc_t5sQ" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%=
2Fw%2Fcpp%2Fstring%2Fbasic_string%2Fto_string\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNE_1B1Xcm7KOvuTgx8xs6Drc_t5sQ&#39;;return true;" onclick=3D"this.=
href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com=
%2Fw%2Fcpp%2Fstring%2Fbasic_string%2Fto_string\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNE_1B1Xcm7KOvuTgx8xs6Drc_t5sQ&#39;;return true;">http://en.cppre=
ference.com/w/<wbr>cpp/string/basic_string/to_<wbr>string</a></blockquote><=
/div><div><br></div><div>I have considered that myself and after some thoug=
hts I decided to go with member functions string()/wstring(). The reason fo=
r that was I have seen the same thing was done for filesystem::path, which =
is the newest library to the standard, so I though that should be a good mo=
del. You seem to think that is not the case.</div></div></blockquote><div><=
br></div><div>The massive overload set of std::to_string() was a mistake in=
 standardization that should never have happened.</div><div>What should exi=
st, and does exist in every codebase AFAICT, is</div><div><br></div><div>te=
mplate&lt;class T&gt;</div><div>auto to_string(T&amp;&amp; t) {</div><div>=
=C2=A0 =C2=A0 std::ostringstream oss;</div><div>=C2=A0 =C2=A0 oss &lt;&lt; =
std::forward&lt;T&gt;(t);</div><div>=C2=A0 =C2=A0 return oss.str();</div><d=
iv>}</div><div><br></div><div>Adding overloads to deal with primitive types=
 as special cases is <i>possible</i> but definitely not <i>necessary</i>.</=
div><div><br></div><div><br></div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">I&#39;d rather remove any mention of std::wstring a=
nd only deal with narrow strings.]</blockquote><div><br></div><div>Can you =
please explain why?</div></div></blockquote><div><br></div><div>wchar_t is =
not useful in portable code; whereas plain old `char` effectively is portab=
le, because most people &quot;just know&quot; that char is 8-bit ASCII or a=
 superset thereof, and std::string works with plain `char`, and so on. So t=
he question is really just whether it&#39;s worth all the &quot;administrat=
ive overhead&quot; =E2=80=94 extra verbiage in the standard, and the entry =
for .wstring() on cppreference, and so on =E2=80=94 to deal with a case (wc=
har_t) that nobody is going to care about in practice.</div><div>However, i=
f you go with operator&lt;&lt;, you don&#39;t have to worry as much about t=
he administrative overhead. Wide streams and regular streams work pretty mu=
ch the same at the high level, which is all you need in this case. Take a l=
ook at the one-line specifications of operator&lt;&lt; in [syserr.errcode.n=
onmembers], [util.smartptr.shared.io], etc.</div><div>=C2=A0</div><blockquo=
te 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><div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">I think, parsing should be a se=
parate algorithm rather than a constructor. I think, the current convention=
 is std::from_chars.<br><a href=3D"http://en.cppreference.com/w/cpp/utility=
/from_chars" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2F=
cpp%2Futility%2Ffrom_chars\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFGjfZnbq=
LdsMssQqtty_VHnQFOsw&#39;;return true;" onclick=3D"this.href=3D&#39;http://=
www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Futilit=
y%2Ffrom_chars\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFGjfZnbqLdsMssQqtty_=
VHnQFOsw&#39;;return true;">http://en.cppreference.com/w/<wbr>cpp/utility/f=
rom_chars</a></blockquote></div></div></blockquote><div><br></div><div>std:=
:from_chars / std::to_chars should not be used as a model of how to do thin=
gs. They&#39;re very low-level and difficult to use correctly. =C2=A0Marius=
&#39;s intuition is correct here.</div><div><br></div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">This constructor:<br>=C2=A0 explicit uu=
id(uint8_t const * const bytes);<br>is potentially unsafe. Yes, we know `by=
tes` should point to 16 bytes, but this interface makes it not obvious and =
not enforceable. I would rather replace this constructor and std::array-bas=
ed one with this:<br>=C2=A0 template&lt; typename ForwardIterator &gt;<br>=
=C2=A0 explicit uuid(ForwardIterator bytes_begin, ForwardIterator bytes_end=
);<br>This also follows the conventions of other sequences/containers in th=
e standard library.</blockquote></div><div><br></div><div>I was having my o=
wn doubts about that particular constructor. I followed your suggestion and=
 removed it and added an iterator based constructor.</div></div></blockquot=
e><div><br></div><div>Well, you definitely need a way to construct a UUID f=
rom a string. I would expect that to be spelled</div><div><br></div><div>=
=C2=A0 =C2=A0 explicit uuid(char const *);</div><div><br></div><div>though,=
 rather than</div><div><br></div><div>=C2=A0 =C2=A0 explicit uuid(uint8_t c=
onst *);</div><div><br></div><div>It&#39;s just a cosmetic difference (assu=
ming your platform&#39;s uint8_t is a typedef for plain char and not unsign=
ed char), but it would make it clearer what you expect to happen when this =
constructor is called.</div><div><br></div><div><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><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">8. Random UUID generation algorithm should accept =
the random number generator. The proposal should not require the implementa=
tion to use some pre-defined, possibly global RNG. It should allow reusing =
the RNG to generate multiple UUIDs. I would also name the algorithm somethi=
ng like `generate_random_uuid`.<br></blockquote></div></div></blockquote><d=
iv><br></div><div>If you mean make_uuid(), I believe the problem there is t=
hat make_uuid() is specified to create a &quot;version 1&quot; UUID using t=
he platform&#39;s own OS-dependent method of generating UUIDs. This is not =
going to be parameterizable with anything like a C++ random number engine. =
(Nor should it be.)</div><div>It would be possible to provide another facto=
ry for &quot;version 4&quot; RNG-based UUIDs, parameterized on the RNG engi=
ne.</div><div><br></div><div>Speaking of versions, why do you have</div><di=
v>=C2=A0 =C2=A0 uuid_variant::future</div><div>=C2=A0 =C2=A0 uuid_version::=
none</div><div>I would naively expect to see &quot;uuid_foo::unknown&quot; =
for both of these. In particular, &quot;future&quot; seems like a bad name =
because it collides with &quot;std::future&quot; and because it implies som=
ething about historical time which might or might not be accurate by the ti=
me programmers start using this library. =C2=A0The name &quot;unknown&quot;=
 would be accurate and easy to remember, if used consistently.</div><div><b=
r></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">9. I still=
 think the proposal should include other means of generating UUIDs, such as=
 generating UUID from a name. When generating from a name, the algorithm sh=
ould also accept the hashing function to use.<br></blockquote></div></div><=
/blockquote><div><br></div><div>Sadly, RFC 4122 defines &quot;version&quot;=
 numbers 3 and 5 for the relatively obsolete MD5 and SHA-1 hashes respectiv=
ely, and does not define any &quot;version&quot; numbers for present-day ha=
shes such as SHA-256. I&#39;d say it&#39;s very important to make sure that=
 such UUID-generating functions <i>can be written=C2=A0</i>using the primit=
ives this library provides; but it is not important to provide those UUID-g=
enerating functions out of the box as <i>part</i> of this library.</div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">10. I would like th=
e proposal to explicitly mention that the alignment of the `uuid` type is a=
llowed and encouraged to be higher than 1, if it allows for a faster implem=
entation (read: using vector instructions). Also, the proposal should make =
clear that the internal representation may not be a straightforward array o=
f bytes and may have arbitrary endianness. This means that iterators should=
 not be defined as pointers.</blockquote><div><br></div><div>I need a bit m=
ore time to think about those ones.</div></div></div></blockquote><div><br>=
</div><div>Iterators should not be provided at all, because a UUID is not a=
 container or sequence of objects.</div><div>But yes, I would expect the na=
tural alignment of `class uuid` on, say, a RISC machine, to be the same as =
the alignment of `__uint128_t` or `uint64_t`.</div><div><br></div><div>my $=
..02,</div><div>Arthur</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/704c7dc2-1fd1-42fa-bca3-545ccc3b55e1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/704c7dc2-1fd1-42fa-bca3-545ccc3b55e1=
%40isocpp.org</a>.<br />

------=_Part_32043_260970833.1513721114376--

------=_Part_32042_1689606517.1513721114375--

.

On ter=C3=A7a-feira, 19 de dezembro de 2017 13:13:24 PST Andrey Semashev wr=
ote:
> On 12/19/17 20:40, Thiago Macieira wrote:
> > On ter=C3=A7a-feira, 19 de dezembro de 2017 04:38:06 PST Andrey Semashe=
v wrote:
> >> On 12/18/17 21:07, Nicol Bolas wrote:
> >>> On Monday, December 18, 2017 at 11:26:21 AM UTC-5, Nicolas Lesser wro=
te:
> >>>      Shouldn't you be using std::byte instead of std::uint8_t?
> >>>=20
> >>> Especially since `uint8_t` is not required to be implemented.
> >>=20
> >> UUIDs are defined as 128-bit values. The RFC also defines contents of
> >> specific bits of the value. So, it might make sense precondition UUIDs
> >> on the support for `std::uint8_t`.
> >=20
> > Why can't you store 128 bits in a type that is 144 bits long?
>=20
> You can, but you will have problems importing/exporting the value as
> exactly 128 bits with no padding because that is the format defined by
> the RFC.

Why would I have such problems?

Please answer in a hypothetical 9-bit machine that has 8-bit network and=20
filesystem capabilities.

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

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1682555.6eEWCFAsHV%40tjmaciei-mobl1.

.

On 12/20/17 01:05, Arthur O'Dwyer wrote:
> On Tuesday, December 19, 2017 at 2:56:19 AM UTC-8, Marius Bancila wrote:
>=20
>=20
>         is there a way to use it without dynamic memory allocation?
>=20
>=20
>     What sort of dynamic memory allocation? Apologizes, but not sure I
>     get the question.
>=20
>=20
> The then-current version had a hard dependency on std::string, which=20
> you've now fixed, except that I'm still not sure there's any way to=20
> extract the "string representation" of a std::uuid object without using=
=20
> std::string. One not-really-solution =E2=80=94 which is probably a good i=
dea=20
> anyway =E2=80=94 is to provide a stream operator
>=20
>  =C2=A0 =C2=A0 ostream& operator<<(ostream&, const uuid&);
>=20
> that streams the result directly into the ostream rather than needing=20
> dynamic memory allocation to convert it to std::string first. Of course,=
=20
> people who want to avoid memory allocation often want to avoid iostreams=
=20
> as well; that's why I say this is a not-really-solution. =C2=A0I have mor=
e=20
> comments on I/O below.

If you want to have a malloc-free interface then iostreams are not the=20
way to go. You would need a method that would produce the string=20
representation of an UUID in an externally provided buffer.

   char buf[100];
   uuid.to_string(buf, sizeof(buf));

Unfortunately, such an interface is not convenitnt when you can malloc=20
and just want to get the string in-line:

   throw std::runtime_error("Transaction " + uuid.to_string() + " failed");

>         Shouldn't you be using std::byte instead of std::uint8_t?
>=20
>     My thoughts were that I want to make it simply constructible from an
>     array of unsigned chars, without having to explicitly convert every
>     single one to std::byte. But I see there is a consensus std::byte
>     should be the one to go with, so I will do that.
>=20
> I don't think there's consensus. std::byte is for bytes, not for an=20
> array that really boils down to a single __uint128_t anyway. The obvious=
=20
> way to represent a UUID in memory is as a __uint128_t. The second most=20
> obvious way is as a pair of uint64_ts, or a set-of-16 uint8_ts. I don't=
=20
> see why std::byte should be relevant at all.

Not std::byte itself, but std::uuid should allow to be created from an=20
array of 16 bytes, which have contents defined in RFC:

https://tools.ietf.org/html/rfc4122#section-4.1.2

> Also, you should remove the begin() and end() methods from class uuid.=20
> Iterators are used to enable algorithms over sequences, and a UUID is=20
> not a sequence. Now, it /can be serialized=C2=A0into/ a sequence of 16 by=
tes,=20
> or 2 uint64_ts, or ~35 characters, but it is not /itself/ a sequence of=
=20
> anything. It's just an object.

Iterators offer the natural way of serialization:

    std::uint8_t bytes[16];
    std::copy(uuid.begin(), uuid.end(), bytes);

If iterators are not provided then std::uuid should provide a dedicated=20
method for exporting its contents. Which might not be a bad idea.

> The massive overload set of std::to_string() was a mistake in=20
> standardization that should never have happened.
> What should exist, and does exist in every codebase AFAICT, is
>=20
> template<class T>
> auto to_string(T&& t) {
>  =C2=A0 =C2=A0 std::ostringstream oss;
>  =C2=A0 =C2=A0 oss << std::forward<T>(t);
>  =C2=A0 =C2=A0 return oss.str();
> }
>=20
> Adding overloads to deal with primitive types as special cases is=20
> /possible/ but definitely not /necessary/.

This is essentianlly what `boost::lexical_cast< std::string >(t)` is.=20
One of the benefits of `std::to_string` is that it _doesn't_ use=20
iostreams. The above might be good as the default fallback=20
implementation, but people (and compiler writerts) should be highly=20
encouraged to provide more efficient implementations for specific types.

>         I think, parsing should be a separate algorithm rather than a
>         constructor. I think, the current convention is std::from_chars.
>         http://en.cppreference.com/w/cpp/utility/from_chars
>         <http://en.cppreference.com/w/cpp/utility/from_chars>
>=20
> std::from_chars / std::to_chars should not be used as a model of how to=
=20
> do things. They're very low-level and difficult to use correctly.=20
>  =C2=A0Marius's intuition is correct here.

The interface looks like what no-exceptions people would want to use.=20
The throwing alternative could look like this:

   uuid uuid_from_string(std::string_view str);

But in any case, such conversion should not be the std::uuid's constructor.

>         This constructor:
>          =C2=A0 explicit uuid(uint8_t const * const bytes);
>         is potentially unsafe. Yes, we know `bytes` should point to 16
>         bytes, but this interface makes it not obvious and not
>         enforceable. I would rather replace this constructor and
>         std::array-based one with this:
>          =C2=A0 template< typename ForwardIterator >
>          =C2=A0 explicit uuid(ForwardIterator bytes_begin, ForwardIterato=
r
>         bytes_end);
>         This also follows the conventions of other sequences/containers
>         in the standard library.
>=20
>=20
>     I was having my own doubts about that particular constructor. I
>     followed your suggestion and removed it and added an iterator based
>     constructor.
>=20
>=20
> Well, you definitely need a way to construct a UUID from a string. I=20
> would expect that to be spelled
>=20
>  =C2=A0 =C2=A0 explicit uuid(char const *);
>=20
> though, rather than
>=20
>  =C2=A0 =C2=A0 explicit uuid(uint8_t const *);
>=20
> It's just a cosmetic difference (assuming your platform's uint8_t is a=20
> typedef for plain char and not unsigned char), but it would make it=20
> clearer what you expect to happen when this constructor is called.

I believe, this was not a constructor from a string representation of an=20
UUID but from the binary representation (i.e. the pointer points to 16=20
bytes that are the UUID's value).

>         8. Random UUID generation algorithm should accept the random
>         number generator. The proposal should not require the
>         implementation to use some pre-defined, possibly global RNG. It
>         should allow reusing the RNG to generate multiple UUIDs. I would
>         also name the algorithm something like `generate_random_uuid`.
>=20
>=20
> If you mean make_uuid(), I believe the problem there is that make_uuid()=
=20
> is specified to create a "version 1" UUID using the platform's own=20
> OS-dependent method of generating UUIDs. This is not going to be=20
> parameterizable with anything like a C++ random number engine. (Nor=20
> should it be.)

The proposal wasn't clear about it, and I'm not very familiar with the=20
system APIs mentioned there, but my understanding is that those APIs=20
generate RNG-based UUIDs, i.e. they should be version 4. I think,=20
nowdays version 4 is the only version being widely generated, possibly=20
with the exception of version 5, the name-based UUIDs, when one needs=20
stable name-to-UUID mapping.

In any case, the standard cannot assume the underlying OS has the means=20
to generate UUIDs directly. At most, it can assume some (P)RNG like=20
random_device or Mersenne twister, which is stateful. Requiring=20
make_uuid() to be self-contained on such systems basically means making=20
that (P)RNG global or performing expensive initialization of the RNG on=20
each call. In fact, that's what happens in uuid_generate that was=20
referenced in the proposal, which does stat() and IO on /dev/urandom or=20
/dev/random (although the actual IO may be avoided if getrandom() is=20
present).

> Speaking of versions, why do you have
>  =C2=A0 =C2=A0 uuid_variant::future
>  =C2=A0 =C2=A0 uuid_version::none
> I would naively expect to see "uuid_foo::unknown" for both of these. In=
=20
> particular, "future" seems like a bad name because it collides with=20
> "std::future" and because it implies something about historical time=20
> which might or might not be accurate by the time programmers start using=
=20
> this library. =C2=A0The name "unknown" would be accurate and easy to=20
> remember, if used consistently.

+1

>         9. I still think the proposal should include other means of
>         generating UUIDs, such as generating UUID from a name. When
>         generating from a name, the algorithm should also accept the
>         hashing function to use.
>=20
> Sadly, RFC 4122 defines "version" numbers 3 and 5 for the relatively=20
> obsolete MD5 and SHA-1 hashes respectively, and does not define any=20
> "version" numbers for present-day hashes such as SHA-256.

This is why I mentioned that the algorithm should accept a hashing=20
function to use.

> I'd say it's=20
> very important to make sure that such UUID-generating functions /can be=
=20
> written /using the primitives this library provides; but it is not=20
> important to provide those UUID-generating functions out of the box as=20
> /part/ of this library.

That's certainly a possible approach, but I would still prefer if=20
std::uuid offered a more complete support for UUIDs and not just a=20
wrapper around `std::array<std::uint8_t, 16>`.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/568e19ce-d0f1-ad65-e912-788301c50e7a%40gmail.com=
..

.

On 12/20/17 01:53, Thiago Macieira wrote:
> On ter=C3=A7a-feira, 19 de dezembro de 2017 13:13:24 PST Andrey Semashev =
wrote:
>> On 12/19/17 20:40, Thiago Macieira wrote:
>>> On ter=C3=A7a-feira, 19 de dezembro de 2017 04:38:06 PST Andrey Semashe=
v wrote:
>>>> On 12/18/17 21:07, Nicol Bolas wrote:
>>>>> On Monday, December 18, 2017 at 11:26:21 AM UTC-5, Nicolas Lesser wro=
te:
>>>>>       Shouldn't you be using std::byte instead of std::uint8_t?
>>>>>
>>>>> Especially since `uint8_t` is not required to be implemented.
>>>>
>>>> UUIDs are defined as 128-bit values. The RFC also defines contents of
>>>> specific bits of the value. So, it might make sense precondition UUIDs
>>>> on the support for `std::uint8_t`.
>>>
>>> Why can't you store 128 bits in a type that is 144 bits long?
>>
>> You can, but you will have problems importing/exporting the value as
>> exactly 128 bits with no padding because that is the format defined by
>> the RFC.
>=20
> Why would I have such problems?
>=20
> Please answer in a hypothetical 9-bit machine that has 8-bit network and
> filesystem capabilities.

How exactly such a machine operates in 8-bit environment? How does one=20
represent a 128-bit message on such a machine? I can imagine multiple=20
possibilities, and none of them looks suitable to me, unless I'm missing=20
something.

For example, we could use 8 least significant bits in each 9-bit byte to=20
store the corresponding 8 bits of the UUID. Thus we have 1-bit padding=20
in every byte. There are two problems with this:

- What to do with the padding, especially when importing the UUID into=20
std::uuid? The padding bits must not be part of the UUID value, so the=20
bits bust be either masked or the conversion should fail. The latter I=20
find unacceptable, because all the normal world expects this operation=20
to never fail and be noexcept.

- How to transmit these 144 bits as a 128-bit message to another=20
machine? This means that the program that has exported the value into an=20
array of 9-bit bytes now has to compact the bits somehow and then send=20
only the 128 significant bits to network or something. I have no idea=20
how that would happen. In any case, that kind of conversion is specific=20
to that 9-bit machine and is not needed on 8-bit machines.

Or, we could always use the compacted representation, but then the 9-bit=20
machine would only use 15-byte buffer with some bit padding. This makes=20
the surrounding code different (e.g. buffer sizes may be smaller) and=20
possibly incompatible with 8-bit machines. Ther there is that magic to=20
send exactly 128 bits over the network.

With all that complexity and potentially non-portable code, I would=20
rather limit UUIDs to machines with 8-bit bytes and make that interface=20
and implementation most efficient there.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/50277626-6c7a-38db-ac37-463d0aac5caf%40gmail.com=
..

.

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

We could approach the problem of generating uuids in a similar manner as
done in boost::uuid. We could have generator like this one that uses a
random number generator (and a uniform distribution) to produce uuids:


template <typename UniformRandomNumberGenerator>
class uuid_random_generator
{
public:
  typedef uuid result_type;

  uuid_random_generator();
  explicit uuid_random_generator(UniformRandomNumberGenerator& gen);
  explicit uuid_random_generator(UniformRandomNumberGenerator* pGen);

  uuid operator()();
};


boost also has a name generator, but that requires SHA1 support.

I would propose a "default generator" one that may rely on the operating
system uuid support, as make_uuid() does in my current proposal.

class uuid_default_generator
{
public:
  typedef uuid result_type;

  uuid operator()();
};


Then, we could have two overloads for make_uuid() that would look like this=
:

uuid make_uuid()
{
  return uuid_default_generator{}();
}

template <typename Generator>
uuid make_uuid(Generator & g)
{
  return g();
}


This would enable users to write their own generators, such as one that is
based on name hashing, and use them with make_uuid.

That would allow us to write code like the following:

auto id1 =3D make_uuid();

uuid_default_generator dgen;
auto id2 =3D make_uuid(dgen);
auto id3 =3D make_uuid(dgen);

std::random_device rd;
std::mt19937 mtgen(rd());
uuid_random_generator<std::mt19937> rgen(mtgen);
auto id4 =3D make_uuid(rgen);
auto id5 =3D make_uuid(rgen);



What do you think of this?

Marius


On Wed, Dec 20, 2017 at 1:18 AM, Andrey Semashev <andrey.semashev@gmail.com=
>
wrote:

> On 12/20/17 01:53, Thiago Macieira wrote:
>
>> On ter=C3=A7a-feira, 19 de dezembro de 2017 13:13:24 PST Andrey Semashev=
 wrote:
>>
>>> On 12/19/17 20:40, Thiago Macieira wrote:
>>>
>>>> On ter=C3=A7a-feira, 19 de dezembro de 2017 04:38:06 PST Andrey Semash=
ev
>>>> wrote:
>>>>
>>>>> On 12/18/17 21:07, Nicol Bolas wrote:
>>>>>
>>>>>> On Monday, December 18, 2017 at 11:26:21 AM UTC-5, Nicolas Lesser
>>>>>> wrote:
>>>>>>       Shouldn't you be using std::byte instead of std::uint8_t?
>>>>>>
>>>>>> Especially since `uint8_t` is not required to be implemented.
>>>>>>
>>>>>
>>>>> UUIDs are defined as 128-bit values. The RFC also defines contents of
>>>>> specific bits of the value. So, it might make sense precondition UUID=
s
>>>>> on the support for `std::uint8_t`.
>>>>>
>>>>
>>>> Why can't you store 128 bits in a type that is 144 bits long?
>>>>
>>>
>>> You can, but you will have problems importing/exporting the value as
>>> exactly 128 bits with no padding because that is the format defined by
>>> the RFC.
>>>
>>
>> Why would I have such problems?
>>
>> Please answer in a hypothetical 9-bit machine that has 8-bit network and
>> filesystem capabilities.
>>
>
> How exactly such a machine operates in 8-bit environment? How does one
> represent a 128-bit message on such a machine? I can imagine multiple
> possibilities, and none of them looks suitable to me, unless I'm missing
> something.
>
> For example, we could use 8 least significant bits in each 9-bit byte to
> store the corresponding 8 bits of the UUID. Thus we have 1-bit padding in
> every byte. There are two problems with this:
>
> - What to do with the padding, especially when importing the UUID into
> std::uuid? The padding bits must not be part of the UUID value, so the bi=
ts
> bust be either masked or the conversion should fail. The latter I find
> unacceptable, because all the normal world expects this operation to neve=
r
> fail and be noexcept.
>
> - How to transmit these 144 bits as a 128-bit message to another machine?
> This means that the program that has exported the value into an array of
> 9-bit bytes now has to compact the bits somehow and then send only the 12=
8
> significant bits to network or something. I have no idea how that would
> happen. In any case, that kind of conversion is specific to that 9-bit
> machine and is not needed on 8-bit machines.
>
> Or, we could always use the compacted representation, but then the 9-bit
> machine would only use 15-byte buffer with some bit padding. This makes t=
he
> surrounding code different (e.g. buffer sizes may be smaller) and possibl=
y
> incompatible with 8-bit machines. Ther there is that magic to send exactl=
y
> 128 bits over the network.
>
> With all that complexity and potentially non-portable code, I would rathe=
r
> limit UUIDs to machines with 8-bit bytes and make that interface and
> implementation most efficient there.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/50277626-6c7a-38db-ac37-
> 463d0aac5caf%40gmail.com.
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CA%2BgtASxFM_cWykUOXZQPUncLObPyYYDku2iipPmA62vrE=
gmE3w%40mail.gmail.com.

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

<div dir=3D"ltr">We could approach the problem of generating uuids in a sim=
ilar manner as done in boost::uuid. We could have generator like this one t=
hat uses a random number generator (and a uniform distribution) to produce =
uuids:<div><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px">=
<div><br></div><div><div><font face=3D"monospace, monospace">template &lt;t=
ypename UniformRandomNumberGenerator&gt;</font></div></div><div><div><font =
face=3D"monospace, monospace">class uuid_random_generator=C2=A0</font></div=
></div><div><div><font face=3D"monospace, monospace">{</font></div></div><d=
iv><div><font face=3D"monospace, monospace">public:</font></div></div><div>=
<div><font face=3D"monospace, monospace">=C2=A0 typedef uuid result_type;</=
font></div></div><div><div><font face=3D"monospace, monospace"><br></font><=
/div></div><div><div><font face=3D"monospace, monospace">=C2=A0 uuid_random=
_generator();</font></div></div><div><div><font face=3D"monospace, monospac=
e">=C2=A0 explicit uuid_random_generator(UniformRandomNumberGenerator&amp; =
gen);</font></div></div><div><div><font face=3D"monospace, monospace">=C2=
=A0 explicit uuid_random_generator(UniformRandomNumberGenerator* pGen);</fo=
nt></div></div><div><div><font face=3D"monospace, monospace"><br></font></d=
iv></div><div><div><font face=3D"monospace, monospace">=C2=A0 uuid operator=
()();</font></div></div><div><div><font face=3D"monospace, monospace">};</f=
ont></div></div></blockquote></div><div><div><br></div><div>boost also has =
a name generator, but that requires SHA1 support.</div><div><br></div><div>=
I would propose a &quot;default generator&quot; one that may rely on the op=
erating system uuid support, as make_uuid() does in my current proposal.</d=
iv><div><font face=3D"monospace, monospace"><br></font></div></div><blockqu=
ote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div><div><div><fon=
t face=3D"monospace, monospace">class uuid_default_generator</font></div></=
div></div><div><div><div><font face=3D"monospace, monospace">{</font></div>=
</div></div><div><div><div><font face=3D"monospace, monospace">public:</fon=
t></div></div></div><div><div><div><font face=3D"monospace, monospace">=C2=
=A0 typedef uuid result_type;</font></div></div></div><div><div><div><font =
face=3D"monospace, monospace"><br></font></div></div></div><div><div><div><=
font face=3D"monospace, monospace">=C2=A0 uuid operator()();</font></div></=
div></div><div><div><div><font face=3D"monospace, monospace">};</font></div=
></div></div></blockquote><div><div><br></div><div>Then, we could have two =
overloads for make_uuid() that would look like this:</div><div><font face=
=3D"monospace, monospace"><br></font></div></div><blockquote style=3D"margi=
n:0 0 0 40px;border:none;padding:0px"><div><div><div><font face=3D"monospac=
e, monospace">uuid make_uuid()</font></div></div></div><div><div><div><font=
 face=3D"monospace, monospace">{</font></div></div></div><div><div><div><fo=
nt face=3D"monospace, monospace">=C2=A0 return uuid_default_generator{}();<=
/font></div></div></div><div><div><div><font face=3D"monospace, monospace">=
}</font></div></div></div><div><div><div><font face=3D"monospace, monospace=
"><br></font></div></div></div><div><div><div><font face=3D"monospace, mono=
space">template &lt;typename Generator&gt;</font></div></div></div><div><di=
v><div><font face=3D"monospace, monospace">uuid make_uuid(Generator &amp; g=
)=C2=A0</font></div></div></div><div><div><div><font face=3D"monospace, mon=
ospace">{</font></div></div></div><div><div><div><font face=3D"monospace, m=
onospace">=C2=A0 return g();</font></div></div></div><div><div><div><font f=
ace=3D"monospace, monospace">}</font></div></div></div></blockquote><div><d=
iv><br></div><div>This would enable users to write their own generators, su=
ch as one that is based on name hashing, and use them with make_uuid.</div>=
<div><br></div><div>That would allow us to write code like the following:</=
div><div><br></div></div><blockquote style=3D"margin:0 0 0 40px;border:none=
;padding:0px"><div><div><div><font face=3D"monospace, monospace">auto id1 =
=3D make_uuid();</font></div></div></div><div><div><div><font face=3D"monos=
pace, monospace"><br></font></div></div></div><div><div><div><font face=3D"=
monospace, monospace">uuid_default_generator dgen;</font></div></div></div>=
<div><div><div><font face=3D"monospace, monospace">auto id2 =3D make_uuid(d=
gen);</font></div></div></div><div><div><div><font face=3D"monospace, monos=
pace">auto id3 =3D make_uuid(dgen);</font></div></div></div><div><div><div>=
<font face=3D"monospace, monospace"><br></font></div></div></div><div><div>=
<div><font face=3D"monospace, monospace">std::random_device rd;</font></div=
></div></div><div><div><div><font face=3D"monospace, monospace">std::mt1993=
7 mtgen(rd());</font></div></div></div><div><div><div><font face=3D"monospa=
ce, monospace">uuid_random_generator&lt;std::mt19937&gt; rgen(mtgen);</font=
></div></div></div><div><div><div><font face=3D"monospace, monospace">auto =
id4 =3D make_uuid(rgen);</font></div></div></div><div><div><div><font face=
=3D"monospace, monospace">auto id5 =3D make_uuid(rgen);</font></div></div><=
/div></blockquote><div><div><br></div><div><br></div><div>What do you think=
 of this?</div><div><br></div><div>Marius</div><div><br></div></div></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Dec 20, 20=
17 at 1:18 AM, Andrey Semashev <span dir=3D"ltr">&lt;<a href=3D"mailto:andr=
ey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gmail.com</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 12/20/1=
7 01:53, Thiago Macieira wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On ter=C3=A7a-feira, 19 de dezembro de 2017 13:13:24 PST Andrey Semashev wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 12/19/17 20:40, Thiago Macieira wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On ter=C3=A7a-feira, 19 de dezembro de 2017 04:38:06 PST Andrey Semashev wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 12/18/17 21:07, Nicol Bolas wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Monday, December 18, 2017 at 11:26:21 AM UTC-5, Nicolas Lesser wrote:<br=
>
=C2=A0 =C2=A0 =C2=A0 Shouldn&#39;t you be using std::byte instead of std::u=
int8_t?<br>
<br>
Especially since `uint8_t` is not required to be implemented.<br>
</blockquote>
<br>
UUIDs are defined as 128-bit values. The RFC also defines contents of<br>
specific bits of the value. So, it might make sense precondition UUIDs<br>
on the support for `std::uint8_t`.<br>
</blockquote>
<br>
Why can&#39;t you store 128 bits in a type that is 144 bits long?<br>
</blockquote>
<br>
You can, but you will have problems importing/exporting the value as<br>
exactly 128 bits with no padding because that is the format defined by<br>
the RFC.<br>
</blockquote>
<br>
Why would I have such problems?<br>
<br>
Please answer in a hypothetical 9-bit machine that has 8-bit network and<br=
>
filesystem capabilities.<br>
</blockquote>
<br></span>
How exactly such a machine operates in 8-bit environment? How does one repr=
esent a 128-bit message on such a machine? I can imagine multiple possibili=
ties, and none of them looks suitable to me, unless I&#39;m missing somethi=
ng.<br>
<br>
For example, we could use 8 least significant bits in each 9-bit byte to st=
ore the corresponding 8 bits of the UUID. Thus we have 1-bit padding in eve=
ry byte. There are two problems with this:<br>
<br>
- What to do with the padding, especially when importing the UUID into std:=
:uuid? The padding bits must not be part of the UUID value, so the bits bus=
t be either masked or the conversion should fail. The latter I find unaccep=
table, because all the normal world expects this operation to never fail an=
d be noexcept.<br>
<br>
- How to transmit these 144 bits as a 128-bit message to another machine? T=
his means that the program that has exported the value into an array of 9-b=
it bytes now has to compact the bits somehow and then send only the 128 sig=
nificant bits to network or something. I have no idea how that would happen=
.. In any case, that kind of conversion is specific to that 9-bit machine an=
d is not needed on 8-bit machines.<br>
<br>
Or, we could always use the compacted representation, but then the 9-bit ma=
chine would only use 15-byte buffer with some bit padding. This makes the s=
urrounding code different (e.g. buffer sizes may be smaller) and possibly i=
ncompatible with 8-bit machines. Ther there is that magic to send exactly 1=
28 bits over the network.<br>
<br>
With all that complexity and potentially non-portable code, I would rather =
limit UUIDs to machines with 8-bit bytes and make that interface and implem=
entation most efficient there.<span class=3D""><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/50277626-6c7a-38db-ac37-463d0aac5caf%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/50277626-6c7a-38db-ac37-<wbr>=
463d0aac5caf%40gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxFM_cWykUOXZQPUncLObPyYYDku2=
iipPmA62vrEgmE3w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxFM_cW=
ykUOXZQPUncLObPyYYDku2iipPmA62vrEgmE3w%40mail.gmail.com</a>.<br />

--001a114028e0e2ca920560c04e9d--

.

On ter=C3=A7a-feira, 19 de dezembro de 2017 15:18:46 PST Andrey Semashev wr=
ote:
> How exactly such a machine operates in 8-bit environment? How does one
> represent a 128-bit message on such a machine? I can imagine multiple
> possibilities, and none of them looks suitable to me, unless I'm missing
> something.

You tell me. That's exactly the issue: there's nothing inherently wrong wit=
h=20
those machines and they do operate with an outside world 8-bit environment.=
 So=20
why exactly should UUID in the standard library be forbidden?

> For example, we could use 8 least significant bits in each 9-bit byte to
> store the corresponding 8 bits of the UUID. Thus we have 1-bit padding
> in every byte. There are two problems with this:

I believe that's how they do strings.

> - What to do with the padding, especially when importing the UUID into
> std::uuid? The padding bits must not be part of the UUID value, so the
> bits bust be either masked or the conversion should fail. The latter I
> find unacceptable, because all the normal world expects this operation
> to never fail and be noexcept.

If you consider the UUID as a char[16], I don't see why that would be a=20
problem at all.

> - How to transmit these 144 bits as a 128-bit message to another
> machine? This means that the program that has exported the value into an
> array of 9-bit bytes now has to compact the bits somehow and then send
> only the 128 significant bits to network or something. I have no idea
> how that would happen. In any case, that kind of conversion is specific
> to that 9-bit machine and is not needed on 8-bit machines.

That's a solved problem. Such machines already know how to talk to the outs=
ide=20
world. I asked you to assume such a solution exists (and it does for such=
=20
machines).=20

Usually, the C library of those machines has functions to convert the low 3=
2=20
bits of a of 36-bit multi-byte words into four octet, stored in consecutive=
 9-
bit bytes. Similar for 18-bit words into 2 bytes.

> With all that complexity and potentially non-portable code, I would
> rather limit UUIDs to machines with 8-bit bytes and make that interface
> and implementation most efficient there.

What are you talking about in non-portable code? The standard library for t=
his=20
platform is designed for this platform by the compiler vendor. There's no=
=20
portability issue.

If you meant with the API, then there is only a portability issue if the AP=
I=20
creates one in the first place. So create an API that doesn't have portabil=
ity=20
issues: simply replace uint8_t with unsigned char or std::byte and the prob=
lem=20
is solved. (C++ requires a byte to be at least 8 bits wide)

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

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2608099.0HH9CbnkGl%40tjmaciei-mobl1.

.

On 12/20/17 10:12, Marius Bancila wrote:
> We could approach the problem of generating uuids in a similar manner as=
=20
> done in boost::uuid. We could have generator like this one that uses a=20
> random number generator (and a uniform distribution) to produce uuids:
>=20
>=20
>     template <typename UniformRandomNumberGenerator>
>     class uuid_random_generator
>     {
>     public:
>      =C2=A0 typedef uuid result_type;
>=20
>      =C2=A0 uuid_random_generator();
>      =C2=A0 explicit uuid_random_generator(UniformRandomNumberGenerator& =
gen);
>      =C2=A0 explicit uuid_random_generator(UniformRandomNumberGenerator* =
pGen);
>=20
>      =C2=A0 uuid operator()();
>     };
>=20
>=20
> boost also has a name generator, but that requires SHA1 support.

I don't see the problem of implementing SHA1 in the standard library. It=20
would have value of its own if implemented as a generic component, but=20
in case of std::uuid it can be an internal part of the generator.

> I would propose a "default generator" one that may rely on the operating=
=20
> system uuid support, as make_uuid() does in my current proposal.
>=20
>     class uuid_default_generator
>     {
>     public:
>      =C2=A0 typedef uuid result_type;
>=20
>      =C2=A0 uuid operator()();
>     };

If you put this uuid_default_generator in the standard you effectively=20
*require* the OS to provide this kind of utility. My point is that this=20
requirement is unreasonable and possibly not every OS that currently=20
supports C++ qualifies.

I don't really see the point in having the generator as an object=20
either. This is one part of Boost.UUID design that I don't like. You=20
really want a function, which takes the RNG (in case of random=20
generator) or name and hash function state (in case of name generator)=20
as arguments. It's these arguments that may need to be persistent across=20
multiple calls to the generation algorithm; the algorithm itself has no=20
state.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5fc79b4c-1abe-1d29-5144-d4e0a87a9348%40gmail.com=
..

.

On 12/20/17 10:12, Marius Bancila wrote:
> We could approach the problem of generating uuids in a similar manner as=
=20
> done in boost::uuid. We could have generator like this one that uses a=20
> random number generator (and a uniform distribution) to produce uuids:
>=20
>=20
>     template <typename UniformRandomNumberGenerator>
>     class uuid_random_generator
>     {
>     public:
>      =C2=A0 typedef uuid result_type;
>=20
>      =C2=A0 uuid_random_generator();
>      =C2=A0 explicit uuid_random_generator(UniformRandomNumberGenerator& =
gen);
>      =C2=A0 explicit uuid_random_generator(UniformRandomNumberGenerator* =
pGen);
>=20
>      =C2=A0 uuid operator()();
>     };
>=20
>=20
> boost also has a name generator, but that requires SHA1 support.

I don't see the problem of implementing SHA1 in the standard library. It=20
would have value of its own if implemented as a generic component, but=20
in case of std::uuid it can be an internal part of the generator.

> I would propose a "default generator" one that may rely on the operating=
=20
> system uuid support, as make_uuid() does in my current proposal.
>=20
>     class uuid_default_generator
>     {
>     public:
>      =C2=A0 typedef uuid result_type;
>=20
>      =C2=A0 uuid operator()();
>     };

If you put this uuid_default_generator in the standard you effectively=20
*require* the OS to provide this kind of utility. My point is that this=20
requirement is unreasonable and possibly not every OS that currently=20
supports C++ qualifies.

I don't really see the point in having the generator as an object=20
either. This is one part of Boost.UUID design that I don't like. You=20
really want a function, which takes the RNG (in case of random=20
generator) or name and hash function state (in case of name generator)=20
as arguments. It's these arguments that may need to be persistent across=20
multiple calls to the generation algorithm; the algorithm itself has no=20
state.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0d9c708d-dbf1-5891-9e68-9ed1771c2bae%40gmail.com=
..

.

On 12/20/17 11:27, Thiago Macieira wrote:
> On ter=C3=A7a-feira, 19 de dezembro de 2017 15:18:46 PST Andrey Semashev =
wrote:
>> How exactly such a machine operates in 8-bit environment? How does one
>> represent a 128-bit message on such a machine? I can imagine multiple
>> possibilities, and none of them looks suitable to me, unless I'm missing
>> something.
>=20
> You tell me.

Sorry, it works backwards. I have no idea. None of what I could imagine=20
makes sense, so I consider the idea of supporting non-8-bit machines=20
nonsensical. If you can suggest a sensible way to support those=20
machines, please do.

>> - What to do with the padding, especially when importing the UUID into
>> std::uuid? The padding bits must not be part of the UUID value, so the
>> bits bust be either masked or the conversion should fail. The latter I
>> find unacceptable, because all the normal world expects this operation
>> to never fail and be noexcept.
>=20
> If you consider the UUID as a char[16], I don't see why that would be a
> problem at all.

That should be unsigned char[16]. The problem is that unsigned char[16]=20
does not represent a 128-bit value on a non-8-bit machine. For example,=20
two 144-bit "UUIDs" may not compare equal because of the padding bits.=20
You have to define the meaning and behavior with regard to the bits that=20
are not part of the UUID value. That, in turn, may penalize 8-bit machines.

>> - How to transmit these 144 bits as a 128-bit message to another
>> machine? This means that the program that has exported the value into an
>> array of 9-bit bytes now has to compact the bits somehow and then send
>> only the 128 significant bits to network or something. I have no idea
>> how that would happen. In any case, that kind of conversion is specific
>> to that 9-bit machine and is not needed on 8-bit machines.
>=20
> That's a solved problem. Such machines already know how to talk to the ou=
tside
> world. I asked you to assume such a solution exists (and it does for such
> machines).
>=20
> Usually, the C library of those machines has functions to convert the low=
 32
> bits of a of 36-bit multi-byte words into four octet, stored in consecuti=
ve 9-
> bit bytes. Similar for 18-bit words into 2 bytes.

Who and when calls these functions? Does the C/C++ program need to call=20
these functions to convert the 9-bit bytes to 8-bit bytes before sending=20
a message to network? If the answer is yes then that code that does this=20
is not portable.

>> With all that complexity and potentially non-portable code, I would
>> rather limit UUIDs to machines with 8-bit bytes and make that interface
>> and implementation most efficient there.
>=20
> What are you talking about in non-portable code? The standard library for=
 this
> platform is designed for this platform by the compiler vendor. There's no
> portability issue.

I was talking about a hypothetical implementation that used 128=20
consecutive bits to represent a UUID. So on a 9-bit machine one could write=
:

   unsigned char buf[15]; // 135 bits
   uuid.copy_to(buf); // writes 128 consecutive bits
   network.send_bits(buf, 128 /* bits */);

Such code would not work on an 8-bit machine because unsigned char[15]=20
would not be enough to store a UUID.

> If you meant with the API, then there is only a portability issue if the =
API
> creates one in the first place. So create an API that doesn't have portab=
ility
> issues: simply replace uint8_t with unsigned char or std::byte and the pr=
oblem
> is solved. (C++ requires a byte to be at least 8 bits wide)

It's not solved until you define the behavior on non-8-bit machines.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e92c3788-b880-176f-7d84-169a05f93703%40gmail.com=
..

.

------=_Part_3571_499241328.1513799414627
Content-Type: multipart/alternative;
 boundary="----=_Part_3572_1470935122.1513799414628"

------=_Part_3572_1470935122.1513799414628
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wednesday, December 20, 2017 at 2:19:34 PM UTC-5, Andrey Semashev wrote:
>
> On 12/20/17 11:27, Thiago Macieira wrote:=20
> > On ter=C3=A7a-feira, 19 de dezembro de 2017 15:18:46 PST Andrey Semashe=
v=20
> wrote:=20
> >> How exactly such a machine operates in 8-bit environment? How does one=
=20
> >> represent a 128-bit message on such a machine? I can imagine multiple=
=20
> >> possibilities, and none of them looks suitable to me, unless I'm=20
> missing=20
> >> something.=20
> >=20
> > You tell me.=20
>
> Sorry, it works backwards. I have no idea. None of what I could imagine=
=20
> makes sense, so I consider the idea of supporting non-8-bit machines=20
> nonsensical. If you can suggest a sensible way to support those=20
> machines, please do.=20
>

And yet they do work. Your imagination is not required.

Let them work out how to handle their stuff.
=20

>
> >> - What to do with the padding, especially when importing the UUID into=
=20
> >> std::uuid? The padding bits must not be part of the UUID value, so the=
=20
> >> bits bust be either masked or the conversion should fail. The latter I=
=20
> >> find unacceptable, because all the normal world expects this operation=
=20
> >> to never fail and be noexcept.=20
> >=20
> > If you consider the UUID as a char[16], I don't see why that would be a=
=20
> > problem at all.=20
>
> That should be unsigned char[16]. The problem is that unsigned char[16]=
=20
> does not represent a 128-bit value on a non-8-bit machine. For example,=
=20
> two 144-bit "UUIDs" may not compare equal because of the padding bits.=20
> You have to define the meaning and behavior with regard to the bits that=
=20
> are not part of the UUID value. That, in turn, may penalize 8-bit=20
> machines.=20
>

But there wouldn't be padding bits. If a byte is 9 bits, and you set the=20
value 128 in a 9-bit byte, the top bit is zero. That's not padding; that's=
=20
how you encode 128 in 9 bits.

So the same would be here. An `std::byte[16]` would contain 16 9-bit bytes.=
=20
The high byte of each one would be zero, since each byte only contains=20
values on the range [0, 255].

So two 144-bit "UUIDs" will compare equal if their sequence of 8-bit bytes=
=20
are equal.
=20

>
> >> - How to transmit these 144 bits as a 128-bit message to another=20
> >> machine? This means that the program that has exported the value into=
=20
> an=20
> >> array of 9-bit bytes now has to compact the bits somehow and then send=
=20
> >> only the 128 significant bits to network or something. I have no idea=
=20
> >> how that would happen. In any case, that kind of conversion is specifi=
c=20
> >> to that 9-bit machine and is not needed on 8-bit machines.=20
> >=20
> > That's a solved problem. Such machines already know how to talk to the=
=20
> outside=20
> > world. I asked you to assume such a solution exists (and it does for=20
> such=20
> > machines).=20
> >=20
> > Usually, the C library of those machines has functions to convert the=
=20
> low 32=20
> > bits of a of 36-bit multi-byte words into four octet, stored in=20
> consecutive 9-=20
> > bit bytes. Similar for 18-bit words into 2 bytes.=20
>
> Who and when calls these functions? Does the C/C++ program need to call=
=20
> these functions to convert the 9-bit bytes to 8-bit bytes before sending=
=20
> a message to network? If the answer is yes then that code that does this=
=20
> is not portable.=20
>
> >> With all that complexity and potentially non-portable code, I would=20
> >> rather limit UUIDs to machines with 8-bit bytes and make that interfac=
e=20
> >> and implementation most efficient there.=20
> >=20
> > What are you talking about in non-portable code? The standard library=
=20
> for this=20
> > platform is designed for this platform by the compiler vendor. There's=
=20
> no=20
> > portability issue.=20
>
> I was talking about a hypothetical implementation that used 128=20
> consecutive bits to represent a UUID. So on a 9-bit machine one could=20
> write:=20
>
>    unsigned char buf[15]; // 135 bits=20
>    uuid.copy_to(buf); // writes 128 consecutive bits=20
>    network.send_bits(buf, 128 /* bits */);=20
>
> Such code would not work on an 8-bit machine because unsigned char[15]=20
> would not be enough to store a UUID.=20
>
> > If you meant with the API, then there is only a portability issue if th=
e=20
> API=20
> > creates one in the first place. So create an API that doesn't have=20
> portability=20
> > issues: simply replace uint8_t with unsigned char or std::byte and the=
=20
> problem=20
> > is solved. (C++ requires a byte to be at least 8 bits wide)=20
>
> It's not solved until you define the behavior on non-8-bit machines.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a38c2059-8534-4764-9fe1-16e630814553%40isocpp.or=
g.

------=_Part_3572_1470935122.1513799414628
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, December 20, 2017 at 2:19:34 PM UTC-5, Andre=
y Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 12/20/17 1=
1:27, Thiago Macieira wrote:
<br>&gt; On ter=C3=A7a-feira, 19 de dezembro de 2017 15:18:46 PST Andrey Se=
mashev wrote:
<br>&gt;&gt; How exactly such a machine operates in 8-bit environment? How =
does one
<br>&gt;&gt; represent a 128-bit message on such a machine? I can imagine m=
ultiple
<br>&gt;&gt; possibilities, and none of them looks suitable to me, unless I=
&#39;m missing
<br>&gt;&gt; something.
<br>&gt;=20
<br>&gt; You tell me.
<br>
<br>Sorry, it works backwards. I have no idea. None of what I could imagine=
=20
<br>makes sense, so I consider the idea of supporting non-8-bit machines=20
<br>nonsensical. If you can suggest a sensible way to support those=20
<br>machines, please do.
<br></blockquote><div><br></div><div>And yet they do work. Your imagination=
 is not required.</div><div><br></div><div>Let them work out how to handle =
their stuff.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
<br>&gt;&gt; - What to do with the padding, especially when importing the U=
UID into
<br>&gt;&gt; std::uuid? The padding bits must not be part of the UUID value=
, so the
<br>&gt;&gt; bits bust be either masked or the conversion should fail. The =
latter I
<br>&gt;&gt; find unacceptable, because all the normal world expects this o=
peration
<br>&gt;&gt; to never fail and be noexcept.
<br>&gt;=20
<br>&gt; If you consider the UUID as a char[16], I don&#39;t see why that w=
ould be a
<br>&gt; problem at all.
<br>
<br>That should be unsigned char[16]. The problem is that unsigned char[16]=
=20
<br>does not represent a 128-bit value on a non-8-bit machine. For example,=
=20
<br>two 144-bit &quot;UUIDs&quot; may not compare equal because of the padd=
ing bits.=20
<br>You have to define the meaning and behavior with regard to the bits tha=
t=20
<br>are not part of the UUID value. That, in turn, may penalize 8-bit machi=
nes.
<br></blockquote><div><br></div><div>But there wouldn&#39;t be padding bits=
.. If a byte is 9 bits, and you set the value 128 in a 9-bit byte, the top b=
it is zero. That&#39;s not padding; that&#39;s how you encode 128 in 9 bits=
..</div><div><br></div><div>So the same would be here. An `std::byte[16]` wo=
uld contain 16 9-bit bytes. The high byte of each one would be zero, since =
each byte only contains values on the range [0, 255].</div><div><br></div><=
div>So two 144-bit &quot;UUIDs&quot; will compare equal if their sequence o=
f 8-bit bytes are equal.</div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">
<br>&gt;&gt; - How to transmit these 144 bits as a 128-bit message to anoth=
er
<br>&gt;&gt; machine? This means that the program that has exported the val=
ue into an
<br>&gt;&gt; array of 9-bit bytes now has to compact the bits somehow and t=
hen send
<br>&gt;&gt; only the 128 significant bits to network or something. I have =
no idea
<br>&gt;&gt; how that would happen. In any case, that kind of conversion is=
 specific
<br>&gt;&gt; to that 9-bit machine and is not needed on 8-bit machines.
<br>&gt;=20
<br>&gt; That&#39;s a solved problem. Such machines already know how to tal=
k to the outside
<br>&gt; world. I asked you to assume such a solution exists (and it does f=
or such
<br>&gt; machines).
<br>&gt;=20
<br>&gt; Usually, the C library of those machines has functions to convert =
the low 32
<br>&gt; bits of a of 36-bit multi-byte words into four octet, stored in co=
nsecutive 9-
<br>&gt; bit bytes. Similar for 18-bit words into 2 bytes.
<br>
<br>Who and when calls these functions? Does the C/C++ program need to call=
=20
<br>these functions to convert the 9-bit bytes to 8-bit bytes before sendin=
g=20
<br>a message to network? If the answer is yes then that code that does thi=
s=20
<br>is not portable.
<br>
<br>&gt;&gt; With all that complexity and potentially non-portable code, I =
would
<br>&gt;&gt; rather limit UUIDs to machines with 8-bit bytes and make that =
interface
<br>&gt;&gt; and implementation most efficient there.
<br>&gt;=20
<br>&gt; What are you talking about in non-portable code? The standard libr=
ary for this
<br>&gt; platform is designed for this platform by the compiler vendor. The=
re&#39;s no
<br>&gt; portability issue.
<br>
<br>I was talking about a hypothetical implementation that used 128=20
<br>consecutive bits to represent a UUID. So on a 9-bit machine one could w=
rite:
<br>
<br>=C2=A0 =C2=A0unsigned char buf[15]; // 135 bits
<br>=C2=A0 =C2=A0uuid.copy_to(buf); // writes 128 consecutive bits
<br>=C2=A0 =C2=A0network.send_bits(buf, 128 /* bits */);
<br>
<br>Such code would not work on an 8-bit machine because unsigned char[15]=
=20
<br>would not be enough to store a UUID.
<br>
<br>&gt; If you meant with the API, then there is only a portability issue =
if the API
<br>&gt; creates one in the first place. So create an API that doesn&#39;t =
have portability
<br>&gt; issues: simply replace uint8_t with unsigned char or std::byte and=
 the problem
<br>&gt; is solved. (C++ requires a byte to be at least 8 bits wide)
<br>
<br>It&#39;s not solved until you define the behavior on non-8-bit machines=
..
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a38c2059-8534-4764-9fe1-16e630814553%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a38c2059-8534-4764-9fe1-16e630814553=
%40isocpp.org</a>.<br />

------=_Part_3572_1470935122.1513799414628--

------=_Part_3571_499241328.1513799414627--

.

On 12/20/17 22:50, Nicol Bolas wrote:
> On Wednesday, December 20, 2017 at 2:19:34 PM UTC-5, Andrey Semashev wrot=
e:
>=20
>     On 12/20/17 11:27, Thiago Macieira wrote:
>      > On ter=C3=A7a-feira, 19 de dezembro de 2017 15:18:46 PST Andrey
>=20
>      >> - What to do with the padding, especially when importing the
>     UUID into
>      >> std::uuid? The padding bits must not be part of the UUID value,
>     so the
>      >> bits bust be either masked or the conversion should fail. The
>     latter I
>      >> find unacceptable, because all the normal world expects this
>     operation
>      >> to never fail and be noexcept.
>      >
>      > If you consider the UUID as a char[16], I don't see why that
>     would be a
>      > problem at all.
>=20
>     That should be unsigned char[16]. The problem is that unsigned char[1=
6]
>     does not represent a 128-bit value on a non-8-bit machine. For exampl=
e,
>     two 144-bit "UUIDs" may not compare equal because of the padding bits=
..
>     You have to define the meaning and behavior with regard to the bits
>     that
>     are not part of the UUID value. That, in turn, may penalize 8-bit
>     machines.
>=20
> But there wouldn't be padding bits. If a byte is 9 bits, and you set the=
=20
> value 128 in a 9-bit byte, the top bit is zero. That's not padding;=20
> that's how you encode 128 in 9 bits.

Yes, sorry, by "padding" I meant the additional significant bit.

> So the same would be here. An `std::byte[16]` would contain 16 9-bit=20
> bytes. The high byte of each one would be zero, since each byte only=20
> contains values on the range [0, 255].
>=20
> So two 144-bit "UUIDs" will compare equal if their sequence of 8-bit=20
> bytes are equal.

You will have to deal with the 9th bit when importing UUID from=20
`std::byte[16]` buffer. What if one of the bytes is 256, for example?=20
Should it be considered invalid input?

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5f998357-fd9d-eb89-8212-625bf9befd77%40gmail.com=
..

.

------=_Part_3432_960967487.1513800886893
Content-Type: multipart/alternative;
 boundary="----=_Part_3433_152849521.1513800886894"

------=_Part_3433_152849521.1513800886894
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wednesday, December 20, 2017 at 3:00:06 PM UTC-5, Andrey Semashev wrote:
>
> On 12/20/17 22:50, Nicol Bolas wrote:=20
> > On Wednesday, December 20, 2017 at 2:19:34 PM UTC-5, Andrey Semashev=20
> wrote:=20
> >=20
> >     On 12/20/17 11:27, Thiago Macieira wrote:=20
> >      > On ter=C3=A7a-feira, 19 de dezembro de 2017 15:18:46 PST Andrey=
=20
> >=20
> >      >> - What to do with the padding, especially when importing the=20
> >     UUID into=20
> >      >> std::uuid? The padding bits must not be part of the UUID value,=
=20
> >     so the=20
> >      >> bits bust be either masked or the conversion should fail. The=
=20
> >     latter I=20
> >      >> find unacceptable, because all the normal world expects this=20
> >     operation=20
> >      >> to never fail and be noexcept.=20
> >      >=20
> >      > If you consider the UUID as a char[16], I don't see why that=20
> >     would be a=20
> >      > problem at all.=20
> >=20
> >     That should be unsigned char[16]. The problem is that unsigned=20
> char[16]=20
> >     does not represent a 128-bit value on a non-8-bit machine. For=20
> example,=20
> >     two 144-bit "UUIDs" may not compare equal because of the padding=20
> bits.=20
> >     You have to define the meaning and behavior with regard to the bits=
=20
> >     that=20
> >     are not part of the UUID value. That, in turn, may penalize 8-bit=
=20
> >     machines.=20
> >=20
> > But there wouldn't be padding bits. If a byte is 9 bits, and you set th=
e=20
> > value 128 in a 9-bit byte, the top bit is zero. That's not padding;=20
> > that's how you encode 128 in 9 bits.=20
>
> Yes, sorry, by "padding" I meant the additional significant bit.=20
>
> > So the same would be here. An `std::byte[16]` would contain 16 9-bit=20
> > bytes. The high byte of each one would be zero, since each byte only=20
> > contains values on the range [0, 255].=20
> >=20
> > So two 144-bit "UUIDs" will compare equal if their sequence of 8-bit=20
> > bytes are equal.=20
>
> You will have to deal with the 9th bit when importing UUID from=20
> `std::byte[16]` buffer. What if one of the bytes is 256, for example?=20
> Should it be considered invalid input?=20
>

Each byte of such a valid UUID buffer would be required to be on the range=
=20
[0, 255]. That's all that needs to be said.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/34382f5d-1c66-430d-991b-57cd387686e5%40isocpp.or=
g.

------=_Part_3433_152849521.1513800886894
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, December 20, 2017 at 3:00:06 PM UTC-5, Andre=
y Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 12/20/17 2=
2:50, Nicol Bolas wrote:
<br>&gt; On Wednesday, December 20, 2017 at 2:19:34 PM UTC-5, Andrey Semash=
ev wrote:
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 On 12/20/17 11:27, Thiago Macieira wrote:
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; On ter=C3=A7a-feira, 19 de dezembro de 20=
17 15:18:46 PST Andrey
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; - What to do with the padding, especi=
ally when importing the
<br>&gt; =C2=A0 =C2=A0 UUID into
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; std::uuid? The padding bits must not =
be part of the UUID value,
<br>&gt; =C2=A0 =C2=A0 so the
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; bits bust be either masked or the con=
version should fail. The
<br>&gt; =C2=A0 =C2=A0 latter I
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; find unacceptable, because all the no=
rmal world expects this
<br>&gt; =C2=A0 =C2=A0 operation
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; to never fail and be noexcept.
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; If you consider the UUID as a char[16], I=
 don&#39;t see why that
<br>&gt; =C2=A0 =C2=A0 would be a
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; problem at all.
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 That should be unsigned char[16]. The problem is tha=
t unsigned char[16]
<br>&gt; =C2=A0 =C2=A0 does not represent a 128-bit value on a non-8-bit ma=
chine. For example,
<br>&gt; =C2=A0 =C2=A0 two 144-bit &quot;UUIDs&quot; may not compare equal =
because of the padding bits.
<br>&gt; =C2=A0 =C2=A0 You have to define the meaning and behavior with reg=
ard to the bits
<br>&gt; =C2=A0 =C2=A0 that
<br>&gt; =C2=A0 =C2=A0 are not part of the UUID value. That, in turn, may p=
enalize 8-bit
<br>&gt; =C2=A0 =C2=A0 machines.
<br>&gt;=20
<br>&gt; But there wouldn&#39;t be padding bits. If a byte is 9 bits, and y=
ou set the=20
<br>&gt; value 128 in a 9-bit byte, the top bit is zero. That&#39;s not pad=
ding;=20
<br>&gt; that&#39;s how you encode 128 in 9 bits.
<br>
<br>Yes, sorry, by &quot;padding&quot; I meant the additional significant b=
it.
<br>
<br>&gt; So the same would be here. An `std::byte[16]` would contain 16 9-b=
it=20
<br>&gt; bytes. The high byte of each one would be zero, since each byte on=
ly=20
<br>&gt; contains values on the range [0, 255].
<br>&gt;=20
<br>&gt; So two 144-bit &quot;UUIDs&quot; will compare equal if their seque=
nce of 8-bit=20
<br>&gt; bytes are equal.
<br>
<br>You will have to deal with the 9th bit when importing UUID from=20
<br>`std::byte[16]` buffer. What if one of the bytes is 256, for example?=
=20
<br>Should it be considered invalid input?
<br></blockquote><div><br></div><div>Each byte of such a valid UUID buffer =
would be required to be on the range [0, 255]. That&#39;s all that needs to=
 be said.</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/34382f5d-1c66-430d-991b-57cd387686e5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/34382f5d-1c66-430d-991b-57cd387686e5=
%40isocpp.org</a>.<br />

------=_Part_3433_152849521.1513800886894--

------=_Part_3432_960967487.1513800886893--

.

On 12/20/17 23:14, Nicol Bolas wrote:
> On Wednesday, December 20, 2017 at 3:00:06 PM UTC-5, Andrey Semashev wrot=
e:
>=20
>     On 12/20/17 22:50, Nicol Bolas wrote:
>      > On Wednesday, December 20, 2017 at 2:19:34 PM UTC-5, Andrey
>     Semashev wrote:
>      >
>      > =C2=A0 =C2=A0 On 12/20/17 11:27, Thiago Macieira wrote:
>      > =C2=A0 =C2=A0 =C2=A0> On ter=C3=A7a-feira, 19 de dezembro de 2017 =
15:18:46 PST Andrey
>      >
>      > =C2=A0 =C2=A0 =C2=A0>> - What to do with the padding, especially w=
hen importing the
>      > =C2=A0 =C2=A0 UUID into
>      > =C2=A0 =C2=A0 =C2=A0>> std::uuid? The padding bits must not be par=
t of the UUID
>     value,
>      > =C2=A0 =C2=A0 so the
>      > =C2=A0 =C2=A0 =C2=A0>> bits bust be either masked or the conversio=
n should fail.
>     The
>      > =C2=A0 =C2=A0 latter I
>      > =C2=A0 =C2=A0 =C2=A0>> find unacceptable, because all the normal w=
orld expects this
>      > =C2=A0 =C2=A0 operation
>      > =C2=A0 =C2=A0 =C2=A0>> to never fail and be noexcept.
>      > =C2=A0 =C2=A0 =C2=A0>
>      > =C2=A0 =C2=A0 =C2=A0> If you consider the UUID as a char[16], I do=
n't see why that
>      > =C2=A0 =C2=A0 would be a
>      > =C2=A0 =C2=A0 =C2=A0> problem at all.
>      >
>      > =C2=A0 =C2=A0 That should be unsigned char[16]. The problem is tha=
t
>     unsigned char[16]
>      > =C2=A0 =C2=A0 does not represent a 128-bit value on a non-8-bit ma=
chine.
>     For example,
>      > =C2=A0 =C2=A0 two 144-bit "UUIDs" may not compare equal because of=
 the
>     padding bits.
>      > =C2=A0 =C2=A0 You have to define the meaning and behavior with reg=
ard to
>     the bits
>      > =C2=A0 =C2=A0 that
>      > =C2=A0 =C2=A0 are not part of the UUID value. That, in turn, may p=
enalize
>     8-bit
>      > =C2=A0 =C2=A0 machines.
>      >
>      > But there wouldn't be padding bits. If a byte is 9 bits, and you
>     set the
>      > value 128 in a 9-bit byte, the top bit is zero. That's not padding=
;
>      > that's how you encode 128 in 9 bits.
>=20
>     Yes, sorry, by "padding" I meant the additional significant bit.
>=20
>      > So the same would be here. An `std::byte[16]` would contain 16 9-b=
it
>      > bytes. The high byte of each one would be zero, since each byte on=
ly
>      > contains values on the range [0, 255].
>      >
>      > So two 144-bit "UUIDs" will compare equal if their sequence of 8-b=
it
>      > bytes are equal.
>=20
>     You will have to deal with the 9th bit when importing UUID from
>     `std::byte[16]` buffer. What if one of the bytes is 256, for example?
>     Should it be considered invalid input?
>=20
> Each byte of such a valid UUID buffer would be required to be on the=20
> range [0, 255]. That's all that needs to be said.

I was asking what if that is not the case. UB?

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/95c3a4d5-4bd0-facd-68f9-9fb09ddf47b8%40gmail.com=
..

.

--089e082ebcc4b2e0de0560cbab4a
Content-Type: text/plain; charset="UTF-8"

Andrey Semashev also wrote:
> If you put this uuid_default_generator in the standard you effectively
*require* the OS
> to provide this kind of utility. My point is that this requirement is
unreasonable and
> possibly not every OS that currently supports C++ qualifies.

This is not a problem. The C++11 standard requires std::random_device to
exist, and not every OS has /dev/urandom. (See
https://reviews.llvm.org/D41316 for a very recent manifestation of this
issue.)  Heck, not every OS has a *filesystem*, and we just got
std::filesystem into C++17!
The important thing is that the functionality be available under a shared
(standard) name. If the functionality is a bit truncated on certain rare
platforms, that's totally fine with me.

> I don't really see the point in having the generator as an object either.
This is one part
> of Boost.UUID design that I don't like. You really want a function, which
takes the RNG
> (in case of random generator) or name and hash function state (in case of
name generator)
> as arguments. It's these arguments that may need to be persistent across
multiple calls
> to the generation algorithm; the algorithm itself has no state.

I generally agree with Andrey here; but statelessness (or
near-statelessness) is not a rock-solid argument against objectness. I will
explain below that what we are looking for here is exactly a *distribution
object*, as defined in C++11.


On Tue, Dec 19, 2017 at 11:12 PM, Marius Bancila <marius.bancila@gmail.com>
wrote:

> We could approach the problem of generating uuids in a similar manner as
> done in boost::uuid. We could have generator like this one that uses a
> random number generator (and a uniform distribution) to produce uuids:
>
>
> template <typename UniformRandomNumberGenerator>
> class uuid_random_generator
> {
> public:
>   typedef uuid result_type;
>
>   uuid_random_generator();
>   explicit uuid_random_generator(UniformRandomNumberGenerator& gen);
>   explicit uuid_random_generator(UniformRandomNumberGenerator* pGen);
>
>   uuid operator()();
> };
>
>
If there is one thing we have learned from std::independent_bits_engine,
it's that ephemeral adaptor objects should not own their adaptees. (See
libc++'s internal __independent_bits_engine
<https://github.com/llvm-mirror/libcxx/blob/master/include/algorithm#L2936>,
which is exactly the same as independent_bits_engine except that it is
non-owning, because you need non-owningness in order to implement
uniform_int_distribution efficiently.)

So what you want here is a non-owning object whose operator() takes a
UniformRandomNumberGenerator& as an argument. And we have a name for that
in C++11; it's a *distribution*.

class uniform_uuid_distribution
{
public:
    using result_type = uuid;

    uniform_uuid_distribution() = default;
    template<class G> requires(UniformRandomBitGenerator<G>)
    uuid operator()(G& g) const;
};


I would propose a "default generator" one that may rely on the operating
> system uuid support, as make_uuid() does in my current proposal.
>
> class uuid_default_generator
> {
> public:
>   typedef uuid result_type;
>
>   uuid operator()();
> };
>
>
This seems unnecessary, at least in my formulation.



> Then, we could have two overloads for make_uuid() that would look like
> this:
>
> uuid make_uuid()
> {
>   return uuid_default_generator{}();
> }
>
> template <typename Generator>
> uuid make_uuid(Generator & g)
> {
>   return g();
> }
>
>
I'd say like this:

uuid make_uuid()
{ ...OS-specific... };

template<class G> requires(UniformRandomBitGenerator<G>)
uuid make_uuid(G& g)
{ return uniform_uuid_distribution()(g); }



> This would enable users to write their own generators, such as one that is
> based on name hashing, and use them with make_uuid.
>
> That would allow us to write code like the following:
>
> auto id1 = make_uuid();
>
> uuid_default_generator dgen;
> auto id2 = make_uuid(dgen);
> auto id3 = make_uuid(dgen);
>
> std::random_device rd;
> std::mt19937 mtgen(rd());
> uuid_random_generator<std::mt19937> rgen(mtgen);
> auto id4 = make_uuid(rgen);
> auto id5 = make_uuid(rgen);
>
>
If I have my own generator, say, rgen, why on earth would I want to write
make_uuid(rgen) when I could just write rgen()? You should introduce new
objects and classes only when they provide some useful functionality.
There's no point in having a function make_uuid(g) that invariably returns
g().

HTH,
Arthur

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0LiLyDuwSmZoWme%2Bm8%3D3azS%3DQHuLYPmgUDwg1W%3DbXnZYw%40mail.gmail.com.

--089e082ebcc4b2e0de0560cbab4a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Andrey Semashev also wrote:</div><div><span style=3D"=
font-size:13px">&gt; If you put this uuid_default_generator in the standard=
 you effectively *require* the OS</span></div><div><span style=3D"font-size=
:13px">&gt; to provide this kind of utility. My point is that this requirem=
ent is unreasonable and</span></div><div><span style=3D"font-size:13px">&gt=
; possibly not every OS that currently supports C++ qualifies.</span></div>=
<div><br></div><div>This is not a problem. The C++11 standard requires std:=
:random_device to exist, and not every OS has /dev/urandom. (See=C2=A0<a hr=
ef=3D"https://reviews.llvm.org/D41316">https://reviews.llvm.org/D41316</a> =
for a very recent manifestation of this issue.) =C2=A0Heck, not every OS ha=
s a <i>filesystem</i>, and we just got std::filesystem into C++17!</div><di=
v>The important thing is that the functionality be available under a shared=
 (standard) name. If the functionality is a bit truncated on certain rare p=
latforms, that&#39;s totally fine with me.<br><br style=3D"font-size:13px">=
<span style=3D"font-size:13px">&gt; I don&#39;t really see the point in hav=
ing the generator as an object either. This is one part</span></div><div><s=
pan style=3D"font-size:13px">&gt; of Boost.UUID design that I don&#39;t lik=
e. You really want a function, which takes the RNG</span></div><div><span s=
tyle=3D"font-size:13px">&gt; (in case of random generator) or name and hash=
 function state (in case of name generator)</span></div><div><span style=3D=
"font-size:13px">&gt; as arguments. It&#39;s these arguments that may need =
to be persistent across multiple calls</span></div><div><span style=3D"font=
-size:13px">&gt; to the generation algorithm; the algorithm itself has no s=
tate.<span class=3D"sewav33phzf6xwu"></span><span class=3D"sewmc6838bhqz82"=
></span></span><br></div><div><span style=3D"font-size:13px"><br></span></d=
iv><div><span style=3D"font-size:13px">I generally agree with Andrey here; =
but statelessness (or near-statelessness) is not a rock-solid argument agai=
nst objectness. I will explain below that what we are looking for here is e=
xactly a <i>distribution object</i>, as defined in C++11.</span></div><div>=
<span style=3D"font-size:13px"><br></span></div><div><br></div>On Tue, Dec =
19, 2017 at 11:12 PM, Marius Bancila <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:marius.bancila@gmail.com" target=3D"_blank">marius.bancila@gmail.com</a>&=
gt;</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:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">We could approach the probl=
em of generating uuids in a similar manner as done in boost::uuid. We could=
 have generator like this one that uses a random number generator (and a un=
iform distribution) to produce uuids:<div><blockquote style=3D"margin:0 0 0=
 40px;border:none;padding:0px"><div><br></div><div><div><font face=3D"monos=
pace, monospace">template &lt;typename UniformRandomNumberGenerator&gt;</fo=
nt></div></div><div><div><font face=3D"monospace, monospace">class uuid_ran=
dom_generator=C2=A0</font></div></div><div><div><font face=3D"monospace, mo=
nospace">{</font></div></div><div><div><font face=3D"monospace, monospace">=
public:</font></div></div><div><div><font face=3D"monospace, monospace">=C2=
=A0 typedef uuid result_type;</font></div></div><div><div><font face=3D"mon=
ospace, monospace"><br></font></div></div><div><div><font face=3D"monospace=
, monospace">=C2=A0 uuid_random_generator();</font></div></div><div><div><f=
ont face=3D"monospace, monospace">=C2=A0 explicit uuid_random_generator(<wb=
r>UniformRandomNumberGenerator&amp; gen);</font></div></div><div><div><font=
 face=3D"monospace, monospace">=C2=A0 explicit uuid_random_generator(<wbr>U=
niformRandomNumberGenerator* pGen);</font></div></div><div><div><font face=
=3D"monospace, monospace"><br></font></div></div><div><div><font face=3D"mo=
nospace, monospace">=C2=A0 uuid operator()();</font></div></div><div><div><=
font face=3D"monospace, monospace">};</font></div></div></blockquote></div>=
</div></blockquote><div><br></div><div>If there is one thing we have learne=
d from std::independent_bits_engine, it&#39;s that ephemeral adaptor object=
s should not own their adaptees. (See libc++&#39;s internal <a href=3D"http=
s://github.com/llvm-mirror/libcxx/blob/master/include/algorithm#L2936">__in=
dependent_bits_engine</a>, which is exactly the same as independent_bits_en=
gine except that it is non-owning, because you need non-owningness in order=
 to implement uniform_int_distribution efficiently.)</div><div><br></div><d=
iv>So what you want here is a non-owning object whose operator() takes a Un=
iformRandomNumberGenerator&amp; as an argument. And we have a name for that=
 in C++11; it&#39;s a <i>distribution</i>.</div><div><br></div><div><font f=
ace=3D"monospace, monospace">class uniform_uuid_distribution</font></div><d=
iv><font face=3D"monospace, monospace">{</font></div><div><font face=3D"mon=
ospace, monospace">public:</font></div><div><font face=3D"monospace, monosp=
ace">=C2=A0 =C2=A0 using result_type =3D uuid;</font></div><div><font face=
=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace, mo=
nospace">=C2=A0 =C2=A0 uniform_uuid_distribution() =3D default;</font></div=
><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 template&lt;class G=
&gt;</font><span style=3D"font-family:monospace,monospace">=C2=A0</span><sp=
an style=3D"font-family:monospace,monospace">requires(UniformRandomBitGener=
ator&lt;G&gt;)<span class=3D"sewav33phzf6xwu"></span><span class=3D"sewmc68=
38bhqz82"></span></span></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 uuid operator()(G&amp; g) const;</font></div><div><font face=3D"=
monospace, monospace">};</font></div><div><br></div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><div>I would propose a &quot;d=
efault generator&quot; one that may rely on the operating system uuid suppo=
rt, as make_uuid() does in my current proposal.</div><div><font face=3D"mon=
ospace, monospace"><br></font></div></div><blockquote style=3D"margin:0 0 0=
 40px;border:none;padding:0px"><div><div><div><font face=3D"monospace, mono=
space">class uuid_default_generator</font></div></div></div><div><div><div>=
<font face=3D"monospace, monospace">{</font></div></div></div><div><div><di=
v><font face=3D"monospace, monospace">public:</font></div></div></div><div>=
<div><div><font face=3D"monospace, monospace">=C2=A0 typedef uuid result_ty=
pe;</font></div></div></div><div><div><div><font face=3D"monospace, monospa=
ce"><br></font></div></div></div><div><div><div><font face=3D"monospace, mo=
nospace">=C2=A0 uuid operator()();</font></div></div></div><div><div><div><=
font face=3D"monospace, monospace">};</font></div></div></div></blockquote>=
</div></blockquote><div><br></div><div>This seems unnecessary, at least in =
my formulation.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><div></div><div>Then, we could have two over=
loads for make_uuid() that would look like this:</div><div><font face=3D"mo=
nospace, monospace"><br></font></div></div><blockquote style=3D"margin:0 0 =
0 40px;border:none;padding:0px"><div><div><div><font face=3D"monospace, mon=
ospace">uuid make_uuid()</font></div></div></div><div><div><div><font face=
=3D"monospace, monospace">{</font></div></div></div><div><div><div><font fa=
ce=3D"monospace, monospace">=C2=A0 return uuid_default_generator{}();</font=
></div></div></div><div><div><div><font face=3D"monospace, monospace">}</fo=
nt></div></div></div><div><div><div><font face=3D"monospace, monospace"><br=
></font></div></div></div><div><div><div><font face=3D"monospace, monospace=
">template &lt;typename Generator&gt;</font></div></div></div><div><div><di=
v><font face=3D"monospace, monospace">uuid make_uuid(Generator &amp; g)=C2=
=A0</font></div></div></div><div><div><div><font face=3D"monospace, monospa=
ce">{</font></div></div></div><div><div><div><font face=3D"monospace, monos=
pace">=C2=A0 return g();</font></div></div></div><div><div><div><font face=
=3D"monospace, monospace">}</font></div></div></div></blockquote></div></bl=
ockquote><div><br></div><div>I&#39;d say like this:</div><div><br></div><di=
v><font face=3D"monospace, monospace">uuid make_uuid()</font></div><div><sp=
an style=3D"font-family:monospace,monospace">{ ...OS-specific... };</span><=
/div><div><font face=3D"monospace, monospace"><br></font></div><div><font f=
ace=3D"monospace, monospace">template&lt;class G&gt;</font><span style=3D"f=
ont-family:monospace,monospace">=C2=A0</span><span style=3D"font-family:mon=
ospace,monospace">requires(UniformRandomBitGenerator&lt;G&gt;)<span class=
=3D"sewav33phzf6xwu"></span><span class=3D"sewmc6838bhqz82"></span></span><=
/div><div><font face=3D"monospace, monospace">uuid make_uuid(G&amp; g)</fon=
t></div><div><font face=3D"monospace, monospace">{ return uniform_uuid_dist=
ribution()(g); }</font></div><div><br></div><div>=C2=A0<br></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><div></div><div>This would enabl=
e users to write their own generators, such as one that is based on name ha=
shing, and use them with make_uuid.</div><div><br></div><div>That would all=
ow us to write code like the following:</div><div><br></div></div><blockquo=
te style=3D"margin:0 0 0 40px;border:none;padding:0px"><div><div><div><font=
 face=3D"monospace, monospace">auto id1 =3D make_uuid();</font></div></div>=
</div><div><div><div><font face=3D"monospace, monospace"><br></font></div><=
/div></div><div><div><div><font face=3D"monospace, monospace">uuid_default_=
generator dgen;</font></div></div></div><div><div><div><font face=3D"monosp=
ace, monospace">auto id2 =3D make_uuid(dgen);</font></div></div></div><div>=
<div><div><font face=3D"monospace, monospace">auto id3 =3D make_uuid(dgen);=
</font></div></div></div><div><div><div><font face=3D"monospace, monospace"=
><br></font></div></div></div><div><div><div><font face=3D"monospace, monos=
pace">std::random_device rd;</font></div></div></div><div><div><div><font f=
ace=3D"monospace, monospace">std::mt19937 mtgen(rd());</font></div></div></=
div><div><div><div><font face=3D"monospace, monospace">uuid_random_generato=
r&lt;std::<wbr>mt19937&gt; rgen(mtgen);</font></div></div></div><div><div><=
div><font face=3D"monospace, monospace">auto id4 =3D make_uuid(rgen);</font=
></div></div></div><div><div><div><font face=3D"monospace, monospace">auto =
id5 =3D make_uuid(rgen);</font></div></div></div></blockquote></div></block=
quote><div><br></div><div>If I have my own generator, say, <font face=3D"mo=
nospace, monospace">rgen</font>, why on earth would I want to write <font f=
ace=3D"monospace, monospace">make_uuid(rgen)</font> when I could just write=
 <font face=3D"monospace, monospace">rgen()</font>? You should introduce ne=
w objects and classes only when they provide some useful functionality. The=
re&#39;s no point in having a function <font face=3D"monospace, monospace">=
make_uuid(g)</font> that invariably returns <font face=3D"monospace, monosp=
ace">g()</font>.</div><div><br></div><div>HTH,</div><div>Arthur</div></div>=
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0LiLyDuwSmZoWme%2Bm8%3D3azS%3DQ=
HuLYPmgUDwg1W%3DbXnZYw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Li=
LyDuwSmZoWme%2Bm8%3D3azS%3DQHuLYPmgUDwg1W%3DbXnZYw%40mail.gmail.com</a>.<br=
 />

--089e082ebcc4b2e0de0560cbab4a--

.

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

Knock it off, you three. Or at least take it to private email.

On Wed, Dec 20, 2017 at 12:19 PM, Andrey Semashev <andrey.semashev@gmail.co=
m
> wrote:

> On 12/20/17 23:14, Nicol Bolas wrote:
>
>> On Wednesday, December 20, 2017 at 3:00:06 PM UTC-5, Andrey Semashev
>> wrote:
>>
>>     On 12/20/17 22:50, Nicol Bolas wrote:
>>      > On Wednesday, December 20, 2017 at 2:19:34 PM UTC-5, Andrey
>>     Semashev wrote:
>>      >
>>      >     On 12/20/17 11:27, Thiago Macieira wrote:
>>      >      > On ter=C3=A7a-feira, 19 de dezembro de 2017 15:18:46 PST A=
ndrey
>>      >
>>      >      >> - What to do with the padding, especially when importing
>> the
>>      >     UUID into
>>      >      >> std::uuid? The padding bits must not be part of the UUID
>>     value,
>>      >     so the
>>      >      >> bits bust be either masked or the conversion should fail.
>>     The
>>      >     latter I
>>      >      >> find unacceptable, because all the normal world expects
>> this
>>      >     operation
>>      >      >> to never fail and be noexcept.
>>      >      >
>>      >      > If you consider the UUID as a char[16], I don't see why th=
at
>>      >     would be a
>>      >      > problem at all.
>>      >
>>      >     That should be unsigned char[16]. The problem is that
>>     unsigned char[16]
>>      >     does not represent a 128-bit value on a non-8-bit machine.
>>     For example,
>>      >     two 144-bit "UUIDs" may not compare equal because of the
>>     padding bits.
>>      >     You have to define the meaning and behavior with regard to
>>     the bits
>>      >     that
>>      >     are not part of the UUID value. That, in turn, may penalize
>>     8-bit
>>      >     machines.
>>      >
>>      > But there wouldn't be padding bits. If a byte is 9 bits, and you
>>     set the
>>      > value 128 in a 9-bit byte, the top bit is zero. That's not paddin=
g;
>>      > that's how you encode 128 in 9 bits.
>>
>>     Yes, sorry, by "padding" I meant the additional significant bit.
>>
>>      > So the same would be here. An `std::byte[16]` would contain 16
>> 9-bit
>>      > bytes. The high byte of each one would be zero, since each byte
>> only
>>      > contains values on the range [0, 255].
>>      >
>>      > So two 144-bit "UUIDs" will compare equal if their sequence of
>> 8-bit
>>      > bytes are equal.
>>
>>     You will have to deal with the 9th bit when importing UUID from
>>     `std::byte[16]` buffer. What if one of the bytes is 256, for example=
?
>>     Should it be considered invalid input?
>>
>> Each byte of such a valid UUID buffer would be required to be on the
>> range [0, 255]. That's all that needs to be said.
>>
>
> I was asking what if that is not the case. UB?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/is
> ocpp.org/d/topic/std-proposals/NjVdCCf0tlk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/95c3a4d5-4bd0-facd-68f9-
> 9fb09ddf47b8%40gmail.com.
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0%2BBOTx-%2BgvpJfkdUNqH_U%2BrK7w-1eEQhs8CW=
RUPAy-Niw%40mail.gmail.com.

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

<div dir=3D"ltr">Knock it off, you three. Or at least take it to private em=
ail.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed,=
 Dec 20, 2017 at 12:19 PM, Andrey Semashev <span dir=3D"ltr">&lt;<a href=3D=
"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gmail.=
com</a>&gt;</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 class=3D"H=
OEnZb"><div class=3D"h5">On 12/20/17 23:14, Nicol Bolas wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Wednesday, December 20, 2017 at 3:00:06 PM UTC-5, Andrey Semashev wrote:=
<br>
<br>
=C2=A0 =C2=A0 On 12/20/17 22:50, Nicol Bolas wrote:<br>
=C2=A0 =C2=A0 =C2=A0&gt; On Wednesday, December 20, 2017 at 2:19:34 PM UTC-=
5, Andrey<br>
=C2=A0 =C2=A0 Semashev wrote:<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 On 12/20/17 11:27, Thiago Macieira w=
rote:<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 =C2=A0&gt; On ter=C3=A7a-feira, 19 d=
e dezembro de 2017 15:18:46 PST Andrey<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; - What to do with the=
 padding, especially when importing the<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 UUID into<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; std::uuid? The paddin=
g bits must not be part of the UUID<br>
=C2=A0 =C2=A0 value,<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 so the<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; bits bust be either m=
asked or the conversion should fail.<br>
=C2=A0 =C2=A0 The<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 latter I<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; find unacceptable, be=
cause all the normal world expects this<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 operation<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 =C2=A0&gt;&gt; to never fail and be =
noexcept.<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 =C2=A0&gt; If you consider the UUID =
as a char[16], I don&#39;t see why that<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 would be a<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 =C2=A0&gt; problem at all.<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 That should be unsigned char[16]. Th=
e problem is that<br>
=C2=A0 =C2=A0 unsigned char[16]<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 does not represent a 128-bit value o=
n a non-8-bit machine.<br>
=C2=A0 =C2=A0 For example,<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 two 144-bit &quot;UUIDs&quot; may no=
t compare equal because of the<br>
=C2=A0 =C2=A0 padding bits.<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 You have to define the meaning and b=
ehavior with regard to<br>
=C2=A0 =C2=A0 the bits<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 that<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 are not part of the UUID value. That=
, in turn, may penalize<br>
=C2=A0 =C2=A0 8-bit<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 machines.<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 =C2=A0&gt; But there wouldn&#39;t be padding bits. If a byte =
is 9 bits, and you<br>
=C2=A0 =C2=A0 set the<br>
=C2=A0 =C2=A0 =C2=A0&gt; value 128 in a 9-bit byte, the top bit is zero. Th=
at&#39;s not padding;<br>
=C2=A0 =C2=A0 =C2=A0&gt; that&#39;s how you encode 128 in 9 bits.<br>
<br>
=C2=A0 =C2=A0 Yes, sorry, by &quot;padding&quot; I meant the additional sig=
nificant bit.<br>
<br>
=C2=A0 =C2=A0 =C2=A0&gt; So the same would be here. An `std::byte[16]` woul=
d contain 16 9-bit<br>
=C2=A0 =C2=A0 =C2=A0&gt; bytes. The high byte of each one would be zero, si=
nce each byte only<br>
=C2=A0 =C2=A0 =C2=A0&gt; contains values on the range [0, 255].<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 =C2=A0&gt; So two 144-bit &quot;UUIDs&quot; will compare equa=
l if their sequence of 8-bit<br>
=C2=A0 =C2=A0 =C2=A0&gt; bytes are equal.<br>
<br>
=C2=A0 =C2=A0 You will have to deal with the 9th bit when importing UUID fr=
om<br>
=C2=A0 =C2=A0 `std::byte[16]` buffer. What if one of the bytes is 256, for =
example?<br>
=C2=A0 =C2=A0 Should it be considered invalid input?<br>
<br>
Each byte of such a valid UUID buffer would be required to be on the range =
[0, 255]. That&#39;s all that needs to be said.<br>
</blockquote>
<br></div></div>
I was asking what if that is not the case. UB?<span class=3D""><br>
<br>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/NjVdCCf0tlk/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/s=
td-proposals<wbr>/NjVdCCf0tlk/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isoc<wbr>pp.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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/95c3a4d5-4bd0-facd-68f9-9fb09ddf47b8%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/95c3a4d5-4bd0-facd-68f9-<wbr>=
9fb09ddf47b8%40gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BBOTx-%2BgvpJfkdUNqH_U%2BrK7=
w-1eEQhs8CWRUPAy-Niw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BB=
OTx-%2BgvpJfkdUNqH_U%2BrK7w-1eEQhs8CWRUPAy-Niw%40mail.gmail.com</a>.<br />

--f403045c28b8f6af060560cbad8b--

.

On quarta-feira, 20 de dezembro de 2017 12:56:10 CST Andrey Semashev wrote:
> I don't really see the point in having the generator as an object
> either. This is one part of Boost.UUID design that I don't like. You
> really want a function, which takes the RNG (in case of random
> generator) or name and hash function state (in case of name generator)
> as arguments. It's these arguments that may need to be persistent across
> multiple calls to the generation algorithm; the algorithm itself has no
> state.

Actually, no. you want ONLY an MD5 or SHA-1 generator and no state. That's
what RFC 4122 says you should use.

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

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

.

On quarta-feira, 20 de dezembro de 2017 14:19:48 CST Andrey Semashev wrote:
> > Each byte of such a valid UUID buffer would be required to be on the
> > range [0, 255]. That's all that needs to be said.
>
> I was asking what if that is not the case. UB?

Precondition violation. Apply GIGO.

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

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

.

On 12/21/17 04:56, Thiago Macieira wrote:
> On quarta-feira, 20 de dezembro de 2017 12:56:10 CST Andrey Semashev wrote:
>> I don't really see the point in having the generator as an object
>> either. This is one part of Boost.UUID design that I don't like. You
>> really want a function, which takes the RNG (in case of random
>> generator) or name and hash function state (in case of name generator)
>> as arguments. It's these arguments that may need to be persistent across
>> multiple calls to the generation algorithm; the algorithm itself has no
>> state.
>
> Actually, no. you want ONLY an MD5 or SHA-1 generator and no state. That's
> what RFC 4122 says you should use.

There's reason to believe that a new RFC comes out that will have a
stronger hash function for name UUIDs. The UUID generation algorithm
should allow for that extension, even if done by user.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/887b341d-753d-928f-2e04-e387977750f4%40gmail.com.

.

On 12/21/17 05:00, Thiago Macieira wrote:
> On quarta-feira, 20 de dezembro de 2017 14:19:48 CST Andrey Semashev wrote:
>>> Each byte of such a valid UUID buffer would be required to be on the
>>> range [0, 255]. That's all that needs to be said.
>>
>> I was asking what if that is not the case. UB?
>
> Precondition violation. Apply GIGO.

Ok, I guess that makes sense and doesn't penalise conventional platforms.

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

.

On quinta-feira, 21 de dezembro de 2017 06:08:29 -02 Andrey Semashev wrote:
> On 12/21/17 04:56, Thiago Macieira wrote:
> > On quarta-feira, 20 de dezembro de 2017 12:56:10 CST Andrey Semashev
wrote:
> >> I don't really see the point in having the generator as an object
> >> either. This is one part of Boost.UUID design that I don't like. You
> >> really want a function, which takes the RNG (in case of random
> >> generator) or name and hash function state (in case of name generator)
> >> as arguments. It's these arguments that may need to be persistent across
> >> multiple calls to the generation algorithm; the algorithm itself has no
> >> state.
> >
> > Actually, no. you want ONLY an MD5 or SHA-1 generator and no state. That's
> > what RFC 4122 says you should use.
>
> There's reason to believe that a new RFC comes out that will have a
> stronger hash function for name UUIDs. The UUID generation algorithm
> should allow for that extension, even if done by user.

Fair enough, but the library should make it easy to follow existing practice.

Making it so that the user has to jump through hoops to get the expected
behaviour only because some RFC in the future may add another hash function is
just bad design.

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

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

.

--001a1141fb80f02426056359cdd1
Content-Type: text/plain; charset="UTF-8"

After winter vacation and further thinking I have made changes to the
library proposal based on the feedback I got from here (although it's hard
to satisfy all opinions).

Here is a list of changes:

   - iterators are no longer defined as pointers; the proposal states that
   the internal representation may not be an array and may have arbitrary
   endianness.
   - conversion functions *string()* and *wstring()* have been removed;
   non-member functions *to_string()* and *to_wstring()* have been added
   instead
   - *make_guid()* functions have been removed; generator function objects
   have been added to create version 4 (random number-based) and 5 (name-based
   with SHA1 hashing) UUIDs.

Again, the link to the project is https://github.com/mariusbancila/stduuid,
and to the proposal:
https://github.com/mariusbancila/stduuid/blob/master/paper.md.

Thank you

On Thu, Dec 21, 2017 at 2:33 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On quinta-feira, 21 de dezembro de 2017 06:08:29 -02 Andrey Semashev wrote:
> > On 12/21/17 04:56, Thiago Macieira wrote:
> > > On quarta-feira, 20 de dezembro de 2017 12:56:10 CST Andrey Semashev
> wrote:
> > >> I don't really see the point in having the generator as an object
> > >> either. This is one part of Boost.UUID design that I don't like. You
> > >> really want a function, which takes the RNG (in case of random
> > >> generator) or name and hash function state (in case of name generator)
> > >> as arguments. It's these arguments that may need to be persistent
> across
> > >> multiple calls to the generation algorithm; the algorithm itself has
> no
> > >> state.
> > >
> > > Actually, no. you want ONLY an MD5 or SHA-1 generator and no state.
> That's
> > > what RFC 4122 says you should use.
> >
> > There's reason to believe that a new RFC comes out that will have a
> > stronger hash function for name UUIDs. The UUID generation algorithm
> > should allow for that extension, even if done by user.
>
> Fair enough, but the library should make it easy to follow existing
> practice.
>
> Making it so that the user has to jump through hoops to get the expected
> behaviour only because some RFC in the future may add another hash
> function is
> just bad design.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/2248745.fYPvmxbhEj%40tjmaciei-mobl1.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASzy2bwCr1-6N2URPLF14hgjJUr5gEbUSsoC9gddzVP%2BhA%40mail.gmail.com.

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

<div dir=3D"ltr">After winter vacation and further thinking I have made cha=
nges to the library proposal based on the feedback I got from here (althoug=
h it&#39;s hard to satisfy all opinions).<div><br></div><div>Here is a list=
 of changes:</div><div><ul><li>iterators are no longer defined as pointers;=
 the proposal states that the internal representation may not be an array a=
nd may have arbitrary endianness.</li><li>conversion functions <i>string()<=
/i> and <i>wstring()</i> have been removed; non-member functions <i>to_stri=
ng()</i> and <i>to_wstring()</i> have been added instead</li><li><i>make_gu=
id()</i> functions have been removed; generator function objects have been =
added to create version 4 (random number-based) and 5 (name-based with SHA1=
 hashing) UUIDs.</li></ul><div>Again, the link to the project is=C2=A0<a hr=
ef=3D"https://github.com/mariusbancila/stduuid">https://github.com/mariusba=
ncila/stduuid</a>, and to the proposal:=C2=A0<a href=3D"https://github.com/=
mariusbancila/stduuid/blob/master/paper.md">https://github.com/mariusbancil=
a/stduuid/blob/master/paper.md</a>.</div></div><div><br></div><div>Thank yo=
u</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On T=
hu, Dec 21, 2017 at 2:33 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</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"><span class=3D"">On quin=
ta-feira, 21 de dezembro de 2017 06:08:29 -02 Andrey Semashev wrote:<br>
&gt; On 12/21/17 04:56, Thiago Macieira wrote:<br>
&gt; &gt; On quarta-feira, 20 de dezembro de 2017 12:56:10 CST Andrey Semas=
hev<br>
wrote:<br>
&gt; &gt;&gt; I don&#39;t really see the point in having the generator as a=
n object<br>
&gt; &gt;&gt; either. This is one part of Boost.UUID design that I don&#39;=
t like. You<br>
&gt; &gt;&gt; really want a function, which takes the RNG (in case of rando=
m<br>
&gt; &gt;&gt; generator) or name and hash function state (in case of name g=
enerator)<br>
&gt; &gt;&gt; as arguments. It&#39;s these arguments that may need to be pe=
rsistent across<br>
&gt; &gt;&gt; multiple calls to the generation algorithm; the algorithm its=
elf has no<br>
&gt; &gt;&gt; state.<br>
&gt; &gt;<br>
&gt; &gt; Actually, no. you want ONLY an MD5 or SHA-1 generator and no stat=
e. That&#39;s<br>
&gt; &gt; what RFC 4122 says you should use.<br>
&gt;<br>
&gt; There&#39;s reason to believe that a new RFC comes out that will have =
a<br>
&gt; stronger hash function for name UUIDs. The UUID generation algorithm<b=
r>
&gt; should allow for that extension, even if done by user.<br>
<br>
</span>Fair enough, but the library should make it easy to follow existing =
practice.<br>
<br>
Making it so that the user has to jump through hoops to get the expected<br=
>
behaviour only because some RFC in the future may add another hash function=
 is<br>
just bad design.<br>
<span class=3D""><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</span><span class=3D"">--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/2248745.fYPvmxbhEj%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/2248745.fYPvmxbhEj%<wbr>40tjmaciei-=
mobl1</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASzy2bwCr1-6N2URPLF14hgjJUr5gE=
bUSsoC9gddzVP%2BhA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASzy2b=
wCr1-6N2URPLF14hgjJUr5gEbUSsoC9gddzVP%2BhA%40mail.gmail.com</a>.<br />

--001a1141fb80f02426056359cdd1--

.

--089e082c2428c12d0d05635cd69a
Content-Type: text/plain; charset="UTF-8"

The std::hash function involves the abomination that is std::stringstream.
Surely there's a better way?
Since these UUIDs are supposed to be unique perhaps you could use part of
the 16 byte array as a hash?

On Mon, Jan 22, 2018 at 9:10 AM, Marius Bancila <marius.bancila@gmail.com>
wrote:

> After winter vacation and further thinking I have made changes to the
> library proposal based on the feedback I got from here (although it's hard
> to satisfy all opinions).
>
> Here is a list of changes:
>
>    - iterators are no longer defined as pointers; the proposal states
>    that the internal representation may not be an array and may have arbitrary
>    endianness.
>    - conversion functions *string()* and *wstring()* have been removed;
>    non-member functions *to_string()* and *to_wstring()* have been added
>    instead
>    - *make_guid()* functions have been removed; generator function
>    objects have been added to create version 4 (random number-based) and 5
>    (name-based with SHA1 hashing) UUIDs.
>
> Again, the link to the project is https://github.com/mariusbancila/stduuid,
> and to the proposal: https://github.com/mariusbancila/stduuid/blob/
> master/paper.md.
>
> Thank you
>
> On Thu, Dec 21, 2017 at 2:33 PM, Thiago Macieira <thiago@macieira.org>
> wrote:
>
>> On quinta-feira, 21 de dezembro de 2017 06:08:29 -02 Andrey Semashev
>> wrote:
>> > On 12/21/17 04:56, Thiago Macieira wrote:
>> > > On quarta-feira, 20 de dezembro de 2017 12:56:10 CST Andrey Semashev
>> wrote:
>> > >> I don't really see the point in having the generator as an object
>> > >> either. This is one part of Boost.UUID design that I don't like. You
>> > >> really want a function, which takes the RNG (in case of random
>> > >> generator) or name and hash function state (in case of name
>> generator)
>> > >> as arguments. It's these arguments that may need to be persistent
>> across
>> > >> multiple calls to the generation algorithm; the algorithm itself has
>> no
>> > >> state.
>> > >
>> > > Actually, no. you want ONLY an MD5 or SHA-1 generator and no state.
>> That's
>> > > what RFC 4122 says you should use.
>> >
>> > There's reason to believe that a new RFC comes out that will have a
>> > stronger hash function for name UUIDs. The UUID generation algorithm
>> > should allow for that extension, even if done by user.
>>
>> Fair enough, but the library should make it easy to follow existing
>> practice.
>>
>> Making it so that the user has to jump through hoops to get the expected
>> behaviour only because some RFC in the future may add another hash
>> function is
>> just bad design.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>    Software Architect - Intel Open Source Technology Center
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/2248745.fYPvmxbhEj%40tjmaciei-mobl1.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CA%2BgtASzy2bwCr1-
> 6N2URPLF14hgjJUr5gEbUSsoC9gddzVP%2BhA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASzy2bwCr1-6N2URPLF14hgjJUr5gEbUSsoC9gddzVP%2BhA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

--089e082c2428c12d0d05635cd69a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>The std::hash function involves the abomination that =
is std::stringstream. Surely there&#39;s a better way?</div><div>Since thes=
e UUIDs are supposed to be unique perhaps you could use part of the 16 byte=
 array as a hash?</div></div><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Mon, Jan 22, 2018 at 9:10 AM, Marius Bancila <span dir=3D"lt=
r">&lt;<a href=3D"mailto:marius.bancila@gmail.com" target=3D"_blank">marius=
..bancila@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr">After winter vacation and further thinking I have made cha=
nges to the library proposal based on the feedback I got from here (althoug=
h it&#39;s hard to satisfy all opinions).<div><br></div><div>Here is a list=
 of changes:</div><div><ul><li>iterators are no longer defined as pointers;=
 the proposal states that the internal representation may not be an array a=
nd may have arbitrary endianness.</li><li>conversion functions <i>string()<=
/i> and <i>wstring()</i> have been removed; non-member functions <i>to_stri=
ng()</i> and <i>to_wstring()</i> have been added instead</li><li><i>make_gu=
id()</i> functions have been removed; generator function objects have been =
added to create version 4 (random number-based) and 5 (name-based with SHA1=
 hashing) UUIDs.</li></ul><div>Again, the link to the project is=C2=A0<a hr=
ef=3D"https://github.com/mariusbancila/stduuid" target=3D"_blank">https://g=
ithub.com/<wbr>mariusbancila/stduuid</a>, and to the proposal:=C2=A0<a href=
=3D"https://github.com/mariusbancila/stduuid/blob/master/paper.md" target=
=3D"_blank">https://github.com/<wbr>mariusbancila/stduuid/blob/<wbr>master/=
paper.md</a>.</div></div><div><br></div><div>Thank you</div></div><div><div=
 class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Thu, Dec 21, 2017 at 2:33 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</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"><span>On quinta-feira, 2=
1 de dezembro de 2017 06:08:29 -02 Andrey Semashev wrote:<br>
&gt; On 12/21/17 04:56, Thiago Macieira wrote:<br>
&gt; &gt; On quarta-feira, 20 de dezembro de 2017 12:56:10 CST Andrey Semas=
hev<br>
wrote:<br>
&gt; &gt;&gt; I don&#39;t really see the point in having the generator as a=
n object<br>
&gt; &gt;&gt; either. This is one part of Boost.UUID design that I don&#39;=
t like. You<br>
&gt; &gt;&gt; really want a function, which takes the RNG (in case of rando=
m<br>
&gt; &gt;&gt; generator) or name and hash function state (in case of name g=
enerator)<br>
&gt; &gt;&gt; as arguments. It&#39;s these arguments that may need to be pe=
rsistent across<br>
&gt; &gt;&gt; multiple calls to the generation algorithm; the algorithm its=
elf has no<br>
&gt; &gt;&gt; state.<br>
&gt; &gt;<br>
&gt; &gt; Actually, no. you want ONLY an MD5 or SHA-1 generator and no stat=
e. That&#39;s<br>
&gt; &gt; what RFC 4122 says you should use.<br>
&gt;<br>
&gt; There&#39;s reason to believe that a new RFC comes out that will have =
a<br>
&gt; stronger hash function for name UUIDs. The UUID generation algorithm<b=
r>
&gt; should allow for that extension, even if done by user.<br>
<br>
</span>Fair enough, but the library should make it easy to follow existing =
practice.<br>
<br>
Making it so that the user has to jump through hoops to get the expected<br=
>
behaviour only because some RFC in the future may add another hash function=
 is<br>
just bad design.<br>
<span><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank" rel=3D"noreferrer">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" target=3D"_blank" rel=3D"noreferrer">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</span><span>--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/2248745.fYPvmxbhEj%40tjmaciei-=
mobl1" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/is<=
wbr>ocpp.org/d/msgid/std-proposals<wbr>/2248745.fYPvmxbhEj%40tjmaciei<wbr>-=
mobl1</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASzy2bwCr1-6N2URPLF14hgjJUr5gE=
bUSsoC9gddzVP%2BhA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CA%2BgtASzy2bwCr1-<wbr>6N2URPLF14hgjJUr5gEbUSsoC9gddz<wb=
r>VP%2BhA%40mail.gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAcQMaJXUpyYE1xw1BmNkUPb5CRrimp=
YLfJbOgiiTj%3D-g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAcQMaJXU=
pyYE1xw1BmNkUPb5CRrimpYLfJbOgiiTj%3D-g%40mail.gmail.com</a>.<br />

--089e082c2428c12d0d05635cd69a--

.

------=_Part_5922_729067100.1516639147037
Content-Type: multipart/alternative;
 boundary="----=_Part_5923_2027047483.1516639147037"

------=_Part_5923_2027047483.1516639147037
Content-Type: text/plain; charset="UTF-8"

- Why do you have two swap functions inside `std::uuid`? Isn't that a bit
redundant, and/or can lead to an ambiguous call?
- There is no mention of *string* or *wstring* in the TS. Is this intended?

What are *uuid_iterator* and *uuid_const_iterator*? They are accessible to
everyone you know, because the default access specifier of struct is
public. You probably meant for them to be implementation defined, in that
case, what the standard normally does is something like:

    typedef /*implementation-defined*/ iterator; // see [uuid]
    using const_iterator = implementation-defined; // see [uuid]

- What do you think of marking every function constexpr? I don't know if
this is going to be tricky to implement, but it seems like the standard
library starts to go in the direction of making a lot of things constexpr.


>    - conversion functions *string()* and *wstring()* have been removed;
>    non-member functions *to_string()* and *to_wstring()* have been added
>    instead
>
> You still call *string* and *wstring* in the example under "String
Conversion".

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

------=_Part_5923_2027047483.1516639147037
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>- Why do you have two swap functions inside `std::uui=
d`? Isn&#39;t that a bit redundant, and/or can lead to an ambiguous call?</=
div><div>- There is no mention of <i>string</i>=C2=A0or <i>wstring</i>=C2=
=A0in the TS. Is this intended?</div><div><br></div><div>What are=C2=A0<i>u=
uid_iterator</i>=C2=A0and <i>uuid_const_iterator</i>? They are accessible t=
o everyone you know, because the default access specifier of struct is publ=
ic. You probably meant for them to be implementation defined, in that case,=
 what the standard normally does is something like:</div><div><br></div><di=
v>=C2=A0 =C2=A0 typedef /*implementation-defined*/ iterator; // see [uuid]<=
/div><div>=C2=A0 =C2=A0 using const_iterator =3D implementation-defined; //=
 see [uuid]</div><div><br></div><div>- What do you think of marking every f=
unction constexpr? I don&#39;t know if this is going to be tricky to implem=
ent, but it seems like the standard library starts to go in the direction o=
f making a lot of things constexpr.</div><div><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><ul><li>conversion functi=
ons <i>string()</i> and <i>wstring()</i> have been removed; non-member func=
tions <i>to_string()</i> and <i>to_wstring()</i> have been added instead</l=
i></ul></div></div></blockquote><div>You still call <i>string</i>=C2=A0and =
<i>wstring</i>=C2=A0in the example under &quot;String Conversion&quot;.=C2=
=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/515e06cc-7caf-4a3c-a8b4-638b6ff80faf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/515e06cc-7caf-4a3c-a8b4-638b6ff80faf=
%40isocpp.org</a>.<br />

------=_Part_5923_2027047483.1516639147037--

------=_Part_5922_729067100.1516639147037--

.

On 01/22/18 12:10, Marius Bancila wrote:
> After winter vacation and further thinking I have made changes to the
> library proposal based on the feedback I got from here (although it's
> hard to satisfy all opinions).
>
> Here is a list of changes:
>
>   * iterators are no longer defined as pointers; the proposal states
>     that the internal representation may not be an array and may have
>     arbitrary endianness.
>   * conversion functions /string()/ and /wstring()/ have been removed;
>     non-member functions /to_string()/ and /to_wstring()/ have been
>     added instead
>   * /make_guid()/ functions have been removed; generator function
>     objects have been added to create version 4 (random number-based)
>     and 5 (name-based with SHA1 hashing) UUIDs.
>
> Again, the link to the project is
> https://github.com/mariusbancila/stduuid, and to the proposal:
> https://github.com/mariusbancila/stduuid/blob/master/paper.md.

Looks much better now. A few comments on the proposal:

- I still think that constructors from strings is a mistake, but you
seem to prefer them to separate functions. Fair enough.

- I believe, `swap` should be overloaded, not specialized.

- The section "Iterators constructors" lists two examples, neither of
which uses iterators to construct UUID.

- The "Capacity" section should probably be named "Size" since you
describe the `size` method there. Also, `nil` has nothing to do with
size, and its description is better moved elsewhere.

- The example in the "String conversion" section still uses member
functions `string` and `wstring`. Also, I still don't see the point in
`to_wstring`.

- In the "Generating new uuids" section, why is `uuid_name_generator`
initialized with an UUID? How do you use that generator with another
hash function?

On the "Technical Specifications" section:

- Why is `uuid_variant::future` needed?

- `uuid::uuid_const_iterator` and `uuid::uuid_iterator` don't need to be
in the specification. The type of the iterators can simply be specified
as implementation-defined.

- I think `uuid_default_generator` still has to provide some guarantees
on the produced UUIDs. Having a generator that produces noone knows what
is hardly useful. I assume it is supposed to produce random UUIDs using
some system-specific source of randomness, so why not say that? Also, if
it is a random generator, its name should reflect that.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c339d417-cbf8-9a40-3d53-1ef4f8bd4f8a%40gmail.com.

.

--f403045c26b207b5aa0563612101
Content-Type: text/plain; charset="UTF-8"

On Mon, Jan 22, 2018 at 9:23 AM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On 01/22/18 12:10, Marius Bancila wrote:
>
>>
>> Again, the link to the project is https://github.com/mariusbanci
>> la/stduuid, and to the proposal: https://github.com/mariusbanci
>> la/stduuid/blob/master/paper.md.
>>
>
> - I believe, `swap` should be overloaded, not specialized.
>

Nicolas Lesser also observed that `swap` was funky.
Marius, here's what you currently have:

    // BAD
    namespace my {
        struct X {
            void swap(X&);  // member swap
            friend void swap(X&, X&);  // Barton-Nackman trick provides ADL
swap
        };
    }
    namespace std {
        template<> void swap(my::X&, my::X&);  // bogus "specialization" of
a function template not in your namespace
    }

And here is what you should have:

    // GOOD
    namespace my {
        struct X {
            void swap(X&);  // member swap
        };
        inline void swap(X&, X&);  // ADL swap
    }

Your specialization for std::hash is correct; std::hash is a customization
point that operates by template specialization.
But std::swap is not a customization point. The way you provide `swap` for
your type is via ADL, not via template specialization of std::swap.
(std::swap actually has tons of overloads, many of which are templates;
providing a "template specialization" for an overloaded function is bad
times.)

It would be acceptable to continue using the Barton-Nackman trick, too.
I.e., this is also acceptable:

    // GOOD
    namespace my {
        struct X {
            void swap(X&);  // member swap
            friend void swap(X&, X&);  // Barton-Nackman trick provides ADL
swap
        };
    }

But standard library types do not use the Barton-Nackman trick, and so I
recommend that you don't use it either, in things targeting the standard
library.


Speaking of std::hash, it might be preferable to write
    using result_type = std::hash<std::string>::result_type;
and eliminate the static_cast in operator()().


- I think `uuid_default_generator` still has to provide some guarantees on
> the produced UUIDs. Having a generator that produces noone knows what is
> hardly useful. I assume it is supposed to produce random UUIDs using some
> system-specific source of randomness, so why not say that? Also, if it is a
> random generator, its name should reflect that.


Yes. Please never ever name anything "default_"-anything. There are two
conflicting meanings for "default_" in the C++ standard:
(1) "Default" as in "the best one to use." There will be a reason that it
is the best one. State that reason. For example, "my::mt19937" is a good
name for a default random number engine, and "my::sha256" is a good name
for the default hash.
(2) "Default" as in "implementation-defined." Such a typedef will never be
used by anyone, because its behavior will not be portable. Prefer to
*eliminate* such useless cruft from the wording completely.

HTH,
Arthur

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

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

<div dir=3D"ltr">On Mon, Jan 22, 2018 at 9:23 AM, Andrey Semashev <span dir=
=3D"ltr">&lt;<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank"=
>andrey.semashev@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">On 01/22/18 12:10, Marius Bancila wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
Again, the link to the project is <a href=3D"https://github.com/mariusbanci=
la/stduuid" rel=3D"noreferrer" target=3D"_blank">https://github.com/mariusb=
anci<wbr>la/stduuid</a>, and to the proposal: <a href=3D"https://github.com=
/mariusbancila/stduuid/blob/master/paper.md" rel=3D"noreferrer" target=3D"_=
blank">https://github.com/mariusbanci<wbr>la/stduuid/blob/master/paper.<wbr=
>md</a>.<br>
</span></blockquote>
<br>
- I believe, `swap` should be overloaded, not specialized.<br></blockquote>=
<div><br></div><div>Nicolas Lesser also observed that `swap` was funky.</di=
v><div>Marius, here&#39;s what you currently have:</div><div><br></div><div=
>=C2=A0 =C2=A0 // BAD</div><div>=C2=A0 =C2=A0 namespace my {</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 struct X {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 void swap(X&amp;); =C2=A0// member swap<br></div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 friend void swap(X&amp;, X&amp;); =C2=A0=
// Barton-Nackman trick provides ADL swap</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 };</div><div>=C2=A0 =C2=A0 }</div><div>=C2=A0 =C2=A0 namespace std {=
</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 template&lt;&gt; void swap(my::X&amp=
;, my::X&amp;); =C2=A0// bogus &quot;specialization&quot; of a function tem=
plate not in your namespace</div><div>=C2=A0 =C2=A0 }</div><div><br></div><=
div>And here is what you should have:</div><div><br></div><div>=C2=A0 =C2=
=A0 // GOOD</div><div><div>=C2=A0 =C2=A0 namespace my {</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 struct X {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 void swap(X&amp;); =C2=A0// member swap<br></div><div>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 };<br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 inline void =
swap(X&amp;, X&amp;); =C2=A0// ADL swap</div><div><span class=3D"sewwz2x3t4=
dl9nx"></span><span class=3D"sewwk8xa8vl1pud"></span>=C2=A0 =C2=A0 }</div><=
div><br></div></div><div>Your specialization for std::hash is correct; std:=
:hash is a customization point that operates by template specialization.</d=
iv><div>But std::swap is not a customization point. The way you provide `sw=
ap` for your type is via ADL, not via template specialization of std::swap.=
</div><div>(std::swap actually has tons of overloads, many of which are tem=
plates; providing a &quot;template specialization&quot; for an overloaded f=
unction is bad times.)</div><div><br></div><div>It would be acceptable to c=
ontinue using the Barton-Nackman trick, too. I.e., this is also acceptable:=
</div><div><br></div><div><div>=C2=A0 =C2=A0 // GOOD</div><div><div>=C2=A0 =
=C2=A0 namespace my {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct X {</div=
><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 void swap(X&amp;); =C2=A0//=
 member swap<br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 friend=
 void swap(X&amp;, X&amp;); =C2=A0// Barton-Nackman trick provides ADL swap=
</div><div><span class=3D"sewwz2x3t4dl9nx"></span><span class=3D"sewwk8xa8v=
l1pud"></span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 };<br></div><div>=C2=A0 =C2=A0 }<=
br></div></div></div><div><span class=3D"sewwz2x3t4dl9nx"></span><span clas=
s=3D"sewwk8xa8vl1pud"></span><br></div><div>But standard library types do n=
ot use the Barton-Nackman trick, and so I recommend that you don&#39;t use =
it either, in things targeting the standard library.</div><div><br></div><d=
iv><br></div><div>Speaking of std::hash, it might be preferable to write</d=
iv><div>=C2=A0 =C2=A0 using result_type =3D std::hash&lt;std::string&gt;::r=
esult_type;</div><div>and eliminate the static_cast in operator()().</div><=
div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- I think `uuid_default_generator` still has to provide some guarantees on =
the produced UUIDs. Having a generator that produces noone knows what is ha=
rdly useful. I assume it is supposed to produce random UUIDs using some sys=
tem-specific source of randomness, so why not say that? Also, if it is a ra=
ndom generator, its name should reflect that.</blockquote><div><br></div><d=
iv>Yes. Please never ever name anything &quot;default_&quot;-anything. Ther=
e are two conflicting meanings for &quot;default_&quot; in the C++ standard=
:</div><div>(1) &quot;Default&quot; as in &quot;the best one to use.&quot; =
There will be a reason that it is the best one. State that reason. For exam=
ple, &quot;my::mt19937&quot; is a good name for a default random number eng=
ine, and &quot;my::sha256&quot; is a good name for the default hash.</div><=
div>(2) &quot;Default&quot; as in &quot;implementation-defined.&quot; Such =
a typedef will never be used by anyone, because its behavior will not be po=
rtable. Prefer to <i>eliminate</i> such useless cruft from the wording comp=
letely.</div><div><br></div><div>HTH,</div><div>Arthur</div></div></div></d=
iv>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2B1jQaQ_mFS4h0gwN8GMRGRnHXqy_=
kUHdXXHQbPJL0RnA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2B1jQaQ=
_mFS4h0gwN8GMRGRnHXqy_kUHdXXHQbPJL0RnA%40mail.gmail.com</a>.<br />

--f403045c26b207b5aa0563612101--

.

--001a114e62fc1b8277056362795d
Content-Type: text/plain; charset="UTF-8"

the signature of std::hash may be correct but the implementation leaves a
lot to be desired. There's too much overhead in converting the uuid to a
string and then hashing the string.

On Monday, January 22, 2018, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

> On Mon, Jan 22, 2018 at 9:23 AM, Andrey Semashev <
> andrey.semashev@gmail.com> wrote:
>
>> On 01/22/18 12:10, Marius Bancila wrote:
>>
>>>
>>> Again, the link to the project is https://github.com/mariusbanci
>>> la/stduuid, and to the proposal: https://github.com/mariusbanci
>>> la/stduuid/blob/master/paper.md.
>>>
>>
>> - I believe, `swap` should be overloaded, not specialized.
>>
>
> Nicolas Lesser also observed that `swap` was funky.
> Marius, here's what you currently have:
>
>     // BAD
>     namespace my {
>         struct X {
>             void swap(X&);  // member swap
>             friend void swap(X&, X&);  // Barton-Nackman trick provides
> ADL swap
>         };
>     }
>     namespace std {
>         template<> void swap(my::X&, my::X&);  // bogus "specialization"
> of a function template not in your namespace
>     }
>
> And here is what you should have:
>
>     // GOOD
>     namespace my {
>         struct X {
>             void swap(X&);  // member swap
>         };
>         inline void swap(X&, X&);  // ADL swap
>     }
>
> Your specialization for std::hash is correct; std::hash is a customization
> point that operates by template specialization.
> But std::swap is not a customization point. The way you provide `swap` for
> your type is via ADL, not via template specialization of std::swap.
> (std::swap actually has tons of overloads, many of which are templates;
> providing a "template specialization" for an overloaded function is bad
> times.)
>
> It would be acceptable to continue using the Barton-Nackman trick, too.
> I.e., this is also acceptable:
>
>     // GOOD
>     namespace my {
>         struct X {
>             void swap(X&);  // member swap
>             friend void swap(X&, X&);  // Barton-Nackman trick provides
> ADL swap
>         };
>     }
>
> But standard library types do not use the Barton-Nackman trick, and so I
> recommend that you don't use it either, in things targeting the standard
> library.
>
>
> Speaking of std::hash, it might be preferable to write
>     using result_type = std::hash<std::string>::result_type;
> and eliminate the static_cast in operator()().
>
>
> - I think `uuid_default_generator` still has to provide some guarantees on
>> the produced UUIDs. Having a generator that produces noone knows what is
>> hardly useful. I assume it is supposed to produce random UUIDs using some
>> system-specific source of randomness, so why not say that? Also, if it is a
>> random generator, its name should reflect that.
>
>
> Yes. Please never ever name anything "default_"-anything. There are two
> conflicting meanings for "default_" in the C++ standard:
> (1) "Default" as in "the best one to use." There will be a reason that it
> is the best one. State that reason. For example, "my::mt19937" is a good
> name for a default random number engine, and "my::sha256" is a good name
> for the default hash.
> (2) "Default" as in "implementation-defined." Such a typedef will never be
> used by anyone, because its behavior will not be portable. Prefer to
> *eliminate* such useless cruft from the wording completely.
>
> HTH,
> Arthur
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CADvuK0%2B1jQaQ_mFS4h0gwN8GMRGRnHXqy_
> kUHdXXHQbPJL0RnA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2B1jQaQ_mFS4h0gwN8GMRGRnHXqy_kUHdXXHQbPJL0RnA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAF2k6p8sCgBRe6FfR5_7oQ%2B9C%3D2qrkbW3MtwFHewVa%3DA%40mail.gmail.com.

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

the signature of std::hash may be correct but the implementation leaves a l=
ot to be desired. There&#39;s too much overhead in converting the uuid to a=
 string and then hashing the string.<br><br>On Monday, January 22, 2018, Ar=
thur O&#39;Dwyer &lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com">arthur.j.=
odwyer@gmail.com</a>&gt; 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">On Mon, Jan 22, 2018 at 9:23 AM, Andrey Semashev <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.=
semashev@gmail.com</a>&gt;</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"><span>On 01/22/18 12:=
10, Marius Bancila wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span><br>
Again, the link to the project is <a href=3D"https://github.com/mariusbanci=
la/stduuid" rel=3D"noreferrer" target=3D"_blank">https://github.com/mariusb=
anci<wbr>la/stduuid</a>, and to the proposal: <a href=3D"https://github.com=
/mariusbancila/stduuid/blob/master/paper.md" rel=3D"noreferrer" target=3D"_=
blank">https://github.com/mariusbanci<wbr>la/stduuid/blob/master/paper.m<wb=
r>d</a>.<br>
</span></blockquote>
<br>
- I believe, `swap` should be overloaded, not specialized.<br></blockquote>=
<div><br></div><div>Nicolas Lesser also observed that `swap` was funky.</di=
v><div>Marius, here&#39;s what you currently have:</div><div><br></div><div=
>=C2=A0 =C2=A0 // BAD</div><div>=C2=A0 =C2=A0 namespace my {</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 struct X {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 void swap(X&amp;); =C2=A0// member swap<br></div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 friend void swap(X&amp;, X&amp;); =C2=A0=
// Barton-Nackman trick provides ADL swap</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 };</div><div>=C2=A0 =C2=A0 }</div><div>=C2=A0 =C2=A0 namespace std {=
</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 template&lt;&gt; void swap(my::X&amp=
;, my::X&amp;); =C2=A0// bogus &quot;specialization&quot; of a function tem=
plate not in your namespace</div><div>=C2=A0 =C2=A0 }</div><div><br></div><=
div>And here is what you should have:</div><div><br></div><div>=C2=A0 =C2=
=A0 // GOOD</div><div><div>=C2=A0 =C2=A0 namespace my {</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 struct X {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 void swap(X&amp;); =C2=A0// member swap<br></div><div>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 };<br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 inline void =
swap(X&amp;, X&amp;); =C2=A0// ADL swap</div><div><span></span><span></span=
>=C2=A0 =C2=A0 }</div><div><br></div></div><div>Your specialization for std=
::hash is correct; std::hash is a customization point that operates by temp=
late specialization.</div><div>But std::swap is not a customization point. =
The way you provide `swap` for your type is via ADL, not via template speci=
alization of std::swap.</div><div>(std::swap actually has tons of overloads=
, many of which are templates; providing a &quot;template specialization&qu=
ot; for an overloaded function is bad times.)</div><div><br></div><div>It w=
ould be acceptable to continue using the Barton-Nackman trick, too. I.e., t=
his is also acceptable:</div><div><br></div><div><div>=C2=A0 =C2=A0 // GOOD=
</div><div><div>=C2=A0 =C2=A0 namespace my {</div><div>=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 struct X {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 void=
 swap(X&amp;); =C2=A0// member swap<br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 friend void swap(X&amp;, X&amp;); =C2=A0// Barton-Nackman=
 trick provides ADL swap</div><div><span></span><span></span>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 };<br></div><div>=C2=A0 =C2=A0 }<br></div></div></div><div><s=
pan></span><span></span><br></div><div>But standard library types do not us=
e the Barton-Nackman trick, and so I recommend that you don&#39;t use it ei=
ther, in things targeting the standard library.</div><div><br></div><div><b=
r></div><div>Speaking of std::hash, it might be preferable to write</div><d=
iv>=C2=A0 =C2=A0 using result_type =3D std::hash&lt;std::string&gt;::<wbr>r=
esult_type;</div><div>and eliminate the static_cast in operator()().</div><=
div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- I think `uuid_default_generator` still has to provide some guarantees on =
the produced UUIDs. Having a generator that produces noone knows what is ha=
rdly useful. I assume it is supposed to produce random UUIDs using some sys=
tem-specific source of randomness, so why not say that? Also, if it is a ra=
ndom generator, its name should reflect that.</blockquote><div><br></div><d=
iv>Yes. Please never ever name anything &quot;default_&quot;-anything. Ther=
e are two conflicting meanings for &quot;default_&quot; in the C++ standard=
:</div><div>(1) &quot;Default&quot; as in &quot;the best one to use.&quot; =
There will be a reason that it is the best one. State that reason. For exam=
ple, &quot;my::mt19937&quot; is a good name for a default random number eng=
ine, and &quot;my::sha256&quot; is a good name for the default hash.</div><=
div>(2) &quot;Default&quot; as in &quot;implementation-defined.&quot; Such =
a typedef will never be used by anyone, because its behavior will not be po=
rtable. Prefer to <i>eliminate</i> such useless cruft from the wording comp=
letely.</div><div><br></div><div>HTH,</div><div>Arthur</div></div></div></d=
iv>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2B1jQaQ_mFS4h0gwN8GMRGRnHXqy_=
kUHdXXHQbPJL0RnA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CADvuK0%2B1jQaQ_<wbr>mFS4h0gwN8GMRGRnHXqy_<wbr>kUHdXXHQbPJ=
L0RnA%40mail.gmail.<wbr>com</a>.<br>
</blockquote>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAF2k6p8sCgBRe6FfR5_7oQ%2B9C%3D=
2qrkbW3MtwFHewVa%3DA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAF2k=
6p8sCgBRe6FfR5_7oQ%2B9C%3D2qrkbW3MtwFHewVa%3DA%40mail.gmail.com</a>.<br />

--001a114e62fc1b8277056362795d--

.

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

On Mon, Jan 22, 2018 at 11:31 AM, j c <james.a.cooper@gmail.com> wrote:

> the signature of std::hash may be correct but the implementation leaves a
> lot to be desired. There's too much overhead in converting the uuid to a
> string and then hashing the string.


FWIW, I agree that the std::hash implementation should be improved by
vendors if possible. However:
(1) The semantics seem correct to me. I think it is at least slightly
valuable for std::hash<>(uu) and std::hash<>(uu.to_string()) to have the
same integer value. Or, equivalently, for std::hash<>(s) and
std::hash<>(uuid(s)) to have the same integer value.
(2) The details of the implementation (e.g. whether it allocates memory
from the free store) can be left up to the vendor, under the as-if rule.

Should there be a "to_string" member function overload that takes a
buffer-of-char and writes the result into it?  That would eliminate
free-store allocation, since the maximum length of a UUID is known ahead of
time (right?).  But the exact signature of such a member function might be
hard to agree on, in the absence of a standardized writeable string_view
class.  My suggestion would be the classic `size_t to_string(char *,
size_t)`, just to rub it in the faces of the "string_view is implicitly
const" crowd. :P

That is:

    template<>
    struct hash<uuids::uuid> {
        using argument_type =3D uuids::uuid;
        using result_type =3D typename
std::hash<std::string_view>::result_type;
        result_type operator()(argument_type const& uuid) const {
            char buffer[100];  // should be enough for anybody
            auto length =3D uuid.to_string(buffer, sizeof buffer);
            return std::hash<std::string_view>()(std::string_view(buffer,
length));
        }
    };

=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0J-aLUJKS_N-xSbAj8e34rFRD_a-_rC1cSyd49XiED=
hVw%40mail.gmail.com.

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

<div dir=3D"ltr">On Mon, Jan 22, 2018 at 11:31 AM, j c <span dir=3D"ltr">&l=
t;<a href=3D"mailto:james.a.cooper@gmail.com" target=3D"_blank">james.a.coo=
per@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">the signature of std::hash=
 may be correct but the implementation leaves a lot to be desired. There&#3=
9;s too much overhead in converting the uuid to a string and then hashing t=
he string.</blockquote><div><br></div><div>FWIW, I agree that the std::hash=
 implementation should be improved by vendors if possible. However:</div><d=
iv>(1) The semantics seem correct to me. I think it is at least slightly va=
luable for std::hash&lt;&gt;(uu) and std::hash&lt;&gt;(uu.to_string()) to h=
ave the same integer value. Or, equivalently, for std::hash&lt;&gt;(s) and =
std::hash&lt;&gt;(uuid(s)) to have the same integer value.</div><div>(2) Th=
e details of the implementation (e.g. whether it allocates memory from the =
free store) can be left up to the vendor, under the as-if rule.</div><div><=
br></div><div>Should there be a &quot;to_string&quot; member function overl=
oad that takes a buffer-of-char and writes the result into it?=C2=A0 That w=
ould eliminate free-store allocation, since the maximum length of a UUID is=
 known ahead of time (right?).=C2=A0 But the exact signature of such a memb=
er function might be hard to agree on, in the absence of a standardized wri=
teable string_view class.=C2=A0 My suggestion would be the classic `size_t =
to_string(char *, size_t)`, just to rub it in the faces of the &quot;string=
_view is implicitly const&quot; crowd. :P</div><div><br></div><div>That is:=
</div><div><br></div><div>=C2=A0 =C2=A0 template&lt;&gt;<br></div>=C2=A0 =
=C2=A0 struct hash&lt;uuids::uuid&gt;=C2=A0{<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 using argument_type =3D uuids::uuid;</div><div class=3D"gmail_quote">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 using result_type =3D typename std::hash&lt;std::s=
tring_view&gt;::result_type;</div><div class=3D"gmail_quote">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 result_type operator()(argument_type const&amp; uuid) const {=
</div><div class=3D"gmail_quote">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
char buffer[100]; =C2=A0// should be enough for anybody<br></div><div class=
=3D"gmail_quote">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto length =3D =
uuid.to_string(buffer, sizeof buffer);</div><div class=3D"gmail_quote">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return=C2=A0std::hash&lt;std::string=
_view&gt;()<span class=3D"sewqtmxguywzr94"></span><span class=3D"sewoiu250r=
bw9vn"></span>(std::string_view(buffer, length));</div><div class=3D"gmail_=
quote">=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</div><div class=3D"gmail_quote">=C2=A0=
 =C2=A0 };</div><div class=3D"gmail_quote"><div><br></div><div>=E2=80=93Art=
hur</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0J-aLUJKS_N-xSbAj8e34rFRD_a-_rC=
1cSyd49XiEDhVw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0J-aLUJKS_N=
-xSbAj8e34rFRD_a-_rC1cSyd49XiEDhVw%40mail.gmail.com</a>.<br />

--f4030439dba468a3f9056362b751--

.

--94eb2c0b04de6a0fb30563633df3
Content-Type: text/plain; charset="UTF-8"

On Monday, January 22, 2018, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

> On Mon, Jan 22, 2018 at 11:31 AM, j c <james.a.cooper@gmail.com> wrote:
>
>> the signature of std::hash may be correct but the implementation leaves a
>> lot to be desired. There's too much overhead in converting the uuid to a
>> string and then hashing the string.
>
>
> FWIW, I agree that the std::hash implementation should be improved by
> vendors if possible. However:
> (1) The semantics seem correct to me. I think it is at least slightly
> valuable for std::hash<>(uu) and std::hash<>(uu.to_string()) to have the
> same integer value. Or, equivalently, for std::hash<>(s) and
> std::hash<>(uuid(s)) to have the same integer value.
>

it's not the same though. A raw uuid is an array of 16 bytes. A string
representation of this is those 16 bytes converted to human readable
characters and then having hyphens inserted where appropriate.

If you want these to hash to the same value then I'd argue that there
should be a std::uuid::from_string function.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAzeg9Z9uL%3DxuyHA-7WoDnS5aNmW3%2BbCsyzQOXFmavqWw%40mail.gmail.com.

--94eb2c0b04de6a0fb30563633df3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, January 22, 2018, Arthur O&#39;Dwyer &lt;<a href=3D"mail=
to:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>&gt; 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">On Mon, Jan 22, 2018 at 11:3=
1 AM, j c <span dir=3D"ltr">&lt;<a href=3D"mailto:james.a.cooper@gmail.com"=
 target=3D"_blank">james.a.cooper@gmail.com</a>&gt;</span> wrote:<br><div c=
lass=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:1=
ex">the signature of std::hash may be correct but the implementation leaves=
 a lot to be desired. There&#39;s too much overhead in converting the uuid =
to a string and then hashing the string.</blockquote><div><br></div><div>FW=
IW, I agree that the std::hash implementation should be improved by vendors=
 if possible. However:</div><div>(1) The semantics seem correct to me. I th=
ink it is at least slightly valuable for std::hash&lt;&gt;(uu) and std::has=
h&lt;&gt;(uu.to_string()) to have the same integer value. Or, equivalently,=
 for std::hash&lt;&gt;(s) and std::hash&lt;&gt;(uuid(s)) to have the same i=
nteger value.</div></div></div></div></blockquote><div><br></div><div>it&#3=
9;s not the same though. A raw uuid is an array of 16 bytes. A string repre=
sentation of this is those 16 bytes converted to human readable characters =
and then having hyphens inserted where appropriate.</div><div><br></div><di=
v>If you want these to hash to the same value then I&#39;d argue that there=
 should be a std::uuid::from_string function.</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAzeg9Z9uL%3DxuyHA-7WoDnS5aNmW3=
%2BbCsyzQOXFmavqWw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAzeg9Z=
9uL%3DxuyHA-7WoDnS5aNmW3%2BbCsyzQOXFmavqWw%40mail.gmail.com</a>.<br />

--94eb2c0b04de6a0fb30563633df3--

.

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

On Mon, Jan 22, 2018 at 12:26 PM, j c <james.a.cooper@gmail.com> wrote:

> On Monday, January 22, 2018, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
> wrote:
>
>> On Mon, Jan 22, 2018 at 11:31 AM, j c <james.a.cooper@gmail.com> wrote:
>>
>>> the signature of std::hash may be correct but the implementation leaves
>>> a lot to be desired. There's too much overhead in converting the uuid t=
o a
>>> string and then hashing the string.
>>
>>
>> FWIW, I agree that the std::hash implementation should be improved by
>> vendors if possible. However:
>> (1) The semantics seem correct to me. I think it is at least slightly
>> valuable for std::hash<>(uu) and std::hash<>(uu.to_string()) to have the
>> same integer value. Or, equivalently, for std::hash<>(s) and
>> std::hash<>(uuid(s)) to have the same integer value.
>>
>
> it's not the same though. A raw uuid is an array of 16 bytes. A string
> representation of this is those 16 bytes converted to human readable
> characters and then having hyphens inserted where appropriate.
>
> If you want these to hash to the same value then I'd argue that there
> should be a std::uuid::from_string function.
>

Marius does provide such a function.
https://github.com/mariusbancila/stduuid/blob/master/include/uuid.h#L604-L6=
19

However, you make a good point there: suppose we have
    std::string string_with_dashes =3D "47183823-2574-4bfd-b411-99ed177d3e4=
3";
    std::string string_without_dashes =3D "4718382325744bfdb41199ed177d3e43=
";
    stdext::uuid uuid_with_dashes(string_with_dashes);
    stdext::uuid uuid_without_dashes(string_without_dashes);
    std::hash<std::string> string_hasher;
    std::hash<stdext::uuid> uuid_hasher;
    const bool string_hashes_arent_equal =3D
(string_hasher(string_with_dashes) !=3D string_hasher(string_without_dashes=
));
    const bool uuid_hash_doesnt_behave_like_string_hash =3D not (
        (uuid_hasher(uuid_with_dashes) =3D=3D string_hasher(string_with_das=
hes)
&&
        (uuid_hasher(uuid_without_dashes) =3D=3D
string_hasher(string_without_dashes)
    );

Then we expect to have
    assert(string_with_dashes !=3D string_without_dashes);  // we MUST have
this
    assert(uuid_with_dashes =3D=3D uuid_without_dashes);  // we MUST have t=
his
    expect(string_hashes_arent_equal);  // we SHOULD have this
    assert(uuid_hasher(uuid_with_dashes) =3D=3D
uuid_hasher(uuid_without_dashes));  // we MUST have this (since the two
hasher arguments are equal)

    if (string_hashes_arent_equal && uuid_hasher(uuid_with_dashes) =3D=3D
string_hasher(string_with_dashes)) {
        assert(uuid_hasher(uuid_without_dashes) =3D=3D
string_hasher(string_with_dashes));  // we MUST have this (by transitivity
of equality on size_t)
        assert(uuid_hasher(uuid_without_dashes) !=3D
string_hasher(string_without_dashes));  // if the string hashes aren't
equal, we MUST have this
        assert(uuid_hash_doesnt_behave_like_string_hash);
    }

So okay, I agree, making hash<uuid> and hash<string> behave "the same" is
just asking for trouble. hash<uuid> should be reimplemented in terms of
hashing the underlying bytes.  It could probably just XOR them all together
in size_t-sized chunks.  And the standard should make it
implementation-defined, i.e., let the vendor figure it out.

=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0LdBz%2BtkpuBpsQ2Z%2BOvzi%3DAp_ea_napA6kya=
x91WQ94ow%40mail.gmail.com.

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

<div dir=3D"ltr">On Mon, Jan 22, 2018 at 12:26 PM, j c <span dir=3D"ltr">&l=
t;<a href=3D"mailto:james.a.cooper@gmail.com" target=3D"_blank">james.a.coo=
per@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Monday=
, January 22, 2018, Arthur O&#39;Dwyer &lt;<a href=3D"mailto:arthur.j.odwye=
r@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.com</a>&gt; wrote:<br>=
</span><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On =
Mon, Jan 22, 2018 at 11:31 AM, j c <span dir=3D"ltr">&lt;<a href=3D"mailto:=
james.a.cooper@gmail.com" target=3D"_blank">james.a.cooper@gmail.com</a>&gt=
;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">the signature of std::hash may be correct but =
the implementation leaves a lot to be desired. There&#39;s too much overhea=
d in converting the uuid to a string and then hashing the string.</blockquo=
te><div><br></div><div>FWIW, I agree that the std::hash implementation shou=
ld be improved by vendors if possible. However:</div><div>(1) The semantics=
 seem correct to me. I think it is at least slightly valuable for std::hash=
&lt;&gt;(uu) and std::hash&lt;&gt;(uu.to_string()) to have the same integer=
 value. Or, equivalently, for std::hash&lt;&gt;(s) and std::hash&lt;&gt;(uu=
id(s)) to have the same integer value.</div></div></div></div></blockquote>=
<div><br></div></span><div>it&#39;s not the same though. A raw uuid is an a=
rray of 16 bytes. A string representation of this is those 16 bytes convert=
ed to human readable characters and then having hyphens inserted where appr=
opriate.</div><div><br></div><div>If you want these to hash to the same val=
ue then I&#39;d argue that there should be a std::uuid::from_string functio=
n.</div></blockquote><div><br></div><div>Marius does provide such a functio=
n.</div><div><a href=3D"https://github.com/mariusbancila/stduuid/blob/maste=
r/include/uuid.h#L604-L619">https://github.com/mariusbancila/stduuid/blob/m=
aster/include/uuid.h#L604-L619</a><span class=3D"sewstcjq6miqs54"></span><s=
pan class=3D"sewvb6b9cb6b3id"></span></div><div><br></div><div>However, you=
 make a good point there: suppose we have</div><div>=C2=A0 =C2=A0 std::stri=
ng string_with_dashes =3D &quot;47183823-2574-4bfd-b411-99ed177d3e43&quot;;=
</div><div>=C2=A0 =C2=A0 std::string string_without_dashes =3D &quot;471838=
2325744bfdb41199ed177d3e43&quot;;</div><div>=C2=A0 =C2=A0 stdext::uuid uuid=
_with_dashes(string_with_dashes<span class=3D"sewstcjq6miqs54"></span><span=
 class=3D"sewvb6b9cb6b3id"></span>);</div><div>=C2=A0 =C2=A0 stdext::uuid u=
uid_without_dashes(string_without_dashes<span class=3D"sewstcjq6miqs54"></s=
pan><span class=3D"sewvb6b9cb6b3id"></span>);</div><div>=C2=A0 =C2=A0 std::=
hash&lt;std::string&gt; string_hasher;</div><div>=C2=A0 =C2=A0 std::hash&lt=
;stdext::uuid&gt; uuid_hasher;</div><div>=C2=A0 =C2=A0 const bool string_ha=
shes_arent_equal =3D (string_hasher(string_with_dashes) !=3D string_hasher(=
string_without_dashes));<span class=3D"sewstcjq6miqs54"></span><span class=
=3D"sewvb6b9cb6b3id"></span></div><div>=C2=A0 =C2=A0 const bool uuid_hash_d=
oesnt_behave_like_string_hash =3D not (</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 (uuid_hasher(uuid_with_dashes) =3D=3D string_hasher(string_with_dashes)=
 &amp;&amp;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (uuid_hasher(uuid_without=
_dashes) =3D=3D string_hasher(string_without_dashes)</div><div><span class=
=3D"sewstcjq6miqs54"></span><span class=3D"sewvb6b9cb6b3id"></span><span cl=
ass=3D"sewstcjq6miqs54"></span><span class=3D"sewvb6b9cb6b3id"></span>=C2=
=A0 =C2=A0 );<br></div><div><br></div><div>Then we expect to have</div><div=
>=C2=A0 =C2=A0 assert(string_with_dashes !=3D string_without_dashes); =C2=
=A0// we MUST have this</div><div>=C2=A0 =C2=A0 assert(uuid_with_dashes =3D=
=3D uuid_without_dashes); =C2=A0// we MUST have this</div><div><span class=
=3D"sewstcjq6miqs54"></span><span class=3D"sewvb6b9cb6b3id"></span>=C2=A0 =
=C2=A0 expect(string_hashes_arent_equal<span class=3D"sewstcjq6miqs54"></sp=
an><span class=3D"sewvb6b9cb6b3id"></span>); =C2=A0// we SHOULD have this</=
div><div>=C2=A0 =C2=A0 assert(uuid_hasher(uuid_with_dashes) =3D=3D uuid_has=
her(uuid_without_dashes)); =C2=A0// we MUST have this (since the two hasher=
 arguments are equal)<span class=3D"sewstcjq6miqs54"></span></div><div><br>=
</div><div>=C2=A0 =C2=A0 if (string_hashes_arent_equal &amp;&amp;=C2=A0<spa=
n class=3D"sewstcjq6miqs54"></span><span class=3D"sewvb6b9cb6b3id"></span>u=
uid_hasher(uuid_with_dashes) =3D=3D string_hasher(string_with_dashes)) {</d=
iv><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 assert(uuid_hasher(uuid_without_dashes)=
 =3D=3D string_hasher(string_with_dashes)<span class=3D"sewstcjq6miqs54"></=
span><span class=3D"sewvb6b9cb6b3id"></span>); =C2=A0// we MUST have this (=
by transitivity of equality on size_t)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 assert(uuid_hasher(uuid_without_dashes) !=3D string_hasher(string_witho=
ut_dashes)); =C2=A0// if the string hashes aren&#39;t equal, we MUST have t=
his</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 assert(uuid_hash_doesnt_behave_li=
ke_string_hash);</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div>So okay=
, I agree, making hash&lt;uuid&gt; and hash&lt;string&gt; behave &quot;the =
same&quot; is just asking for trouble. hash&lt;uuid&gt; should be reimpleme=
nted in terms of hashing the underlying bytes.=C2=A0 It could probably just=
 XOR them all together in size_t-sized chunks.=C2=A0 And the standard shoul=
d make it implementation-defined, i.e., let the vendor figure it out.</div>=
<div><br></div><div>=E2=80=93Arthur</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0LdBz%2BtkpuBpsQ2Z%2BOvzi%3DAp_=
ea_napA6kyax91WQ94ow%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0LdBz=
%2BtkpuBpsQ2Z%2BOvzi%3DAp_ea_napA6kyax91WQ94ow%40mail.gmail.com</a>.<br />

--f403045c26b29429f7056363a234--

.

On 01/22/18 22:48, Arthur O'Dwyer wrote:
> On Mon, Jan 22, 2018 at 11:31 AM, j c <james.a.cooper@gmail.com
> <mailto:james.a.cooper@gmail.com>> wrote:
>
>     the signature of std::hash may be correct but the implementation
>     leaves a lot to be desired. There's too much overhead in converting
>     the uuid to a string and then hashing the string.
>
>
> FWIW, I agree that the std::hash implementation should be improved by
> vendors if possible. However:
> (1) The semantics seem correct to me. I think it is at least slightly
> valuable for std::hash<>(uu) and std::hash<>(uu.to_string()) to have the
> same integer value. Or, equivalently, for std::hash<>(s) and
> std::hash<>(uuid(s)) to have the same integer value.
> (2) The details of the implementation (e.g. whether it allocates memory
> from the free store) can be left up to the vendor, under the as-if rule.
>
> Should there be a "to_string" member function overload that takes a
> buffer-of-char and writes the result into it?

I don't think std::hash<std::uuid> should be string-based at all, but
we're discussing the proposal, and it doesn't need to suggest a
particular implementation of the specialization. In fact, I think it
should *not* suggest a particular implementation.

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

.

------=_Part_342_1687962585.1516827737871
Content-Type: text/plain; charset="UTF-8"

On Tuesday, 23 January 2018 10:30:20 UTC+9, Andrey Semashev  wrote:
> On 01/22/18 22:48, Arthur O'Dwyer wrote:
> > On Mon, Jan 22, 2018 at 11:31 AM, j c <james.a.cooper@gmail.com
> > <mailto:james.a.cooper@gmail.com>> wrote:
> >
> >     the signature of std::hash may be correct but the implementation
> >     leaves a lot to be desired. There's too much overhead in converting
> >     the uuid to a string and then hashing the string.
> >
> >
> > FWIW, I agree that the std::hash implementation should be improved by
> > vendors if possible. However:
> > (1) The semantics seem correct to me. I think it is at least slightly
> > valuable for std::hash<>(uu) and std::hash<>(uu.to_string()) to have the
> > same integer value. Or, equivalently, for std::hash<>(s) and
> > std::hash<>(uuid(s)) to have the same integer value.
> > (2) The details of the implementation (e.g. whether it allocates memory
> > from the free store) can be left up to the vendor, under the as-if rule.
> >
> > Should there be a "to_string" member function overload that takes a
> > buffer-of-char and writes the result into it?
>
> I don't think std::hash<std::uuid> should be string-based at all, but
> we're discussing the proposal, and it doesn't need to suggest a
> particular implementation of the specialization. In fact, I think it
> should *not* suggest a particular implementation.

Would it be acceptable to make it constexpr, noexcept or (preferably) both? That would preclude the slow, allocating stringstream approach without mandating any particular implementation.

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

------=_Part_342_1687962585.1516827737871--

.

On Thu, Jan 25, 2018 at 12:02 AM, Edward Catmur <ed@catmur.co.uk> wrote:
> On Tuesday, 23 January 2018 10:30:20 UTC+9, Andrey Semashev  wrote:
>>
>> I don't think std::hash<std::uuid> should be string-based at all, but
>> we're discussing the proposal, and it doesn't need to suggest a
>> particular implementation of the specialization. In fact, I think it
>> should *not* suggest a particular implementation.
>
> Would it be acceptable to make it constexpr, noexcept or (preferably) both? That would preclude the slow, allocating stringstream approach without mandating any particular implementation.

I think, constexpr and noexcept would be nice regardless. They don't
preclude a string-based implementation though, as one could generate a
string in a local buffer. Not that I see why one would implement it
that 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B6CgEYsdm1ZnR2UPRT4%2BzNL3OuwQ2Wg5j_FObnT%2BfA-Rug%40mail.gmail.com.

.

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

On Wed, Jan 24, 2018 at 2:23 PM, Andrey Semashev <andrey.semashev@gmail.com=
>
wrote:

> On Thu, Jan 25, 2018 at 12:02 AM, Edward Catmur <ed@catmur.co.uk> wrote:
> > On Tuesday, 23 January 2018 10:30:20 UTC+9, Andrey Semashev  wrote:
> >>
> >> I don't think std::hash<std::uuid> should be string-based at all, but
> >> we're discussing the proposal, and it doesn't need to suggest a
> >> particular implementation of the specialization. In fact, I think it
> >> should *not* suggest a particular implementation.
> >
> > Would it be acceptable to make it constexpr, noexcept or (preferably)
> both? That would preclude the slow, allocating stringstream approach
> without mandating any particular implementation.
>
> I think, constexpr and noexcept would be nice regardless. They don't
> preclude a string-based implementation though, as one could generate a
> string in a local buffer. Not that I see why one would implement it
> that way.
>

That's exactly what I meant by the suggestion

> > Should there be a "to_string" member function overload that takes a
> > buffer-of-char and writes the result into it?

There probably should be such a member function.

Either that, or
(A) uuid::operator<< should be specified not to use heap-allocation, *and*
(B) the standard should provide an allocator-aware version of
std::ostringstream (P0407 <http://wg21.link/p0407>),
which would let people stringify a UUID to a local char buffer by jumping
through only O(1) hoops.

=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0%2BPp40k0wLva_6iF1mApOeq0ycNt94cjYeAUD-TC=
_XYNQ%40mail.gmail.com.

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

<div dir=3D"ltr">On Wed, Jan 24, 2018 at 2:23 PM, Andrey Semashev <span dir=
=3D"ltr">&lt;<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank"=
>andrey.semashev@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">On Thu, Jan 25, 2018 at 12:02 AM, Edward Catmur &lt;<a href=3D"mailto=
:ed@catmur.co.uk">ed@catmur.co.uk</a>&gt; wrote:<br>
&gt; On Tuesday, 23 January 2018 10:30:20 UTC+9, Andrey Semashev=C2=A0 wrot=
e:<br>
&gt;&gt;<br>
</span><span class=3D"">&gt;&gt; I don&#39;t think std::hash&lt;std::uuid&g=
t; should be string-based at all, but<br>
&gt;&gt; we&#39;re discussing the proposal, and it doesn&#39;t need to sugg=
est a<br>
&gt;&gt; particular implementation of the specialization. In fact, I think =
it<br>
&gt;&gt; should *not* suggest a particular implementation.<br>
&gt;<br>
&gt; Would it be acceptable to make it constexpr, noexcept or (preferably) =
both? That would preclude the slow, allocating stringstream approach withou=
t mandating any particular implementation.<br>
<br>
</span>I think, constexpr and noexcept would be nice regardless. They don&#=
39;t<br>
preclude a string-based implementation though, as one could generate a<br>
string in a local buffer. Not that I see why one would implement it<br>
that way.<span class=3D""><br></span></blockquote><div><br></div><div>That&=
#39;s exactly what I meant by the suggestion</div><div><br></div><div><span=
 style=3D"font-size:13px">&gt; &gt; Should there be a &quot;to_string&quot;=
 member function overload that takes a</span><br style=3D"font-size:13px"><=
span style=3D"font-size:13px">&gt; &gt; buffer-of-char and writes the resul=
t into it?<span class=3D"sew9ywgm8p2konq"></span><span class=3D"sewsor5h9ki=
z23z"></span></span><br></div><div><br></div><div>There probably should be =
such a member function.</div><div><br></div><div>Either that, or<br></div><=
div>(A) uuid::operator&lt;&lt; should be specified not to use heap-allocati=
on, <b><i>and</i></b></div><div>(B) the standard should provide an allocato=
r-aware version of std::ostringstream (<a href=3D"http://wg21.link/p0407">P=
0407</a>),</div><div>which would let people stringify a UUID to a local cha=
r buffer by jumping through only O(1) hoops.</div><div><br></div><div>=E2=
=80=93Arthur</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BPp40k0wLva_6iF1mApOeq0ycNt9=
4cjYeAUD-TC_XYNQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BPp40k=
0wLva_6iF1mApOeq0ycNt94cjYeAUD-TC_XYNQ%40mail.gmail.com</a>.<br />

--f403045c0d3eac185d05638ea19d--

.

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

I got some good comments after the last update. I'll try to summarize the
main points and answer here:

The section "Iterators constructors" lists two examples, neither of which
> uses iterators to construct UUID.


That was a error after some edits. It's fixed.

The "Capacity" section should probably be named "Size" since you describe
> the `size` method there. Also, `nil` has nothing to do with size, and its
> description is better moved elsewhere.


Done. I made two sections, one called Size and one called Nil.

I believe, `swap` should be overloaded, not specialized.


Done. I removed the specialization of swap and provided an overload.

Why is `uuid_variant::future` needed?


It's actually called uuid_variant::reserved. It's not really needed, but it
is specified by rfc4122 so at least in theory it may occur (in the future),
and therefore the enum should have, in my opinion, an enumerator for it.


> `uuid::uuid_const_iterator` and `uuid::uuid_iterator` don't need to be in
> the specification. The type of the iterators can simply be specified as
> implementation-defined.
>     typedef /*implementation-defined*/ iterator; // see [uuid]
>     using const_iterator =3D implementation-defined; // see [uuid]


That was my intention in the first place, but didn't put it in this form,
but in something that looked more of a specification. I changed it to what
was suggested.

I don't think std::hash<std::uuid> should be string-based at all, but we're
> discussing the proposal, and it doesn't need to suggest a particular
> implementation of the specialization. In fact, I think it should *not*
> suggest a particular implementation.


I am not suggesting any implementation. Yes, I did a string-based
implementation, but that doesn't mean it has to be so.

I think `uuid_default_generator` still has to provide some guarantees on
> the produced UUIDs. Having a generator that produces noone knows what is
> hardly useful. I assume it is supposed to produce random UUIDs using some
> system-specific source of randomness, so why not say that? Also, if it is=
 a
> random generator, its name should reflect that.
>
> Yes. Please never ever name anything "default_"-anything. There are two
> conflicting meanings for "default_" in the C++ standard:
> (1) "Default" as in "the best one to use." There will be a reason that it
> is the best one. State that reason. For example, "my::mt19937" is a good
> name for a default random number engine, and "my::sha256" is a good name
> for the default hash.
> (2) "Default" as in "implementation-defined." Such a typedef will never b=
e
> used by anyone, because its behavior will not be portable. Prefer to
> eliminate such useless cruft from the wording completely.


I removed the uuid_default_generator completely from the specification.
Although in my particular implementation I still have that, I have renamed
it to uuid_system_generator and explained it uses system resources for
generating a UUID. However, it's not part of the library specification any
more.

I hope this addresses most of the last concerns.

Marius

On Thu, Jan 25, 2018 at 2:12 AM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

> On Wed, Jan 24, 2018 at 2:23 PM, Andrey Semashev <
> andrey.semashev@gmail.com> wrote:
>
>> On Thu, Jan 25, 2018 at 12:02 AM, Edward Catmur <ed@catmur.co.uk> wrote:
>> > On Tuesday, 23 January 2018 10:30:20 UTC+9, Andrey Semashev  wrote:
>> >>
>> >> I don't think std::hash<std::uuid> should be string-based at all, but
>> >> we're discussing the proposal, and it doesn't need to suggest a
>> >> particular implementation of the specialization. In fact, I think it
>> >> should *not* suggest a particular implementation.
>> >
>> > Would it be acceptable to make it constexpr, noexcept or (preferably)
>> both? That would preclude the slow, allocating stringstream approach
>> without mandating any particular implementation.
>>
>> I think, constexpr and noexcept would be nice regardless. They don't
>> preclude a string-based implementation though, as one could generate a
>> string in a local buffer. Not that I see why one would implement it
>> that way.
>>
>
> That's exactly what I meant by the suggestion
>
> > > Should there be a "to_string" member function overload that takes a
> > > buffer-of-char and writes the result into it?
>
> There probably should be such a member function.
>
> Either that, or
> (A) uuid::operator<< should be specified not to use heap-allocation, *and=
*
> (B) the standard should provide an allocator-aware version of
> std::ostringstream (P0407 <http://wg21.link/p0407>),
> which would let people stringify a UUID to a local char buffer by jumping
> through only O(1) hoops.
>
> =E2=80=93Arthur
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CADvuK0%2BPp40k0wLva_
> 6iF1mApOeq0ycNt94cjYeAUD-TC_XYNQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BP=
p40k0wLva_6iF1mApOeq0ycNt94cjYeAUD-TC_XYNQ%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CA%2BgtASx%3DVyao4vj-jToYmKYeY2p_7OV7_AR2tOTwdVO=
3kqVzqw%40mail.gmail.com.

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

<div dir=3D"ltr">I got some good comments after the last update. I&#39;ll t=
ry to summarize the main points and answer here:<div><br></div><div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">The section &quot;Iterators cons=
tructors&quot; lists two examples, neither of which uses iterators to const=
ruct UUID.</blockquote><div><br></div><div>That was a error after some edit=
s. It&#39;s fixed.</div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">The &quot;Capacity&quot; section should probably be named &qu=
ot;Size&quot; since you describe the `size` method there. Also, `nil` has n=
othing to do with size, and its description is better moved elsewhere.</blo=
ckquote><div><br></div><div>Done. I made two sections, one called Size and =
one called Nil.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">I believe, `swap` should be overloaded, not specialized.</blockq=
uote><div><br></div><div>Done. I removed the specialization of swap and pro=
vided an overload.</div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">Why is `uuid_variant::future` needed?</blockquote><div><br></=
div><div>It&#39;s actually called <font face=3D"monospace, monospace">uuid_=
variant::reserved</font>. It&#39;s not really needed, but it is specified b=
y rfc4122 so at least in theory it may occur (in the future), and therefore=
 the enum should have, in my opinion, an enumerator for it.=C2=A0</div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>`uuid::uui=
d_const_iterator` and `uuid::uuid_iterator` don&#39;t need to be in the spe=
cification. The type of the iterators can simply be specified as implementa=
tion-defined.<br>=C2=A0 =C2=A0 typedef /*implementation-defined*/ iterator;=
 // see [uuid]<br>=C2=A0 =C2=A0 using const_iterator =3D implementation-def=
ined; // see [uuid]</blockquote><div>=C2=A0 =C2=A0=C2=A0</div><div>That was=
 my intention in the first place, but didn&#39;t put it in this form, but i=
n something that looked more of a specification. I changed it to what was s=
uggested.</div><div><br></div><div>

<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex" class=3D"gmail_quote">I don&#39;t think std::ha=
sh&lt;std::uuid&gt; should be string-based at all, but we&#39;re discussing=
 the proposal, and it doesn&#39;t need to suggest a particular implementati=
on of the specialization. In fact, I think it should *not* suggest a partic=
ular implementation.</blockquote><br class=3D"gmail-Apple-interchange-newli=
ne">

I am not suggesting any implementation. Yes, I did a string-based implement=
ation, but that doesn&#39;t mean it has to be so.</div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">I think `uuid_default_generato=
r` still has to provide some guarantees on the produced UUIDs. Having a gen=
erator that produces noone knows what is hardly useful. I assume it is supp=
osed to produce random UUIDs using some system-specific source of randomnes=
s, so why not say that? Also, if it is a random generator, its name should =
reflect that.<br><br>Yes. Please never ever name anything &quot;default_&qu=
ot;-anything. There are two conflicting meanings for &quot;default_&quot; i=
n the C++ standard:<br>(1) &quot;Default&quot; as in &quot;the best one to =
use.&quot; There will be a reason that it is the best one. State that reaso=
n. For example, &quot;my::mt19937&quot; is a good name for a default random=
 number engine, and &quot;my::sha256&quot; is a good name for the default h=
ash.<br>(2) &quot;Default&quot; as in &quot;implementation-defined.&quot; S=
uch a typedef will never be used by anyone, because its behavior will not b=
e portable. Prefer to eliminate such useless cruft from the wording complet=
ely.</blockquote><div><br></div><div>I removed the uuid_default_generator c=
ompletely from the specification. Although in my particular implementation =
I still have that, I have renamed it to uuid_system_generator and explained=
 it uses system resources for generating a UUID. However, it&#39;s not part=
 of the library specification any more.</div></div><div><br></div><div>I ho=
pe this addresses most of the last concerns.</div><div><br></div><div>Mariu=
s</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On T=
hu, Jan 25, 2018 at 2:12 AM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@g=
mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><span class=3D"">On Wed, Jan 24, 2018 at 2:23 PM, Andrey Semashev =
<span dir=3D"ltr">&lt;<a href=3D"mailto:andrey.semashev@gmail.com" target=
=3D"_blank">andrey.semashev@gmail.com</a>&gt;</span> wrote:<br></span><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><span>On Thu, Jan 25, 2018 at 12:02 AM, Edward Catmur=
 &lt;<a href=3D"mailto:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co.uk</=
a>&gt; wrote:<br>
&gt; On Tuesday, 23 January 2018 10:30:20 UTC+9, Andrey Semashev=C2=A0 wrot=
e:<br>
&gt;&gt;<br>
</span><span>&gt;&gt; I don&#39;t think std::hash&lt;std::uuid&gt; should b=
e string-based at all, but<br>
&gt;&gt; we&#39;re discussing the proposal, and it doesn&#39;t need to sugg=
est a<br>
&gt;&gt; particular implementation of the specialization. In fact, I think =
it<br>
&gt;&gt; should *not* suggest a particular implementation.<br>
&gt;<br>
&gt; Would it be acceptable to make it constexpr, noexcept or (preferably) =
both? That would preclude the slow, allocating stringstream approach withou=
t mandating any particular implementation.<br>
<br>
</span>I think, constexpr and noexcept would be nice regardless. They don&#=
39;t<br>
preclude a string-based implementation though, as one could generate a<br>
string in a local buffer. Not that I see why one would implement it<br>
that way.<span><br></span></blockquote><div><br></div></span><div>That&#39;=
s exactly what I meant by the suggestion</div><span class=3D""><div><br></d=
iv><div><span style=3D"font-size:13px">&gt; &gt; Should there be a &quot;to=
_string&quot; member function overload that takes a</span><br style=3D"font=
-size:13px"><span style=3D"font-size:13px">&gt; &gt; buffer-of-char and wri=
tes the result into it?<span class=3D"m_8318511200263111284sew9ywgm8p2konq"=
></span><span class=3D"m_8318511200263111284sewsor5h9kiz23z"></span></span>=
<br></div><div><br></div></span><div>There probably should be such a member=
 function.</div><div><br></div><div>Either that, or<br></div><div>(A) uuid:=
:operator&lt;&lt; should be specified not to use heap-allocation, <b><i>and=
</i></b></div><div>(B) the standard should provide an allocator-aware versi=
on of std::ostringstream (<a href=3D"http://wg21.link/p0407" target=3D"_bla=
nk">P0407</a>),</div><div>which would let people stringify a UUID to a loca=
l char buffer by jumping through only O(1) hoops.</div><div><br></div><div>=
=E2=80=93Arthur</div></div></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BPp40k0wLva_6iF1mApOeq0ycNt9=
4cjYeAUD-TC_XYNQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CADvuK0%<wbr>2BPp40k0wLva_<wbr>6iF1mApOeq0ycNt94cjYeAUD-TC=
_<wbr>XYNQ%40mail.gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASx%3DVyao4vj-jToYmKYeY2p_7OV7=
_AR2tOTwdVO3kqVzqw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASx%3D=
Vyao4vj-jToYmKYeY2p_7OV7_AR2tOTwdVO3kqVzqw%40mail.gmail.com</a>.<br />

--001a1141fb80b2635605640da80a--

.

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

My proposal on the uuid library, P0959R0
<http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0959r0.md>, made it
to the pre-Jacksonville mailing (
https://isocpp.org/blog/2018/02/2018-02-pre-jacksonville-mailing-available)=
,
but I cannot be there to present it. If anyone that will be there is
interested in doing so, please drop me a message.

Thank you

On Wed, Jan 31, 2018 at 9:44 AM, Marius Bancila <marius.bancila@gmail.com>
wrote:

> I got some good comments after the last update. I'll try to summarize the
> main points and answer here:
>
> The section "Iterators constructors" lists two examples, neither of which
>> uses iterators to construct UUID.
>
>
> That was a error after some edits. It's fixed.
>
> The "Capacity" section should probably be named "Size" since you describe
>> the `size` method there. Also, `nil` has nothing to do with size, and it=
s
>> description is better moved elsewhere.
>
>
> Done. I made two sections, one called Size and one called Nil.
>
> I believe, `swap` should be overloaded, not specialized.
>
>
> Done. I removed the specialization of swap and provided an overload.
>
> Why is `uuid_variant::future` needed?
>
>
> It's actually called uuid_variant::reserved. It's not really needed, but
> it is specified by rfc4122 so at least in theory it may occur (in the
> future), and therefore the enum should have, in my opinion, an enumerator
> for it.
>
>
>> `uuid::uuid_const_iterator` and `uuid::uuid_iterator` don't need to be i=
n
>> the specification. The type of the iterators can simply be specified as
>> implementation-defined.
>>     typedef /*implementation-defined*/ iterator; // see [uuid]
>>     using const_iterator =3D implementation-defined; // see [uuid]
>
>
> That was my intention in the first place, but didn't put it in this form,
> but in something that looked more of a specification. I changed it to wha=
t
> was suggested.
>
> I don't think std::hash<std::uuid> should be string-based at all, but
>> we're discussing the proposal, and it doesn't need to suggest a particul=
ar
>> implementation of the specialization. In fact, I think it should *not*
>> suggest a particular implementation.
>
>
> I am not suggesting any implementation. Yes, I did a string-based
> implementation, but that doesn't mean it has to be so.
>
> I think `uuid_default_generator` still has to provide some guarantees on
>> the produced UUIDs. Having a generator that produces noone knows what is
>> hardly useful. I assume it is supposed to produce random UUIDs using som=
e
>> system-specific source of randomness, so why not say that? Also, if it i=
s a
>> random generator, its name should reflect that.
>>
>> Yes. Please never ever name anything "default_"-anything. There are two
>> conflicting meanings for "default_" in the C++ standard:
>> (1) "Default" as in "the best one to use." There will be a reason that i=
t
>> is the best one. State that reason. For example, "my::mt19937" is a good
>> name for a default random number engine, and "my::sha256" is a good name
>> for the default hash.
>> (2) "Default" as in "implementation-defined." Such a typedef will never
>> be used by anyone, because its behavior will not be portable. Prefer to
>> eliminate such useless cruft from the wording completely.
>
>
> I removed the uuid_default_generator completely from the specification.
> Although in my particular implementation I still have that, I have rename=
d
> it to uuid_system_generator and explained it uses system resources for
> generating a UUID. However, it's not part of the library specification an=
y
> more.
>
> I hope this addresses most of the last concerns.
>
> Marius
>
> On Thu, Jan 25, 2018 at 2:12 AM, Arthur O'Dwyer <arthur.j.odwyer@gmail.co=
m
> > wrote:
>
>> On Wed, Jan 24, 2018 at 2:23 PM, Andrey Semashev <
>> andrey.semashev@gmail.com> wrote:
>>
>>> On Thu, Jan 25, 2018 at 12:02 AM, Edward Catmur <ed@catmur.co.uk> wrote=
:
>>> > On Tuesday, 23 January 2018 10:30:20 UTC+9, Andrey Semashev  wrote:
>>> >>
>>> >> I don't think std::hash<std::uuid> should be string-based at all, bu=
t
>>> >> we're discussing the proposal, and it doesn't need to suggest a
>>> >> particular implementation of the specialization. In fact, I think it
>>> >> should *not* suggest a particular implementation.
>>> >
>>> > Would it be acceptable to make it constexpr, noexcept or (preferably)
>>> both? That would preclude the slow, allocating stringstream approach
>>> without mandating any particular implementation.
>>>
>>> I think, constexpr and noexcept would be nice regardless. They don't
>>> preclude a string-based implementation though, as one could generate a
>>> string in a local buffer. Not that I see why one would implement it
>>> that way.
>>>
>>
>> That's exactly what I meant by the suggestion
>>
>> > > Should there be a "to_string" member function overload that takes a
>> > > buffer-of-char and writes the result into it?
>>
>> There probably should be such a member function.
>>
>> Either that, or
>> (A) uuid::operator<< should be specified not to use heap-allocation,
>> *and*
>> (B) the standard should provide an allocator-aware version of
>> std::ostringstream (P0407 <http://wg21.link/p0407>),
>> which would let people stringify a UUID to a local char buffer by jumpin=
g
>> through only O(1) hoops.
>>
>> =E2=80=93Arthur
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/CADvuK0%2BPp40k0wLva_6iF1mApO
>> eq0ycNt94cjYeAUD-TC_XYNQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2B=
Pp40k0wLva_6iF1mApOeq0ycNt94cjYeAUD-TC_XYNQ%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>> .
>>
>
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CA%2BgtASwAinGU4xSiTO513TTU-47YKymHQC5YnBv_QidTa=
5Tt0A%40mail.gmail.com.

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

<div dir=3D"ltr">My proposal on the uuid library,=C2=A0<a href=3D"http://op=
en-std.org/JTC1/SC22/WG21/docs/papers/2018/p0959r0.md">P0959R0</a>, made it=
 to the pre-Jacksonville mailing (<a href=3D"https://isocpp.org/blog/2018/0=
2/2018-02-pre-jacksonville-mailing-available">https://isocpp.org/blog/2018/=
02/2018-02-pre-jacksonville-mailing-available</a>), but I cannot be there t=
o present it. If anyone that will be there is interested in doing so, pleas=
e drop me a message.<div><br></div><div>Thank you</div></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jan 31, 2018 at 9:44 AM=
, Marius Bancila <span dir=3D"ltr">&lt;<a href=3D"mailto:marius.bancila@gma=
il.com" target=3D"_blank">marius.bancila@gmail.com</a>&gt;</span> wrote:<br=
><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">I got some good comments a=
fter the last update. I&#39;ll try to summarize the main points and answer =
here:<div><br></div><div><span class=3D""><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">The section &quot;Iterators constructors&quot; lists two e=
xamples, neither of which uses iterators to construct UUID.</blockquote><di=
v><br></div></span><div>That was a error after some edits. It&#39;s fixed.<=
/div><span class=3D""><div><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">The &quot;Capacity&quot; section should probably be named &quot=
;Size&quot; since you describe the `size` method there. Also, `nil` has not=
hing to do with size, and its description is better moved elsewhere.</block=
quote><div><br></div></span><div>Done. I made two sections, one called Size=
 and one called Nil.</div><span class=3D""><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">I believe, `swap` should be overloaded, no=
t specialized.</blockquote><div><br></div></span><div>Done. I removed the s=
pecialization of swap and provided an overload.</div><span class=3D""><div>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Why is `uuid_va=
riant::future` needed?</blockquote><div><br></div></span><div>It&#39;s actu=
ally called <font face=3D"monospace, monospace">uuid_variant::reserved</fon=
t>. It&#39;s not really needed, but it is specified by rfc4122 so at least =
in theory it may occur (in the future), and therefore the enum should have,=
 in my opinion, an enumerator for it.=C2=A0</div><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><span class=3D""><br>`uuid::uuid_con=
st_iterator` and `uuid::uuid_iterator` don&#39;t need to be in the specific=
ation. The type of the iterators can simply be specified as implementation-=
defined.<br></span><span class=3D"">=C2=A0 =C2=A0 typedef /*implementation-=
defined*/ iterator; // see [uuid]<br>=C2=A0 =C2=A0 using const_iterator =3D=
 implementation-defined; // see [uuid]</span></blockquote><div>=C2=A0 =C2=
=A0=C2=A0</div><div>That was my intention in the first place, but didn&#39;=
t put it in this form, but in something that looked more of a specification=
.. I changed it to what was suggested.</div><div><br></div><div><span class=
=3D"">

<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex" class=3D"gmail_quote">I don&#39;t think std::ha=
sh&lt;std::uuid&gt; should be string-based at all, but we&#39;re discussing=
 the proposal, and it doesn&#39;t need to suggest a particular implementati=
on of the specialization. In fact, I think it should *not* suggest a partic=
ular implementation.</blockquote><br class=3D"m_3843970509591103383gmail-Ap=
ple-interchange-newline"></span>

I am not suggesting any implementation. Yes, I did a string-based implement=
ation, but that doesn&#39;t mean it has to be so.</div><span class=3D""><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think `uuid=
_default_generator` still has to provide some guarantees on the produced UU=
IDs. Having a generator that produces noone knows what is hardly useful. I =
assume it is supposed to produce random UUIDs using some system-specific so=
urce of randomness, so why not say that? Also, if it is a random generator,=
 its name should reflect that.<br><br>Yes. Please never ever name anything =
&quot;default_&quot;-anything. There are two conflicting meanings for &quot=
;default_&quot; in the C++ standard:<br>(1) &quot;Default&quot; as in &quot=
;the best one to use.&quot; There will be a reason that it is the best one.=
 State that reason. For example, &quot;my::mt19937&quot; is a good name for=
 a default random number engine, and &quot;my::sha256&quot; is a good name =
for the default hash.<br>(2) &quot;Default&quot; as in &quot;implementation=
-defined.&quot; Such a typedef will never be used by anyone, because its be=
havior will not be portable. Prefer to eliminate such useless cruft from th=
e wording completely.</blockquote><div><br></div></span><div>I removed the =
uuid_default_generator completely from the specification. Although in my pa=
rticular implementation I still have that, I have renamed it to uuid_system=
_generator and explained it uses system resources for generating a UUID. Ho=
wever, it&#39;s not part of the library specification any more.</div></div>=
<div><br></div><div>I hope this addresses most of the last concerns.</div><=
span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>Marius</d=
iv></font></span></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Jan 25, 2018 at 2:1=
2 AM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D"mailto:arthur.j.o=
dwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Wed, Ja=
n 24, 2018 at 2:23 PM, Andrey Semashev <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gmail.com<=
/a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, Jan 25, 2018 =
at 12:02 AM, Edward Catmur &lt;<a href=3D"mailto:ed@catmur.co.uk" target=3D=
"_blank">ed@catmur.co.uk</a>&gt; wrote:<br>
&gt; On Tuesday, 23 January 2018 10:30:20 UTC+9, Andrey Semashev=C2=A0 wrot=
e:<br>
&gt;&gt;<br>
</span><span>&gt;&gt; I don&#39;t think std::hash&lt;std::uuid&gt; should b=
e string-based at all, but<br>
&gt;&gt; we&#39;re discussing the proposal, and it doesn&#39;t need to sugg=
est a<br>
&gt;&gt; particular implementation of the specialization. In fact, I think =
it<br>
&gt;&gt; should *not* suggest a particular implementation.<br>
&gt;<br>
&gt; Would it be acceptable to make it constexpr, noexcept or (preferably) =
both? That would preclude the slow, allocating stringstream approach withou=
t mandating any particular implementation.<br>
<br>
</span>I think, constexpr and noexcept would be nice regardless. They don&#=
39;t<br>
preclude a string-based implementation though, as one could generate a<br>
string in a local buffer. Not that I see why one would implement it<br>
that way.<span><br></span></blockquote><div><br></div></span><div>That&#39;=
s exactly what I meant by the suggestion</div><span><div><br></div><div><sp=
an style=3D"font-size:13px">&gt; &gt; Should there be a &quot;to_string&quo=
t; member function overload that takes a</span><br style=3D"font-size:13px"=
><span style=3D"font-size:13px">&gt; &gt; buffer-of-char and writes the res=
ult into it?<span class=3D"m_3843970509591103383m_8318511200263111284sew9yw=
gm8p2konq"></span><span class=3D"m_3843970509591103383m_8318511200263111284=
sewsor5h9kiz23z"></span></span><br></div><div><br></div></span><div>There p=
robably should be such a member function.</div><div><br></div><div>Either t=
hat, or<br></div><div>(A) uuid::operator&lt;&lt; should be specified not to=
 use heap-allocation, <b><i>and</i></b></div><div>(B) the standard should p=
rovide an allocator-aware version of std::ostringstream (<a href=3D"http://=
wg21.link/p0407" target=3D"_blank">P0407</a>),</div><div>which would let pe=
ople stringify a UUID to a local char buffer by jumping through only O(1) h=
oops.</div><div><br></div><div>=E2=80=93Arthur</div></div></div></div><span=
>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BPp40k0wLva_6iF1mApOeq0ycNt9=
4cjYeAUD-TC_XYNQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CADvuK0%2BPp40k0wLva_6iF1mApO<wbr>eq0ycNt94cjYeAUD-TC_XYNQ=
%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASwAinGU4xSiTO513TTU-47YKymHQC=
5YnBv_QidTa5Tt0A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASwAinGU=
4xSiTO513TTU-47YKymHQC5YnBv_QidTa5Tt0A%40mail.gmail.com</a>.<br />

--001a1140f5e63a0a380566c5671c--

.

--000000000000c2ced2056e917478
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The committee discussed this paper briefly on Saturday, at the very end of
the week.

Some comments (a mix of just my opinions, and LEWG comments)

- don't construct from a string_view.  Make that a "factory" function.  ie
a static member function uuid from_string(string_view).  Either return nil
uuid on error, or throw an exception. (Note that nil is a valid result, so
returning nil means you don't know if it is an error or a valid parse,
unfortunately.  Might also consider expected<uuid> but nothing else in the
STL uses expected (and it is not in the STL yet))
It should be a function because it is doing parsing, which feels more like
a function (takes input, gives output) than a constructor.

- construct from a fixed-size span<const std::byte, 16>. This makes "wrong
size" not your problem.
- not sure whether the iterator constructor should stay - I suppose it is
useful for non-contiguous cases.  Committee might make it UB if it is not
16 bytes.

- remove container-like stuff: size and iterators, typedefs, etc - just
have a to_span() function that returns a span<const std::byte, 16>
(it probably never should have had mutable iterators, btw - we don't want
to allow changing single bytes in a uuid)

Oh, wait - you were saying that the internal representation might not be
just bytes - is that important?
I think we need to standardize the order.  Construction from a sequence of
bytes should give the same uuid on all machines.

And we also need to define how the bytes turn into strings.

Basically, I would say the byte order turns directly into string order.
For bytes a,b,c,d... you get string "aabbccdd-eeff-gghh-iijj-kkllmmnnoopp"


- remove state_size.  sizeof(uuid) is good enough (Hmm, although it is
technically not guaranteed to be  =3D=3D 16, unless we add that in writing.
But it doesn't matter - use size() on the returned span)

- rename nil to is_nil (or remove altogether - checking =3D=3D {} works)

- add assignment from another uuid

- should be trivially copyable, etc


Basically, we want a class that is not much more than 16 bytes gathered
up.  They should almost always be treated as a whole, not parts.  So once
you have the unique bytes inside the uuid, you can be sure that they stay
unique (as unique as wherever you constructed them from).
The invariant of the class is the uniqueness.  You can't actually guarantee
that, but you can at least guarantee that a uuid (if not nil) _maintains_
the invariant, if you assume all uuids are correct on construction.

(Would be interesting to consider move-only, to maintain uniqueness)



On Tue, Mar 6, 2018 at 4:48 PM, Marius Bancila <marius.bancila@gmail.com>
wrote:

> My proposal on the uuid library, P0959R0
> <http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0959r0.md>, made it
> to the pre-Jacksonville mailing (https://isocpp.org/blog/2018/
> 02/2018-02-pre-jacksonville-mailing-available), but I cannot be there to
> present it. If anyone that will be there is interested in doing so, pleas=
e
> drop me a message.
>
> Thank you
>
> On Wed, Jan 31, 2018 at 9:44 AM, Marius Bancila <marius.bancila@gmail.com=
>
> wrote:
>
>> I got some good comments after the last update. I'll try to summarize th=
e
>> main points and answer here:
>>
>> The section "Iterators constructors" lists two examples, neither of whic=
h
>>> uses iterators to construct UUID.
>>
>>
>> That was a error after some edits. It's fixed.
>>
>> The "Capacity" section should probably be named "Size" since you describ=
e
>>> the `size` method there. Also, `nil` has nothing to do with size, and i=
ts
>>> description is better moved elsewhere.
>>
>>
>> Done. I made two sections, one called Size and one called Nil.
>>
>> I believe, `swap` should be overloaded, not specialized.
>>
>>
>> Done. I removed the specialization of swap and provided an overload.
>>
>> Why is `uuid_variant::future` needed?
>>
>>
>> It's actually called uuid_variant::reserved. It's not really needed, but
>> it is specified by rfc4122 so at least in theory it may occur (in the
>> future), and therefore the enum should have, in my opinion, an enumerato=
r
>> for it.
>>
>>
>>> `uuid::uuid_const_iterator` and `uuid::uuid_iterator` don't need to be
>>> in the specification. The type of the iterators can simply be specified=
 as
>>> implementation-defined.
>>>     typedef /*implementation-defined*/ iterator; // see [uuid]
>>>     using const_iterator =3D implementation-defined; // see [uuid]
>>
>>
>> That was my intention in the first place, but didn't put it in this form=
,
>> but in something that looked more of a specification. I changed it to wh=
at
>> was suggested.
>>
>> I don't think std::hash<std::uuid> should be string-based at all, but
>>> we're discussing the proposal, and it doesn't need to suggest a particu=
lar
>>> implementation of the specialization. In fact, I think it should *not*
>>> suggest a particular implementation.
>>
>>
>> I am not suggesting any implementation. Yes, I did a string-based
>> implementation, but that doesn't mean it has to be so.
>>
>> I think `uuid_default_generator` still has to provide some guarantees on
>>> the produced UUIDs. Having a generator that produces noone knows what i=
s
>>> hardly useful. I assume it is supposed to produce random UUIDs using so=
me
>>> system-specific source of randomness, so why not say that? Also, if it =
is a
>>> random generator, its name should reflect that.
>>>
>>> Yes. Please never ever name anything "default_"-anything. There are two
>>> conflicting meanings for "default_" in the C++ standard:
>>> (1) "Default" as in "the best one to use." There will be a reason that
>>> it is the best one. State that reason. For example, "my::mt19937" is a =
good
>>> name for a default random number engine, and "my::sha256" is a good nam=
e
>>> for the default hash.
>>> (2) "Default" as in "implementation-defined." Such a typedef will never
>>> be used by anyone, because its behavior will not be portable. Prefer to
>>> eliminate such useless cruft from the wording completely.
>>
>>
>> I removed the uuid_default_generator completely from the specification.
>> Although in my particular implementation I still have that, I have renam=
ed
>> it to uuid_system_generator and explained it uses system resources for
>> generating a UUID. However, it's not part of the library specification a=
ny
>> more.
>>
>> I hope this addresses most of the last concerns.
>>
>> Marius
>>
>> On Thu, Jan 25, 2018 at 2:12 AM, Arthur O'Dwyer <
>> arthur.j.odwyer@gmail.com> wrote:
>>
>>> On Wed, Jan 24, 2018 at 2:23 PM, Andrey Semashev <
>>> andrey.semashev@gmail.com> wrote:
>>>
>>>> On Thu, Jan 25, 2018 at 12:02 AM, Edward Catmur <ed@catmur.co.uk>
>>>> wrote:
>>>> > On Tuesday, 23 January 2018 10:30:20 UTC+9, Andrey Semashev  wrote:
>>>> >>
>>>> >> I don't think std::hash<std::uuid> should be string-based at all, b=
ut
>>>> >> we're discussing the proposal, and it doesn't need to suggest a
>>>> >> particular implementation of the specialization. In fact, I think i=
t
>>>> >> should *not* suggest a particular implementation.
>>>> >
>>>> > Would it be acceptable to make it constexpr, noexcept or (preferably=
)
>>>> both? That would preclude the slow, allocating stringstream approach
>>>> without mandating any particular implementation.
>>>>
>>>> I think, constexpr and noexcept would be nice regardless. They don't
>>>> preclude a string-based implementation though, as one could generate a
>>>> string in a local buffer. Not that I see why one would implement it
>>>> that way.
>>>>
>>>
>>> That's exactly what I meant by the suggestion
>>>
>>> > > Should there be a "to_string" member function overload that takes a
>>> > > buffer-of-char and writes the result into it?
>>>
>>> There probably should be such a member function.
>>>
>>> Either that, or
>>> (A) uuid::operator<< should be specified not to use heap-allocation,
>>> *and*
>>> (B) the standard should provide an allocator-aware version of
>>> std::ostringstream (P0407 <http://wg21.link/p0407>),
>>> which would let people stringify a UUID to a local char buffer by
>>> jumping through only O(1) hoops.
>>>
>>> =E2=80=93Arthur
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/CADvuK0%2BPp40k0wLva_6iF1mApO
>>> eq0ycNt94cjYeAUD-TC_XYNQ%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2=
BPp40k0wLva_6iF1mApOeq0ycNt94cjYeAUD-TC_XYNQ%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
>>> .
>>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CA%2BgtASwAinGU4xSiTO513TTU-
> 47YKymHQC5YnBv_QidTa5Tt0A%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASwA=
inGU4xSiTO513TTU-47YKymHQC5YnBv_QidTa5Tt0A%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>



--=20
Be seeing you,
Tony

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOHCbitwUMo2%3Dvp4_7AH_d3YfsYYpQn-81BWUE9VFXeVg=
4_GZA%40mail.gmail.com.

--000000000000c2ced2056e917478
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>The committee discussed this paper briefly on Saturda=
y, at the very end of the week.</div><div><br></div><div>Some comments (a m=
ix of just my opinions, and LEWG comments)</div><div><br></div><div>- don&#=
39;t construct from a string_view.=C2=A0 Make that a &quot;factory&quot; fu=
nction.=C2=A0 ie a static member function uuid from_string(string_view).=C2=
=A0 Either return nil uuid on error, or throw an exception. (Note that nil =
is a valid result, so returning nil means you don&#39;t know if it is an er=
ror or a valid parse, unfortunately.=C2=A0 Might also consider expected&lt;=
uuid&gt; but nothing else in the STL uses expected (and it is not in the ST=
L yet))</div><div>It should be a function because it is doing parsing, whic=
h feels more like a function (takes input, gives output) than a constructor=
..</div><div><br></div><div>- construct from a fixed-size span&lt;const std:=
:byte, 16&gt;. This makes &quot;wrong size&quot; not your problem.<br></div=
><div>- not sure whether the iterator constructor should stay - I suppose i=
t is useful for non-contiguous cases.=C2=A0 Committee might make it UB if i=
t is not 16 bytes.</div><div><br></div><div>- remove container-like stuff: =
size and iterators, typedefs, etc - just have a to_span() function that ret=
urns a span&lt;const std::byte, 16&gt;</div><div>(it probably never should =
have had mutable iterators, btw - we don&#39;t want to allow changing singl=
e bytes in a uuid)</div><div><br></div><div>Oh, wait - you were saying that=
 the internal representation might not be just bytes - is that important?</=
div><div>I think we need to standardize the order.=C2=A0 Construction from =
a sequence of bytes should give the same uuid on all machines.<br></div><di=
v><br></div><div>And we also need to define how the bytes turn into strings=
..</div><div><br></div><div>Basically, I would say the byte order turns dire=
ctly into string order.=C2=A0 For bytes a,b,c,d... you get string &quot;aab=
bccdd-eeff-gghh-iijj-kkllmmnnoopp&quot;</div><div><br></div><div><br></div>=
<div>- remove state_size.=C2=A0 sizeof(uuid) is good enough (Hmm, although =
it is technically not guaranteed to be=C2=A0 =3D=3D 16, unless we add that =
in writing.=C2=A0 But it doesn&#39;t matter - use size() on the returned sp=
an)</div><div><br></div><div>- rename nil to is_nil (or remove altogether -=
 checking =3D=3D {} works)<br></div><div><br></div><div>- add assignment fr=
om another uuid<br></div><div><br></div><div>- should be trivially copyable=
, etc<br></div><div><br></div><div><br></div><div>Basically, we want a clas=
s that is not much more than 16 bytes gathered up.=C2=A0 They should almost=
 always be treated as a whole, not parts.=C2=A0 So once you have the unique=
 bytes inside the uuid, you can be sure that they stay unique (as unique as=
 wherever you constructed them from).</div><div>The invariant of the class =
is the uniqueness.=C2=A0 You can&#39;t actually guarantee that, but you can=
 at least guarantee that a uuid (if not nil) _maintains_ the invariant, if =
you assume all uuids are correct on construction.<br></div><div><br></div><=
div>(Would be interesting to consider move-only, to maintain uniqueness)<br=
></div><div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On Tue, Mar 6, 2018 at 4:48 PM, Marius Bancila <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:marius.bancila@gmail.com" target=3D"_=
blank">marius.bancila@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">My proposal on the uuid library,=C2=A0<a hre=
f=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0959r0.md" target=
=3D"_blank">P0959R0</a>, made it to the pre-Jacksonville mailing (<a href=
=3D"https://isocpp.org/blog/2018/02/2018-02-pre-jacksonville-mailing-availa=
ble" target=3D"_blank">https://isocpp.org/blog/2018/<wbr>02/2018-02-pre-jac=
ksonville-<wbr>mailing-available</a>), but I cannot be there to present it.=
 If anyone that will be there is interested in doing so, please drop me a m=
essage.<div><br></div><div>Thank you</div></div><div><div class=3D"h5"><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jan 31, 2018 =
at 9:44 AM, Marius Bancila <span dir=3D"ltr">&lt;<a href=3D"mailto:marius.b=
ancila@gmail.com" target=3D"_blank">marius.bancila@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I got some good =
comments after the last update. I&#39;ll try to summarize the main points a=
nd answer here:<div><br></div><div><span><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">The section &quot;Iterators constructors&quot; lists two ex=
amples, neither of which uses iterators to construct UUID.</blockquote><div=
><br></div></span><div>That was a error after some edits. It&#39;s fixed.</=
div><span><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
The &quot;Capacity&quot; section should probably be named &quot;Size&quot; =
since you describe the `size` method there. Also, `nil` has nothing to do w=
ith size, and its description is better moved elsewhere.</blockquote><div><=
br></div></span><div>Done. I made two sections, one called Size and one cal=
led Nil.</div><span><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">I believe, `swap` should be overloaded, not specialized.</blockq=
uote><div><br></div></span><div>Done. I removed the specialization of swap =
and provided an overload.</div><span><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">Why is `uuid_variant::future` needed?</blockquot=
e><div><br></div></span><div>It&#39;s actually called <font face=3D"monospa=
ce, monospace">uuid_variant::reserved</font>. It&#39;s not really needed, b=
ut it is specified by rfc4122 so at least in theory it may occur (in the fu=
ture), and therefore the enum should have, in my opinion, an enumerator for=
 it.=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><span><br>`uuid::uuid_const_iterator` and `uuid::uuid_iterator` don&#=
39;t need to be in the specification. The type of the iterators can simply =
be specified as implementation-defined.<br></span><span>=C2=A0 =C2=A0 typed=
ef /*implementation-defined*/ iterator; // see [uuid]<br>=C2=A0 =C2=A0 usin=
g const_iterator =3D implementation-defined; // see [uuid]</span></blockquo=
te><div>=C2=A0 =C2=A0=C2=A0</div><div>That was my intention in the first pl=
ace, but didn&#39;t put it in this form, but in something that looked more =
of a specification. I changed it to what was suggested.</div><div><br></div=
><div><span>

<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex" class=3D"gmail_quote">I don&#39;t think std::ha=
sh&lt;std::uuid&gt; should be string-based at all, but we&#39;re discussing=
 the proposal, and it doesn&#39;t need to suggest a particular implementati=
on of the specialization. In fact, I think it should *not* suggest a partic=
ular implementation.</blockquote><br class=3D"m_-7293019058525120346m_38439=
70509591103383gmail-Apple-interchange-newline"></span>

I am not suggesting any implementation. Yes, I did a string-based implement=
ation, but that doesn&#39;t mean it has to be so.</div><span><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">I think `uuid_default_ge=
nerator` still has to provide some guarantees on the produced UUIDs. Having=
 a generator that produces noone knows what is hardly useful. I assume it i=
s supposed to produce random UUIDs using some system-specific source of ran=
domness, so why not say that? Also, if it is a random generator, its name s=
hould reflect that.<br><br>Yes. Please never ever name anything &quot;defau=
lt_&quot;-anything. There are two conflicting meanings for &quot;default_&q=
uot; in the C++ standard:<br>(1) &quot;Default&quot; as in &quot;the best o=
ne to use.&quot; There will be a reason that it is the best one. State that=
 reason. For example, &quot;my::mt19937&quot; is a good name for a default =
random number engine, and &quot;my::sha256&quot; is a good name for the def=
ault hash.<br>(2) &quot;Default&quot; as in &quot;implementation-defined.&q=
uot; Such a typedef will never be used by anyone, because its behavior will=
 not be portable. Prefer to eliminate such useless cruft from the wording c=
ompletely.</blockquote><div><br></div></span><div>I removed the uuid_defaul=
t_generator completely from the specification. Although in my particular im=
plementation I still have that, I have renamed it to uuid_system_generator =
and explained it uses system resources for generating a UUID. However, it&#=
39;s not part of the library specification any more.</div></div><div><br></=
div><div>I hope this addresses most of the last concerns.</div><span class=
=3D"m_-7293019058525120346HOEnZb"><font color=3D"#888888"><div><br></div><d=
iv>Marius</div></font></span></div><div class=3D"m_-7293019058525120346HOEn=
Zb"><div class=3D"m_-7293019058525120346h5"><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">On Thu, Jan 25, 2018 at 2:12 AM, Arthur O&#39;Dw=
yer <span dir=3D"ltr">&lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" targ=
et=3D"_blank">arthur.j.odwyer@gmail.com</a>&gt;</span> wrote:<br><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"><span>On Wed, Jan 24, 2018 at 2:23 PM=
, Andrey Semashev <span dir=3D"ltr">&lt;<a href=3D"mailto:andrey.semashev@g=
mail.com" target=3D"_blank">andrey.semashev@gmail.com</a>&gt;</span> wrote:=
<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><span>On Thu, Jan 25, 2018 at 12:02 AM, Edward C=
atmur &lt;<a href=3D"mailto:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co=
..uk</a>&gt; wrote:<br>
&gt; On Tuesday, 23 January 2018 10:30:20 UTC+9, Andrey Semashev=C2=A0 wrot=
e:<br>
&gt;&gt;<br>
</span><span>&gt;&gt; I don&#39;t think std::hash&lt;std::uuid&gt; should b=
e string-based at all, but<br>
&gt;&gt; we&#39;re discussing the proposal, and it doesn&#39;t need to sugg=
est a<br>
&gt;&gt; particular implementation of the specialization. In fact, I think =
it<br>
&gt;&gt; should *not* suggest a particular implementation.<br>
&gt;<br>
&gt; Would it be acceptable to make it constexpr, noexcept or (preferably) =
both? That would preclude the slow, allocating stringstream approach withou=
t mandating any particular implementation.<br>
<br>
</span>I think, constexpr and noexcept would be nice regardless. They don&#=
39;t<br>
preclude a string-based implementation though, as one could generate a<br>
string in a local buffer. Not that I see why one would implement it<br>
that way.<span><br></span></blockquote><div><br></div></span><div>That&#39;=
s exactly what I meant by the suggestion</div><span><div><br></div><div><sp=
an style=3D"font-size:13px">&gt; &gt; Should there be a &quot;to_string&quo=
t; member function overload that takes a</span><br style=3D"font-size:13px"=
><span style=3D"font-size:13px">&gt; &gt; buffer-of-char and writes the res=
ult into it?<span class=3D"m_-7293019058525120346m_3843970509591103383m_831=
8511200263111284sew9ywgm8p2konq"></span><span class=3D"m_-72930190585251203=
46m_3843970509591103383m_8318511200263111284sewsor5h9kiz23z"></span></span>=
<br></div><div><br></div></span><div>There probably should be such a member=
 function.</div><div><br></div><div>Either that, or<br></div><div>(A) uuid:=
:operator&lt;&lt; should be specified not to use heap-allocation, <b><i>and=
</i></b></div><div>(B) the standard should provide an allocator-aware versi=
on of std::ostringstream (<a href=3D"http://wg21.link/p0407" target=3D"_bla=
nk">P0407</a>),</div><div>which would let people stringify a UUID to a loca=
l char buffer by jumping through only O(1) hoops.</div><div><br></div><div>=
=E2=80=93Arthur</div></div></div></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BPp40k0wLva_6iF1mApOeq0ycNt9=
4cjYeAUD-TC_XYNQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CADvuK0%2BPp40k0wLva_6iF1mApO<wbr>eq0ycNt94cjYeAUD-TC_XYNQ=
%40mai<wbr>l.gmail.com</a>.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASwAinGU4xSiTO513TTU-47YKymHQC=
5YnBv_QidTa5Tt0A%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CA%<wbr>2BgtASwAinGU4xSiTO513TTU-<wbr>47YKymHQC5YnBv_QidTa=
5Tt0A%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbitwUMo2%3Dvp4_7AH_d3YfsYYpQn-81=
BWUE9VFXeVg4_GZA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitwUMo2%3=
Dvp4_7AH_d3YfsYYpQn-81BWUE9VFXeVg4_GZA%40mail.gmail.com</a>.<br />

--000000000000c2ced2056e917478--

.

--000000000000103c2c056e9239fa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for the follow-up, Tony. I'm sure Marius appreciates :)

2018-06-13 23:11 GMT-04:00 Tony V E <tvaneerd@gmail.com>:

> The committee discussed this paper briefly on Saturday, at the very end o=
f
> the week.
>
> Some comments (a mix of just my opinions, and LEWG comments)
>
> - don't construct from a string_view.  Make that a "factory" function.  i=
e
> a static member function uuid from_string(string_view).  Either return ni=
l
> uuid on error, or throw an exception. (Note that nil is a valid result, s=
o
> returning nil means you don't know if it is an error or a valid parse,
> unfortunately.  Might also consider expected<uuid> but nothing else in th=
e
> STL uses expected (and it is not in the STL yet))
> It should be a function because it is doing parsing, which feels more lik=
e
> a function (takes input, gives output) than a constructor.
>
> - construct from a fixed-size span<const std::byte, 16>. This makes "wron=
g
> size" not your problem.
> - not sure whether the iterator constructor should stay - I suppose it is
> useful for non-contiguous cases.  Committee might make it UB if it is not
> 16 bytes.
>
> - remove container-like stuff: size and iterators, typedefs, etc - just
> have a to_span() function that returns a span<const std::byte, 16>
> (it probably never should have had mutable iterators, btw - we don't want
> to allow changing single bytes in a uuid)
>
> Oh, wait - you were saying that the internal representation might not be
> just bytes - is that important?
> I think we need to standardize the order.  Construction from a sequence o=
f
> bytes should give the same uuid on all machines.
>
> And we also need to define how the bytes turn into strings.
>
> Basically, I would say the byte order turns directly into string order.
> For bytes a,b,c,d... you get string "aabbccdd-eeff-gghh-iijj-kkllmmnnoopp=
"
>
>
> - remove state_size.  sizeof(uuid) is good enough (Hmm, although it is
> technically not guaranteed to be  =3D=3D 16, unless we add that in writin=
g.
> But it doesn't matter - use size() on the returned span)
>
> - rename nil to is_nil (or remove altogether - checking =3D=3D {} works)
>
> - add assignment from another uuid
>
> - should be trivially copyable, etc
>
>
> Basically, we want a class that is not much more than 16 bytes gathered
> up.  They should almost always be treated as a whole, not parts.  So once
> you have the unique bytes inside the uuid, you can be sure that they stay
> unique (as unique as wherever you constructed them from).
> The invariant of the class is the uniqueness.  You can't actually
> guarantee that, but you can at least guarantee that a uuid (if not nil)
> _maintains_ the invariant, if you assume all uuids are correct on
> construction.
>
> (Would be interesting to consider move-only, to maintain uniqueness)
>
>
>
> On Tue, Mar 6, 2018 at 4:48 PM, Marius Bancila <marius.bancila@gmail.com>
> wrote:
>
>> My proposal on the uuid library, P0959R0
>> <http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0959r0.md>, made
>> it to the pre-Jacksonville mailing (https://isocpp.org/blog/2018/
>> 02/2018-02-pre-jacksonville-mailing-available), but I cannot be there to
>> present it. If anyone that will be there is interested in doing so, plea=
se
>> drop me a message.
>>
>> Thank you
>>
>> On Wed, Jan 31, 2018 at 9:44 AM, Marius Bancila <marius.bancila@gmail.co=
m
>> > wrote:
>>
>>> I got some good comments after the last update. I'll try to summarize
>>> the main points and answer here:
>>>
>>> The section "Iterators constructors" lists two examples, neither of
>>>> which uses iterators to construct UUID.
>>>
>>>
>>> That was a error after some edits. It's fixed.
>>>
>>> The "Capacity" section should probably be named "Size" since you
>>>> describe the `size` method there. Also, `nil` has nothing to do with s=
ize,
>>>> and its description is better moved elsewhere.
>>>
>>>
>>> Done. I made two sections, one called Size and one called Nil.
>>>
>>> I believe, `swap` should be overloaded, not specialized.
>>>
>>>
>>> Done. I removed the specialization of swap and provided an overload.
>>>
>>> Why is `uuid_variant::future` needed?
>>>
>>>
>>> It's actually called uuid_variant::reserved. It's not really needed,
>>> but it is specified by rfc4122 so at least in theory it may occur (in t=
he
>>> future), and therefore the enum should have, in my opinion, an enumerat=
or
>>> for it.
>>>
>>>
>>>> `uuid::uuid_const_iterator` and `uuid::uuid_iterator` don't need to be
>>>> in the specification. The type of the iterators can simply be specifie=
d as
>>>> implementation-defined.
>>>>     typedef /*implementation-defined*/ iterator; // see [uuid]
>>>>     using const_iterator =3D implementation-defined; // see [uuid]
>>>
>>>
>>> That was my intention in the first place, but didn't put it in this
>>> form, but in something that looked more of a specification. I changed i=
t to
>>> what was suggested.
>>>
>>> I don't think std::hash<std::uuid> should be string-based at all, but
>>>> we're discussing the proposal, and it doesn't need to suggest a partic=
ular
>>>> implementation of the specialization. In fact, I think it should *not*
>>>> suggest a particular implementation.
>>>
>>>
>>> I am not suggesting any implementation. Yes, I did a string-based
>>> implementation, but that doesn't mean it has to be so.
>>>
>>> I think `uuid_default_generator` still has to provide some guarantees o=
n
>>>> the produced UUIDs. Having a generator that produces noone knows what =
is
>>>> hardly useful. I assume it is supposed to produce random UUIDs using s=
ome
>>>> system-specific source of randomness, so why not say that? Also, if it=
 is a
>>>> random generator, its name should reflect that.
>>>>
>>>> Yes. Please never ever name anything "default_"-anything. There are tw=
o
>>>> conflicting meanings for "default_" in the C++ standard:
>>>> (1) "Default" as in "the best one to use." There will be a reason that
>>>> it is the best one. State that reason. For example, "my::mt19937" is a=
 good
>>>> name for a default random number engine, and "my::sha256" is a good na=
me
>>>> for the default hash.
>>>> (2) "Default" as in "implementation-defined." Such a typedef will neve=
r
>>>> be used by anyone, because its behavior will not be portable. Prefer t=
o
>>>> eliminate such useless cruft from the wording completely.
>>>
>>>
>>> I removed the uuid_default_generator completely from the specification.
>>> Although in my particular implementation I still have that, I have rena=
med
>>> it to uuid_system_generator and explained it uses system resources for
>>> generating a UUID. However, it's not part of the library specification =
any
>>> more.
>>>
>>> I hope this addresses most of the last concerns.
>>>
>>> Marius
>>>
>>> On Thu, Jan 25, 2018 at 2:12 AM, Arthur O'Dwyer <
>>> arthur.j.odwyer@gmail.com> wrote:
>>>
>>>> On Wed, Jan 24, 2018 at 2:23 PM, Andrey Semashev <
>>>> andrey.semashev@gmail.com> wrote:
>>>>
>>>>> On Thu, Jan 25, 2018 at 12:02 AM, Edward Catmur <ed@catmur.co.uk>
>>>>> wrote:
>>>>> > On Tuesday, 23 January 2018 10:30:20 UTC+9, Andrey Semashev  wrote:
>>>>> >>
>>>>> >> I don't think std::hash<std::uuid> should be string-based at all,
>>>>> but
>>>>> >> we're discussing the proposal, and it doesn't need to suggest a
>>>>> >> particular implementation of the specialization. In fact, I think =
it
>>>>> >> should *not* suggest a particular implementation.
>>>>> >
>>>>> > Would it be acceptable to make it constexpr, noexcept or
>>>>> (preferably) both? That would preclude the slow, allocating stringstr=
eam
>>>>> approach without mandating any particular implementation.
>>>>>
>>>>> I think, constexpr and noexcept would be nice regardless. They don't
>>>>> preclude a string-based implementation though, as one could generate =
a
>>>>> string in a local buffer. Not that I see why one would implement it
>>>>> that way.
>>>>>
>>>>
>>>> That's exactly what I meant by the suggestion
>>>>
>>>> > > Should there be a "to_string" member function overload that takes =
a
>>>> > > buffer-of-char and writes the result into it?
>>>>
>>>> There probably should be such a member function.
>>>>
>>>> Either that, or
>>>> (A) uuid::operator<< should be specified not to use heap-allocation,
>>>> *and*
>>>> (B) the standard should provide an allocator-aware version of
>>>> std::ostringstream (P0407 <http://wg21.link/p0407>),
>>>> which would let people stringify a UUID to a local char buffer by
>>>> jumping through only O(1) hoops.
>>>>
>>>> =E2=80=93Arthur
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to std-proposals+unsubscribe@isocpp.org.
>>>> To post to this group, send email to std-proposals@isocpp.org.
>>>> To view this discussion on the web visit https://groups.google.com/a/i=
s
>>>> ocpp.org/d/msgid/std-proposals/CADvuK0%2BPp40k0wLva_6iF1mApO
>>>> eq0ycNt94cjYeAUD-TC_XYNQ%40mail.gmail.com
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%=
2BPp40k0wLva_6iF1mApOeq0ycNt94cjYeAUD-TC_XYNQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>>>> .
>>>>
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/CA%2BgtASwAinGU4xSiTO513TTU-4
>> 7YKymHQC5YnBv_QidTa5Tt0A%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASw=
AinGU4xSiTO513TTU-47YKymHQC5YnBv_QidTa5Tt0A%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>> .
>>
>
>
>
> --
> Be seeing you,
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAOHCbitwUMo2%3Dvp4_
> 7AH_d3YfsYYpQn-81BWUE9VFXeVg4_GZA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitwUM=
o2%3Dvp4_7AH_d3YfsYYpQn-81BWUE9VFXeVg4_GZA%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKiZDp1vPCGRJFrzey4AYJ-Jq%3Di555VFYSLC8wcZ-5LjK=
o1m6w%40mail.gmail.com.

--000000000000103c2c056e9239fa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for the follow-up, Tony. I&#39;m sure Marius apprec=
iates :)<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>2018-06-13 23:11 GMT-04:00 Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span>:<=
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>The committee discu=
ssed this paper briefly on Saturday, at the very end of the week.</div><div=
><br></div><div>Some comments (a mix of just my opinions, and LEWG comments=
)</div><div><br></div><div>- don&#39;t construct from a string_view.=C2=A0 =
Make that a &quot;factory&quot; function.=C2=A0 ie a static member function=
 uuid from_string(string_view).=C2=A0 Either return nil uuid on error, or t=
hrow an exception. (Note that nil is a valid result, so returning nil means=
 you don&#39;t know if it is an error or a valid parse, unfortunately.=C2=
=A0 Might also consider expected&lt;uuid&gt; but nothing else in the STL us=
es expected (and it is not in the STL yet))</div><div>It should be a functi=
on because it is doing parsing, which feels more like a function (takes inp=
ut, gives output) than a constructor.</div><div><br></div><div>- construct =
from a fixed-size span&lt;const std::byte, 16&gt;. This makes &quot;wrong s=
ize&quot; not your problem.<br></div><div>- not sure whether the iterator c=
onstructor should stay - I suppose it is useful for non-contiguous cases.=
=C2=A0 Committee might make it UB if it is not 16 bytes.</div><div><br></di=
v><div>- remove container-like stuff: size and iterators, typedefs, etc - j=
ust have a to_span() function that returns a span&lt;const std::byte, 16&gt=
;</div><div>(it probably never should have had mutable iterators, btw - we =
don&#39;t want to allow changing single bytes in a uuid)</div><div><br></di=
v><div>Oh, wait - you were saying that the internal representation might no=
t be just bytes - is that important?</div><div>I think we need to standardi=
ze the order.=C2=A0 Construction from a sequence of bytes should give the s=
ame uuid on all machines.<br></div><div><br></div><div>And we also need to =
define how the bytes turn into strings.</div><div><br></div><div>Basically,=
 I would say the byte order turns directly into string order.=C2=A0 For byt=
es a,b,c,d... you get string &quot;aabbccdd-eeff-gghh-iijj-<wbr>kkllmmnnoop=
p&quot;</div><div><br></div><div><br></div><div>- remove state_size.=C2=A0 =
sizeof(uuid) is good enough (Hmm, although it is technically not guaranteed=
 to be=C2=A0 =3D=3D 16, unless we add that in writing.=C2=A0 But it doesn&#=
39;t matter - use size() on the returned span)</div><div><br></div><div>- r=
ename nil to is_nil (or remove altogether - checking =3D=3D {} works)<br></=
div><div><br></div><div>- add assignment from another uuid<br></div><div><b=
r></div><div>- should be trivially copyable, etc<br></div><div><br></div><d=
iv><br></div><div>Basically, we want a class that is not much more than 16 =
bytes gathered up.=C2=A0 They should almost always be treated as a whole, n=
ot parts.=C2=A0 So once you have the unique bytes inside the uuid, you can =
be sure that they stay unique (as unique as wherever you constructed them f=
rom).</div><div>The invariant of the class is the uniqueness.=C2=A0 You can=
&#39;t actually guarantee that, but you can at least guarantee that a uuid =
(if not nil) _maintains_ the invariant, if you assume all uuids are correct=
 on construction.<br></div><div><br></div><div>(Would be interesting to con=
sider move-only, to maintain uniqueness)<br></div><div><br></div><div><br><=
/div></div><div class=3D"gmail_extra"><div><div class=3D"h5"><br><div class=
=3D"gmail_quote">On Tue, Mar 6, 2018 at 4:48 PM, Marius Bancila <span dir=
=3D"ltr">&lt;<a href=3D"mailto:marius.bancila@gmail.com" target=3D"_blank">=
marius.bancila@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">My proposal on the uuid library,=C2=A0<a href=3D"htt=
p://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0959r0.md" target=3D"_bla=
nk">P0959R0</a>, made it to the pre-Jacksonville mailing (<a href=3D"https:=
//isocpp.org/blog/2018/02/2018-02-pre-jacksonville-mailing-available" targe=
t=3D"_blank">https://isocpp.org/blog/2018/<wbr>02/2018-02-pre-jacksonville-=
ma<wbr>iling-available</a>), but I cannot be there to present it. If anyone=
 that will be there is interested in doing so, please drop me a message.<di=
v><br></div><div>Thank you</div></div><div><div class=3D"m_7941487392382346=
079h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Ja=
n 31, 2018 at 9:44 AM, Marius Bancila <span dir=3D"ltr">&lt;<a href=3D"mail=
to:marius.bancila@gmail.com" target=3D"_blank">marius.bancila@gmail.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I got=
 some good comments after the last update. I&#39;ll try to summarize the ma=
in points and answer here:<div><br></div><div><span><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">The section &quot;Iterators constructors&quot; l=
ists two examples, neither of which uses iterators to construct UUID.</bloc=
kquote><div><br></div></span><div>That was a error after some edits. It&#39=
;s fixed.</div><span><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">The &quot;Capacity&quot; section should probably be named &quot;=
Size&quot; since you describe the `size` method there. Also, `nil` has noth=
ing to do with size, and its description is better moved elsewhere.</blockq=
uote><div><br></div></span><div>Done. I made two sections, one called Size =
and one called Nil.</div><span><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">I believe, `swap` should be overloaded, not specialize=
d.</blockquote><div><br></div></span><div>Done. I removed the specializatio=
n of swap and provided an overload.</div><span><div><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">Why is `uuid_variant::future` needed?<=
/blockquote><div><br></div></span><div>It&#39;s actually called <font face=
=3D"monospace, monospace">uuid_variant::reserved</font>. It&#39;s not reall=
y needed, but it is specified by rfc4122 so at least in theory it may occur=
 (in the future), and therefore the enum should have, in my opinion, an enu=
merator for it.=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><span><br>`uuid::uuid_const_iterator` and `uuid::uuid_iter=
ator` don&#39;t need to be in the specification. The type of the iterators =
can simply be specified as implementation-defined.<br></span><span>=C2=A0 =
=C2=A0 typedef /*implementation-defined*/ iterator; // see [uuid]<br>=C2=A0=
 =C2=A0 using const_iterator =3D implementation-defined; // see [uuid]</spa=
n></blockquote><div>=C2=A0 =C2=A0=C2=A0</div><div>That was my intention in =
the first place, but didn&#39;t put it in this form, but in something that =
looked more of a specification. I changed it to what was suggested.</div><d=
iv><br></div><div><span>

<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex" class=3D"gmail_quote">I don&#39;t think std::ha=
sh&lt;std::uuid&gt; should be string-based at all, but we&#39;re discussing=
 the proposal, and it doesn&#39;t need to suggest a particular implementati=
on of the specialization. In fact, I think it should *not* suggest a partic=
ular implementation.</blockquote><br class=3D"m_7941487392382346079m_-72930=
19058525120346m_3843970509591103383gmail-Apple-interchange-newline"></span>

I am not suggesting any implementation. Yes, I did a string-based implement=
ation, but that doesn&#39;t mean it has to be so.</div><span><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">I think `uuid_default_ge=
nerator` still has to provide some guarantees on the produced UUIDs. Having=
 a generator that produces noone knows what is hardly useful. I assume it i=
s supposed to produce random UUIDs using some system-specific source of ran=
domness, so why not say that? Also, if it is a random generator, its name s=
hould reflect that.<br><br>Yes. Please never ever name anything &quot;defau=
lt_&quot;-anything. There are two conflicting meanings for &quot;default_&q=
uot; in the C++ standard:<br>(1) &quot;Default&quot; as in &quot;the best o=
ne to use.&quot; There will be a reason that it is the best one. State that=
 reason. For example, &quot;my::mt19937&quot; is a good name for a default =
random number engine, and &quot;my::sha256&quot; is a good name for the def=
ault hash.<br>(2) &quot;Default&quot; as in &quot;implementation-defined.&q=
uot; Such a typedef will never be used by anyone, because its behavior will=
 not be portable. Prefer to eliminate such useless cruft from the wording c=
ompletely.</blockquote><div><br></div></span><div>I removed the uuid_defaul=
t_generator completely from the specification. Although in my particular im=
plementation I still have that, I have renamed it to uuid_system_generator =
and explained it uses system resources for generating a UUID. However, it&#=
39;s not part of the library specification any more.</div></div><div><br></=
div><div>I hope this addresses most of the last concerns.</div><span class=
=3D"m_7941487392382346079m_-7293019058525120346HOEnZb"><font color=3D"#8888=
88"><div><br></div><div>Marius</div></font></span></div><div class=3D"m_794=
1487392382346079m_-7293019058525120346HOEnZb"><div class=3D"m_7941487392382=
346079m_-7293019058525120346h5"><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Thu, Jan 25, 2018 at 2:12 AM, Arthur O&#39;Dwyer <span =
dir=3D"ltr">&lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_bla=
nk">arthur.j.odwyer@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><span>On Wed, Jan 24, 2018 at 2:23 PM, Andrey S=
emashev <span dir=3D"ltr">&lt;<a href=3D"mailto:andrey.semashev@gmail.com" =
target=3D"_blank">andrey.semashev@gmail.com</a>&gt;</span> wrote:<br></span=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><span>On Thu, Jan 25, 2018 at 12:02 AM, Edward Catmur &lt;=
<a href=3D"mailto:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co.uk</a>&gt=
; wrote:<br>
&gt; On Tuesday, 23 January 2018 10:30:20 UTC+9, Andrey Semashev=C2=A0 wrot=
e:<br>
&gt;&gt;<br>
</span><span>&gt;&gt; I don&#39;t think std::hash&lt;std::uuid&gt; should b=
e string-based at all, but<br>
&gt;&gt; we&#39;re discussing the proposal, and it doesn&#39;t need to sugg=
est a<br>
&gt;&gt; particular implementation of the specialization. In fact, I think =
it<br>
&gt;&gt; should *not* suggest a particular implementation.<br>
&gt;<br>
&gt; Would it be acceptable to make it constexpr, noexcept or (preferably) =
both? That would preclude the slow, allocating stringstream approach withou=
t mandating any particular implementation.<br>
<br>
</span>I think, constexpr and noexcept would be nice regardless. They don&#=
39;t<br>
preclude a string-based implementation though, as one could generate a<br>
string in a local buffer. Not that I see why one would implement it<br>
that way.<span><br></span></blockquote><div><br></div></span><div>That&#39;=
s exactly what I meant by the suggestion</div><span><div><br></div><div><sp=
an style=3D"font-size:13px">&gt; &gt; Should there be a &quot;to_string&quo=
t; member function overload that takes a</span><br style=3D"font-size:13px"=
><span style=3D"font-size:13px">&gt; &gt; buffer-of-char and writes the res=
ult into it?<span class=3D"m_7941487392382346079m_-7293019058525120346m_384=
3970509591103383m_8318511200263111284sew9ywgm8p2konq"></span><span class=3D=
"m_7941487392382346079m_-7293019058525120346m_3843970509591103383m_83185112=
00263111284sewsor5h9kiz23z"></span></span><br></div><div><br></div></span><=
div>There probably should be such a member function.</div><div><br></div><d=
iv>Either that, or<br></div><div>(A) uuid::operator&lt;&lt; should be speci=
fied not to use heap-allocation, <b><i>and</i></b></div><div>(B) the standa=
rd should provide an allocator-aware version of std::ostringstream (<a href=
=3D"http://wg21.link/p0407" target=3D"_blank">P0407</a>),</div><div>which w=
ould let people stringify a UUID to a local char buffer by jumping through =
only O(1) hoops.</div><div><br></div><div>=E2=80=93Arthur</div></div></div>=
</div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BPp40k0wLva_6iF1mApOeq0ycNt9=
4cjYeAUD-TC_XYNQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CADvuK0%2BPp40k0wLva_6iF1mApO<wbr>eq0ycNt94cjYeAUD-TC_XYNQ=
%40mai<wbr>l.gmail.com</a>.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASwAinGU4xSiTO513TTU-47YKymHQC=
5YnBv_QidTa5Tt0A%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CA%2BgtASwAinGU4xSiTO513TTU-4<wbr>7YKymHQC5YnBv_QidTa5Tt0A=
%40mai<wbr>l.gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br></div></div>-- <br><div class=
=3D"m_7941487392382346079gmail_signature" data-smartmail=3D"gmail_signature=
"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbitwUMo2%3Dvp4_7AH_d3YfsYYpQn-81=
BWUE9VFXeVg4_GZA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CAOHCbitwUMo2%3Dvp4_<wbr>7AH_d3YfsYYpQn-81BWUE9VFXeVg4_<wb=
r>GZA%40mail.gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1vPCGRJFrzey4AYJ-Jq%3Di555VFYS=
LC8wcZ-5LjKo1m6w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1vPCGRJF=
rzey4AYJ-Jq%3Di555VFYSLC8wcZ-5LjKo1m6w%40mail.gmail.com</a>.<br />

--000000000000103c2c056e9239fa--

.

--0000000000003dcc04056e93cc9a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you for the feedback. I will work it out following the comments.

As a side note, I have already renamed nil() to is_nil(), although I did
not submitted an update of the paper only for that, as I wanted to get this
kind of feedback first.

Marius

On Thu, Jun 14, 2018 at 6:11 AM Tony V E <tvaneerd@gmail.com> wrote:

> The committee discussed this paper briefly on Saturday, at the very end o=
f
> the week.
>
> Some comments (a mix of just my opinions, and LEWG comments)
>
> - don't construct from a string_view.  Make that a "factory" function.  i=
e
> a static member function uuid from_string(string_view).  Either return ni=
l
> uuid on error, or throw an exception. (Note that nil is a valid result, s=
o
> returning nil means you don't know if it is an error or a valid parse,
> unfortunately.  Might also consider expected<uuid> but nothing else in th=
e
> STL uses expected (and it is not in the STL yet))
> It should be a function because it is doing parsing, which feels more lik=
e
> a function (takes input, gives output) than a constructor.
>
> - construct from a fixed-size span<const std::byte, 16>. This makes "wron=
g
> size" not your problem.
> - not sure whether the iterator constructor should stay - I suppose it is
> useful for non-contiguous cases.  Committee might make it UB if it is not
> 16 bytes.
>
> - remove container-like stuff: size and iterators, typedefs, etc - just
> have a to_span() function that returns a span<const std::byte, 16>
> (it probably never should have had mutable iterators, btw - we don't want
> to allow changing single bytes in a uuid)
>
> Oh, wait - you were saying that the internal representation might not be
> just bytes - is that important?
> I think we need to standardize the order.  Construction from a sequence o=
f
> bytes should give the same uuid on all machines.
>
> And we also need to define how the bytes turn into strings.
>
> Basically, I would say the byte order turns directly into string order.
> For bytes a,b,c,d... you get string "aabbccdd-eeff-gghh-iijj-kkllmmnnoopp=
"
>
>
> - remove state_size.  sizeof(uuid) is good enough (Hmm, although it is
> technically not guaranteed to be  =3D=3D 16, unless we add that in writin=
g.
> But it doesn't matter - use size() on the returned span)
>
> - rename nil to is_nil (or remove altogether - checking =3D=3D {} works)
>
> - add assignment from another uuid
>
> - should be trivially copyable, etc
>
>
> Basically, we want a class that is not much more than 16 bytes gathered
> up.  They should almost always be treated as a whole, not parts.  So once
> you have the unique bytes inside the uuid, you can be sure that they stay
> unique (as unique as wherever you constructed them from).
> The invariant of the class is the uniqueness.  You can't actually
> guarantee that, but you can at least guarantee that a uuid (if not nil)
> _maintains_ the invariant, if you assume all uuids are correct on
> construction.
>
> (Would be interesting to consider move-only, to maintain uniqueness)
>
>
>
> On Tue, Mar 6, 2018 at 4:48 PM, Marius Bancila <marius.bancila@gmail.com>
> wrote:
>
>> My proposal on the uuid library, P0959R0
>> <http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0959r0.md>, made
>> it to the pre-Jacksonville mailing (
>> https://isocpp.org/blog/2018/02/2018-02-pre-jacksonville-mailing-availab=
le),
>> but I cannot be there to present it. If anyone that will be there is
>> interested in doing so, please drop me a message.
>>
>> Thank you
>>
>> On Wed, Jan 31, 2018 at 9:44 AM, Marius Bancila <marius.bancila@gmail.co=
m
>> > wrote:
>>
>>> I got some good comments after the last update. I'll try to summarize
>>> the main points and answer here:
>>>
>>> The section "Iterators constructors" lists two examples, neither of
>>>> which uses iterators to construct UUID.
>>>
>>>
>>> That was a error after some edits. It's fixed.
>>>
>>> The "Capacity" section should probably be named "Size" since you
>>>> describe the `size` method there. Also, `nil` has nothing to do with s=
ize,
>>>> and its description is better moved elsewhere.
>>>
>>>
>>> Done. I made two sections, one called Size and one called Nil.
>>>
>>> I believe, `swap` should be overloaded, not specialized.
>>>
>>>
>>> Done. I removed the specialization of swap and provided an overload.
>>>
>>> Why is `uuid_variant::future` needed?
>>>
>>>
>>> It's actually called uuid_variant::reserved. It's not really needed,
>>> but it is specified by rfc4122 so at least in theory it may occur (in t=
he
>>> future), and therefore the enum should have, in my opinion, an enumerat=
or
>>> for it.
>>>
>>>
>>>> `uuid::uuid_const_iterator` and `uuid::uuid_iterator` don't need to be
>>>> in the specification. The type of the iterators can simply be specifie=
d as
>>>> implementation-defined.
>>>>     typedef /*implementation-defined*/ iterator; // see [uuid]
>>>>     using const_iterator =3D implementation-defined; // see [uuid]
>>>
>>>
>>> That was my intention in the first place, but didn't put it in this
>>> form, but in something that looked more of a specification. I changed i=
t to
>>> what was suggested.
>>>
>>> I don't think std::hash<std::uuid> should be string-based at all, but
>>>> we're discussing the proposal, and it doesn't need to suggest a partic=
ular
>>>> implementation of the specialization. In fact, I think it should *not*
>>>> suggest a particular implementation.
>>>
>>>
>>> I am not suggesting any implementation. Yes, I did a string-based
>>> implementation, but that doesn't mean it has to be so.
>>>
>>> I think `uuid_default_generator` still has to provide some guarantees o=
n
>>>> the produced UUIDs. Having a generator that produces noone knows what =
is
>>>> hardly useful. I assume it is supposed to produce random UUIDs using s=
ome
>>>> system-specific source of randomness, so why not say that? Also, if it=
 is a
>>>> random generator, its name should reflect that.
>>>>
>>>> Yes. Please never ever name anything "default_"-anything. There are tw=
o
>>>> conflicting meanings for "default_" in the C++ standard:
>>>> (1) "Default" as in "the best one to use." There will be a reason that
>>>> it is the best one. State that reason. For example, "my::mt19937" is a=
 good
>>>> name for a default random number engine, and "my::sha256" is a good na=
me
>>>> for the default hash.
>>>> (2) "Default" as in "implementation-defined." Such a typedef will neve=
r
>>>> be used by anyone, because its behavior will not be portable. Prefer t=
o
>>>> eliminate such useless cruft from the wording completely.
>>>
>>>
>>> I removed the uuid_default_generator completely from the specification.
>>> Although in my particular implementation I still have that, I have rena=
med
>>> it to uuid_system_generator and explained it uses system resources for
>>> generating a UUID. However, it's not part of the library specification =
any
>>> more.
>>>
>>> I hope this addresses most of the last concerns.
>>>
>>> Marius
>>>
>>> On Thu, Jan 25, 2018 at 2:12 AM, Arthur O'Dwyer <
>>> arthur.j.odwyer@gmail.com> wrote:
>>>
>>>> On Wed, Jan 24, 2018 at 2:23 PM, Andrey Semashev <
>>>> andrey.semashev@gmail.com> wrote:
>>>>
>>>>> On Thu, Jan 25, 2018 at 12:02 AM, Edward Catmur <ed@catmur.co.uk>
>>>>> wrote:
>>>>> > On Tuesday, 23 January 2018 10:30:20 UTC+9, Andrey Semashev  wrote:
>>>>> >>
>>>>> >> I don't think std::hash<std::uuid> should be string-based at all,
>>>>> but
>>>>> >> we're discussing the proposal, and it doesn't need to suggest a
>>>>> >> particular implementation of the specialization. In fact, I think =
it
>>>>> >> should *not* suggest a particular implementation.
>>>>> >
>>>>> > Would it be acceptable to make it constexpr, noexcept or
>>>>> (preferably) both? That would preclude the slow, allocating stringstr=
eam
>>>>> approach without mandating any particular implementation.
>>>>>
>>>>> I think, constexpr and noexcept would be nice regardless. They don't
>>>>> preclude a string-based implementation though, as one could generate =
a
>>>>> string in a local buffer. Not that I see why one would implement it
>>>>> that way.
>>>>>
>>>>
>>>> That's exactly what I meant by the suggestion
>>>>
>>>> > > Should there be a "to_string" member function overload that takes =
a
>>>> > > buffer-of-char and writes the result into it?
>>>>
>>>> There probably should be such a member function.
>>>>
>>>> Either that, or
>>>> (A) uuid::operator<< should be specified not to use heap-allocation,
>>>> *and*
>>>> (B) the standard should provide an allocator-aware version of
>>>> std::ostringstream (P0407 <http://wg21.link/p0407>),
>>>> which would let people stringify a UUID to a local char buffer by
>>>> jumping through only O(1) hoops.
>>>>
>>>> =E2=80=93Arthur
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to std-proposals+unsubscribe@isocpp.org.
>>>> To post to this group, send email to std-proposals@isocpp.org.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2=
BPp40k0wLva_6iF1mApOeq0ycNt94cjYeAUD-TC_XYNQ%40mail.gmail.com
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%=
2BPp40k0wLva_6iF1mApOeq0ycNt94cjYeAUD-TC_XYNQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>>>> .
>>>>
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASwA=
inGU4xSiTO513TTU-47YKymHQC5YnBv_QidTa5Tt0A%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASw=
AinGU4xSiTO513TTU-47YKymHQC5YnBv_QidTa5Tt0A%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>> .
>>
>
>
>
> --
> Be seeing you,
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitwUMo=
2%3Dvp4_7AH_d3YfsYYpQn-81BWUE9VFXeVg4_GZA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitwUM=
o2%3Dvp4_7AH_d3YfsYYpQn-81BWUE9VFXeVg4_GZA%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CA%2BgtASxytWV33%3D50bNv1BfCZqtef_OfmwOo%3DSEPnL=
_3RvEGXwA%40mail.gmail.com.

--0000000000003dcc04056e93cc9a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you for the feedback. I will work it out following t=
he comments.=C2=A0<div><br></div><div>As a side note, I have already rename=
d nil() to is_nil(), although I did not submitted an update of the paper on=
ly for that, as I wanted to get this kind of feedback first.<div><br></div>=
<div>Marius</div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
">On Thu, Jun 14, 2018 at 6:11 AM Tony V E &lt;<a href=3D"mailto:tvaneerd@g=
mail.com">tvaneerd@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div>The committee discussed this paper briefly o=
n Saturday, at the very end of the week.</div><div><br></div><div>Some comm=
ents (a mix of just my opinions, and LEWG comments)</div><div><br></div><di=
v>- don&#39;t construct from a string_view.=C2=A0 Make that a &quot;factory=
&quot; function.=C2=A0 ie a static member function uuid from_string(string_=
view).=C2=A0 Either return nil uuid on error, or throw an exception. (Note =
that nil is a valid result, so returning nil means you don&#39;t know if it=
 is an error or a valid parse, unfortunately.=C2=A0 Might also consider exp=
ected&lt;uuid&gt; but nothing else in the STL uses expected (and it is not =
in the STL yet))</div><div>It should be a function because it is doing pars=
ing, which feels more like a function (takes input, gives output) than a co=
nstructor.</div><div><br></div><div>- construct from a fixed-size span&lt;c=
onst std::byte, 16&gt;. This makes &quot;wrong size&quot; not your problem.=
<br></div><div>- not sure whether the iterator constructor should stay - I =
suppose it is useful for non-contiguous cases.=C2=A0 Committee might make i=
t UB if it is not 16 bytes.</div><div><br></div><div>- remove container-lik=
e stuff: size and iterators, typedefs, etc - just have a to_span() function=
 that returns a span&lt;const std::byte, 16&gt;</div><div>(it probably neve=
r should have had mutable iterators, btw - we don&#39;t want to allow chang=
ing single bytes in a uuid)</div><div><br></div><div>Oh, wait - you were sa=
ying that the internal representation might not be just bytes - is that imp=
ortant?</div><div>I think we need to standardize the order.=C2=A0 Construct=
ion from a sequence of bytes should give the same uuid on all machines.<br>=
</div><div><br></div><div>And we also need to define how the bytes turn int=
o strings.</div><div><br></div><div>Basically, I would say the byte order t=
urns directly into string order.=C2=A0 For bytes a,b,c,d... you get string =
&quot;aabbccdd-eeff-gghh-iijj-kkllmmnnoopp&quot;</div><div><br></div><div><=
br></div><div>- remove state_size.=C2=A0 sizeof(uuid) is good enough (Hmm, =
although it is technically not guaranteed to be=C2=A0 =3D=3D 16, unless we =
add that in writing.=C2=A0 But it doesn&#39;t matter - use size() on the re=
turned span)</div><div><br></div><div>- rename nil to is_nil (or remove alt=
ogether - checking =3D=3D {} works)<br></div><div><br></div><div>- add assi=
gnment from another uuid<br></div><div><br></div><div>- should be trivially=
 copyable, etc<br></div><div><br></div><div><br></div><div>Basically, we wa=
nt a class that is not much more than 16 bytes gathered up.=C2=A0 They shou=
ld almost always be treated as a whole, not parts.=C2=A0 So once you have t=
he unique bytes inside the uuid, you can be sure that they stay unique (as =
unique as wherever you constructed them from).</div><div>The invariant of t=
he class is the uniqueness.=C2=A0 You can&#39;t actually guarantee that, bu=
t you can at least guarantee that a uuid (if not nil) _maintains_ the invar=
iant, if you assume all uuids are correct on construction.<br></div><div><b=
r></div><div>(Would be interesting to consider move-only, to maintain uniqu=
eness)<br></div><div><br></div><div><br></div></div><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote">On Tue, Mar 6, 2018 at 4:48 PM, Marius B=
ancila <span dir=3D"ltr">&lt;<a href=3D"mailto:marius.bancila@gmail.com" ta=
rget=3D"_blank">marius.bancila@gmail.com</a>&gt;</span> wrote:<br><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">My proposal on the uuid library,=C2=
=A0<a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0959r0.m=
d" target=3D"_blank">P0959R0</a>, made it to the pre-Jacksonville mailing (=
<a href=3D"https://isocpp.org/blog/2018/02/2018-02-pre-jacksonville-mailing=
-available" target=3D"_blank">https://isocpp.org/blog/2018/02/2018-02-pre-j=
acksonville-mailing-available</a>), but I cannot be there to present it. If=
 anyone that will be there is interested in doing so, please drop me a mess=
age.<div><br></div><div>Thank you</div></div><div><div class=3D"m_-32981619=
20261576073h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On=
 Wed, Jan 31, 2018 at 9:44 AM, Marius Bancila <span dir=3D"ltr">&lt;<a href=
=3D"mailto:marius.bancila@gmail.com" target=3D"_blank">marius.bancila@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">I got some good comments after the last update. I&#39;ll try to summariz=
e the main points and answer here:<div><br></div><div><span><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">The section &quot;Iterators constructors=
&quot; lists two examples, neither of which uses iterators to construct UUI=
D.</blockquote><div><br></div></span><div>That was a error after some edits=
.. It&#39;s fixed.</div><span><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">The &quot;Capacity&quot; section should probably be name=
d &quot;Size&quot; since you describe the `size` method there. Also, `nil` =
has nothing to do with size, and its description is better moved elsewhere.=
</blockquote><div><br></div></span><div>Done. I made two sections, one call=
ed Size and one called Nil.</div><span><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">I believe, `swap` should be overloaded, not sp=
ecialized.</blockquote><div><br></div></span><div>Done. I removed the speci=
alization of swap and provided an overload.</div><span><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">Why is `uuid_variant::future` =
needed?</blockquote><div><br></div></span><div>It&#39;s actually called <fo=
nt face=3D"monospace, monospace">uuid_variant::reserved</font>. It&#39;s no=
t really needed, but it is specified by rfc4122 so at least in theory it ma=
y occur (in the future), and therefore the enum should have, in my opinion,=
 an enumerator for it.=C2=A0</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><span><br>`uuid::uuid_const_iterator` and `uuid::uu=
id_iterator` don&#39;t need to be in the specification. The type of the ite=
rators can simply be specified as implementation-defined.<br></span><span>=
=C2=A0 =C2=A0 typedef /*implementation-defined*/ iterator; // see [uuid]<br=
>=C2=A0 =C2=A0 using const_iterator =3D implementation-defined; // see [uui=
d]</span></blockquote><div>=C2=A0 =C2=A0=C2=A0</div><div>That was my intent=
ion in the first place, but didn&#39;t put it in this form, but in somethin=
g that looked more of a specification. I changed it to what was suggested.<=
/div><div><br></div><div><span>

<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex" class=3D"gmail_quote">I don&#39;t think std::ha=
sh&lt;std::uuid&gt; should be string-based at all, but we&#39;re discussing=
 the proposal, and it doesn&#39;t need to suggest a particular implementati=
on of the specialization. In fact, I think it should *not* suggest a partic=
ular implementation.</blockquote><br class=3D"m_-3298161920261576073m_-7293=
019058525120346m_3843970509591103383gmail-Apple-interchange-newline"></span=
>

I am not suggesting any implementation. Yes, I did a string-based implement=
ation, but that doesn&#39;t mean it has to be so.</div><span><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">I think `uuid_default_ge=
nerator` still has to provide some guarantees on the produced UUIDs. Having=
 a generator that produces noone knows what is hardly useful. I assume it i=
s supposed to produce random UUIDs using some system-specific source of ran=
domness, so why not say that? Also, if it is a random generator, its name s=
hould reflect that.<br><br>Yes. Please never ever name anything &quot;defau=
lt_&quot;-anything. There are two conflicting meanings for &quot;default_&q=
uot; in the C++ standard:<br>(1) &quot;Default&quot; as in &quot;the best o=
ne to use.&quot; There will be a reason that it is the best one. State that=
 reason. For example, &quot;my::mt19937&quot; is a good name for a default =
random number engine, and &quot;my::sha256&quot; is a good name for the def=
ault hash.<br>(2) &quot;Default&quot; as in &quot;implementation-defined.&q=
uot; Such a typedef will never be used by anyone, because its behavior will=
 not be portable. Prefer to eliminate such useless cruft from the wording c=
ompletely.</blockquote><div><br></div></span><div>I removed the uuid_defaul=
t_generator completely from the specification. Although in my particular im=
plementation I still have that, I have renamed it to uuid_system_generator =
and explained it uses system resources for generating a UUID. However, it&#=
39;s not part of the library specification any more.</div></div><div><br></=
div><div>I hope this addresses most of the last concerns.</div><span class=
=3D"m_-3298161920261576073m_-7293019058525120346HOEnZb"><font color=3D"#888=
888"><div><br></div><div>Marius</div></font></span></div><div class=3D"m_-3=
298161920261576073m_-7293019058525120346HOEnZb"><div class=3D"m_-3298161920=
261576073m_-7293019058525120346h5"><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On Thu, Jan 25, 2018 at 2:12 AM, Arthur O&#39;Dwyer <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_bl=
ank">arthur.j.odwyer@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span>On Wed, Jan 24, 2018 at 2:23 PM, Andre=
y Semashev <span dir=3D"ltr">&lt;<a href=3D"mailto:andrey.semashev@gmail.co=
m" target=3D"_blank">andrey.semashev@gmail.com</a>&gt;</span> wrote:<br></s=
pan><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><span>On Thu, Jan 25, 2018 at 12:02 AM, Edward Catmur &=
lt;<a href=3D"mailto:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co.uk</a>=
&gt; wrote:<br>
&gt; On Tuesday, 23 January 2018 10:30:20 UTC+9, Andrey Semashev=C2=A0 wrot=
e:<br>
&gt;&gt;<br>
</span><span>&gt;&gt; I don&#39;t think std::hash&lt;std::uuid&gt; should b=
e string-based at all, but<br>
&gt;&gt; we&#39;re discussing the proposal, and it doesn&#39;t need to sugg=
est a<br>
&gt;&gt; particular implementation of the specialization. In fact, I think =
it<br>
&gt;&gt; should *not* suggest a particular implementation.<br>
&gt;<br>
&gt; Would it be acceptable to make it constexpr, noexcept or (preferably) =
both? That would preclude the slow, allocating stringstream approach withou=
t mandating any particular implementation.<br>
<br>
</span>I think, constexpr and noexcept would be nice regardless. They don&#=
39;t<br>
preclude a string-based implementation though, as one could generate a<br>
string in a local buffer. Not that I see why one would implement it<br>
that way.<span><br></span></blockquote><div><br></div></span><div>That&#39;=
s exactly what I meant by the suggestion</div><span><div><br></div><div><sp=
an style=3D"font-size:13px">&gt; &gt; Should there be a &quot;to_string&quo=
t; member function overload that takes a</span><br style=3D"font-size:13px"=
><span style=3D"font-size:13px">&gt; &gt; buffer-of-char and writes the res=
ult into it?<span class=3D"m_-3298161920261576073m_-7293019058525120346m_38=
43970509591103383m_8318511200263111284sew9ywgm8p2konq"></span><span class=
=3D"m_-3298161920261576073m_-7293019058525120346m_3843970509591103383m_8318=
511200263111284sewsor5h9kiz23z"></span></span><br></div><div><br></div></sp=
an><div>There probably should be such a member function.</div><div><br></di=
v><div>Either that, or<br></div><div>(A) uuid::operator&lt;&lt; should be s=
pecified not to use heap-allocation, <b><i>and</i></b></div><div>(B) the st=
andard should provide an allocator-aware version of std::ostringstream (<a =
href=3D"http://wg21.link/p0407" target=3D"_blank">P0407</a>),</div><div>whi=
ch would let people stringify a UUID to a local char buffer by jumping thro=
ugh only O(1) hoops.</div><div><br></div><div>=E2=80=93Arthur</div></div></=
div></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BPp40k0wLva_6iF1mApOeq0ycNt9=
4cjYeAUD-TC_XYNQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CADvuK0%2BPp40k0wLva_6iF1mApOeq0ycNt94cjYeAUD-TC_XYNQ%40mail.gmail.c=
om</a>.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASwAinGU4xSiTO513TTU-47YKymHQC=
5YnBv_QidTa5Tt0A%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CA%2BgtASwAinGU4xSiTO513TTU-47YKymHQC5YnBv_QidTa5Tt0A%40mail.gmail.c=
om</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"m_-329816=
1920261576073gmail_signature" data-smartmail=3D"gmail_signature"><div dir=
=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbitwUMo2%3Dvp4_7AH_d3YfsYYpQn-81=
BWUE9VFXeVg4_GZA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAOHCbitwUMo2%3Dvp4_7AH_d3YfsYYpQn-81BWUE9VFXeVg4_GZA%40mail.gmail.c=
om</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxytWV33%3D50bNv1BfCZqtef_Ofm=
wOo%3DSEPnL_3RvEGXwA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxy=
tWV33%3D50bNv1BfCZqtef_OfmwOo%3DSEPnL_3RvEGXwA%40mail.gmail.com</a>.<br />

--0000000000003dcc04056e93cc9a--

.

On Wednesday, 13 June 2018 20:11:31 PDT Tony V E wrote:
> - remove container-like stuff: size and iterators, typedefs, etc - just
> have a to_span() function that returns a span<const std::byte, 16>
> (it probably never should have had mutable iterators, btw - we don't want
> to allow changing single bytes in a uuid)
>
> Oh, wait - you were saying that the internal representation might not be
> just bytes - is that important?
> I think we need to standardize the order.  Construction from a sequence of
> bytes should give the same uuid on all machines.

Suggest referring to RFC 4122 section 4.1.2 for the layout and byte order.

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



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

.

On 06/14/18 06:11, Tony V E wrote:
> The committee discussed this paper briefly on Saturday, at the very end=
=20
> of the week.
>=20
> Some comments (a mix of just my opinions, and LEWG comments)
>=20
> - remove container-like stuff: size and iterators, typedefs, etc - just=
=20
> have a to_span() function that returns a span<const std::byte, 16>
> (it probably never should have had mutable iterators, btw - we don't=20
> want to allow changing single bytes in a uuid)
>=20
> Oh, wait - you were saying that the internal representation might not be=
=20
> just bytes - is that important?

This was my suggestion. I don't think we should use a span to expose the=20
contents of uuid because it mandates representation (an array of bytes,=20
big endian). This will harm performance. The point of iterators is that=20
they may not be just pointers. For example, they could be reverse=20
iterators on little endian machines.

If we had iterator_range, we could use that. As long as we don't, I=20
think exposing iterators is the best we can do.

> I think we need to standardize the order.=C2=A0 Construction from a seque=
nce=20
> of bytes should give the same uuid on all machines.

The order of bytes exposed by uuid's iterators must be fixed, as it is=20
fixed in RFC. The important part is that the bytes stored in the=20
implementation can have a different order and, actually, can be stored=20
not as bytes but as words or a SIMD vector. The conversion logic is=20
hidden in the iterators.

The constructor from bytes would accept the portable representation=20
(equivalent to RFC) and convert it to the internal representation.

> And we also need to define how the bytes turn into strings.
>=20
> Basically, I would say the byte order turns directly into string order. =
=20
> For bytes a,b,c,d... you get string "aabbccdd-eeff-gghh-iijj-kkllmmnnoopp=
"

The string format is described in the RFC, we could reproduce it in the=20
wording.

> - remove state_size.=C2=A0 sizeof(uuid) is good enough (Hmm, although it =
is=20
> technically not guaranteed to be=C2=A0 =3D=3D 16, unless we add that in w=
riting. =20
> But it doesn't matter - use size() on the returned span)

I think, uuid::size() should do. Using sizeof to determine the size of=20
the UUID doesn't feel right.

> - rename nil to is_nil (or remove altogether - checking =3D=3D {} works)

is_nil could be more efficient.

> Basically, we want a class that is not much more than 16 bytes gathered=
=20
> up.=C2=A0 They should almost always be treated as a whole, not parts.=C2=
=A0 So=20
> once you have the unique bytes inside the uuid, you can be sure that=20
> they stay unique (as unique as wherever you constructed them from).
> The invariant of the class is the uniqueness.=C2=A0 You can't actually=20
> guarantee that, but you can at least guarantee that a uuid (if not nil)=
=20
> _maintains_ the invariant, if you assume all uuids are correct on=20
> construction.

I don't agree. Uniqueness is not an invariant of a UUID. It's an=20
invariant of a random UUID generator, although technically it's not=20
guaranteed. As for UUID, as soon as it it constructed, it's just an id.=20
It doesn't have to be unique (e.g. you can copy it or you can construct=20
multiple UUIDs from the same bytes).

> (Would be interesting to consider move-only, to maintain uniqueness)

I don't think having it movable only would be useful.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b06d1b8d-a1c9-5d85-c3d0-d56d8b93d9ee%40gmail.com=
..

.

--0000000000004ac3bc056e9e3107
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 14, 2018 at 2:01 AM, Andrey Semashev <andrey.semashev@gmail.com=
>
wrote:

> On 06/14/18 06:11, Tony V E wrote:
>
>> The committee discussed this paper briefly on Saturday, at the very end
>> of the week.
>>
>> Some comments (a mix of just my opinions, and LEWG comments)
>
>
> - rename nil to is_nil (or remove altogether - checking =3D=3D {} works)
>>
>
> is_nil could be more efficient.
>

FWIW,
- I forget the motivation for letting a UUID get into the "empty" state
- I forget why the "empty" state should be considered distinct from the
perfectly valid "all-bytes-zero" state which is easy to test for and not
special in any way
- I forget why the "empty" state is not named "empty"



> Basically, we want a class that is not much more than 16 bytes gathered
>> up.  They should almost always be treated as a whole, not parts.  So onc=
e
>> you have the unique bytes inside the uuid, you can be sure that they sta=
y
>> unique (as unique as wherever you constructed them from).
>> The invariant of the class is the uniqueness.  You can't actually
>> guarantee that, but you can at least guarantee that a uuid (if not nil)
>> _maintains_ the invariant, if you assume all uuids are correct on
>> construction.
>>
>
> I don't agree. Uniqueness is not an invariant of a UUID. It's an invarian=
t
> of a random UUID generator, although technically it's not guaranteed. As
> for UUID, as soon as it it constructed, it's just an id. It doesn't have =
to
> be unique (e.g. you can copy it or you can construct multiple UUIDs from
> the same bytes).
>
> (Would be interesting to consider move-only, to maintain uniqueness)
>>
>
> I don't think having it movable only would be useful.


Right. There is absolutely no value, and quite a lot of downside, to making
a key type such as UUID (or ISBN, or a string type used to store person's
name) non-copyable.  The whole *point* of making a key is that you can use
it to refer to things from multiple different places, which means being
able to copy it freely.
See also:
https://codereview.stackexchange.com/questions/86836/library-management-sys=
tem-in-c/

=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0%2BkKWWuFLvGJfdeV42kxvaxjxcoMXWta_q%3D-8S=
2JVDbCw%40mail.gmail.com.

--0000000000004ac3bc056e9e3107
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Jun 14, 2018 at 2:01 AM, Andrey Semashev <span dir=
=3D"ltr">&lt;<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank"=
>andrey.semashev@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;borde=
r-left-color:rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-">On 0=
6/14/18 06:11, Tony V E wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204=
,204);padding-left:1ex"><span class=3D"gmail-">
The committee discussed this paper briefly on Saturday, at the very end of =
the week.<br>
<br>
Some comments (a mix of just my opinions, and LEWG comments)</span></blockq=
uote></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:=
rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex">
- rename nil to is_nil (or remove altogether - checking =3D=3D {} works)<br=
>
</blockquote>
<br></span>
is_nil could be more efficient.<span class=3D"gmail-"><br></span></blockquo=
te><div><br></div><div>FWIW,=C2=A0</div><div>- I forget the motivation for =
letting a UUID get into the &quot;empty&quot; state</div><div>- I forget wh=
y the &quot;empty&quot; state should be considered distinct from the perfec=
tly valid &quot;all-bytes-zero&quot; state which is easy to test for and no=
t special in any way</div><div>- I forget why the &quot;empty&quot; state i=
s not named &quot;empty&quot;</div><div><br></div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-l=
eft:1ex"><span class=3D"gmail-">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex">
Basically, we want a class that is not much more than 16 bytes gathered up.=
=C2=A0 They should almost always be treated as a whole, not parts.=C2=A0 So=
 once you have the unique bytes inside the uuid, you can be sure that they =
stay unique (as unique as wherever you constructed them from).<br>
The invariant of the class is the uniqueness.=C2=A0 You can&#39;t actually =
guarantee that, but you can at least guarantee that a uuid (if not nil) _ma=
intains_ the invariant, if you assume all uuids are correct on construction=
..<br>
</blockquote>
<br></span>
I don&#39;t agree. Uniqueness is not an invariant of a UUID. It&#39;s an in=
variant of a random UUID generator, although technically it&#39;s not guara=
nteed. As for UUID, as soon as it it constructed, it&#39;s just an id. It d=
oesn&#39;t have to be unique (e.g. you can copy it or you can construct mul=
tiple UUIDs from the same bytes).<span class=3D"gmail-"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex">
(Would be interesting to consider move-only, to maintain uniqueness)<br>
</blockquote>
<br></span>
I don&#39;t think having it movable only would be useful.</blockquote><div>=
<br></div><div>Right. There is absolutely no value, and quite a lot of down=
side, to making a key type such as UUID (or ISBN, or a string type used to =
store person&#39;s name) non-copyable.=C2=A0 The whole <i>point</i> of maki=
ng a key is that you can use it to refer to things from multiple different =
places, which means being able to copy it freely.</div><div>See also:=C2=A0=
<a href=3D"https://codereview.stackexchange.com/questions/86836/library-man=
agement-system-in-c/">https://codereview.stackexchange.com/questions/86836/=
library-management-system-in-c/</a></div><div><br></div><div>=E2=80=93Arthu=
r</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BkKWWuFLvGJfdeV42kxvaxjxcoMX=
Wta_q%3D-8S2JVDbCw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BkKW=
WuFLvGJfdeV42kxvaxjxcoMXWta_q%3D-8S2JVDbCw%40mail.gmail.com</a>.<br />

--0000000000004ac3bc056e9e3107--

.

On Thursday, 14 June 2018 02:01:16 PDT Andrey Semashev wrote:
> > - remove container-like stuff: size and iterators, typedefs, etc - just
> > have a to_span() function that returns a span<const std::byte, 16>
> > (it probably never should have had mutable iterators, btw - we don't
> > want to allow changing single bytes in a uuid)
> >
> > Oh, wait - you were saying that the internal representation might not be
> > just bytes - is that important?
>
> This was my suggestion. I don't think we should use a span to expose the
> contents of uuid because it mandates representation (an array of bytes,
> big endian). This will harm performance. The point of iterators is that
> they may not be just pointers. For example, they could be reverse
> iterators on little endian machines.

Right, it may not work to provide a function returning std::span<byte, 16>,
but instead a std::array<byte, 16> to get the actual bytes, if one needs them
for some reason.

For example, the implementation on Windows may want to be layout-compatible
with the GUID structure[1] to facilitate copying to and from that type (QUuid
does that). As a side-effect, it means the first 8 bytes are not in the
correct order for a byte-level access on little-endian machines.

By the way, what's the policy on allowing the implementation to provide member
functions to convert to and from native structures like GUID?

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa373931.aspx

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



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

.

--000000000000cd0c01056e9ec4b4
Content-Type: text/plain; charset="UTF-8"

On Thu, Jun 14, 2018 at 5:01 AM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On 06/14/18 06:11, Tony V E wrote:
>
>> The committee discussed this paper briefly on Saturday, at the very end
>> of the week.
>>
>> Some comments (a mix of just my opinions, and LEWG comments)
>>
>> - remove container-like stuff: size and iterators, typedefs, etc - just
>> have a to_span() function that returns a span<const std::byte, 16>
>> (it probably never should have had mutable iterators, btw - we don't want
>> to allow changing single bytes in a uuid)
>>
>> Oh, wait - you were saying that the internal representation might not be
>> just bytes - is that important?
>>
>
> This was my suggestion. I don't think we should use a span to expose the
> contents of uuid because it mandates representation (an array of bytes, big
> endian). This will harm performance. The point of iterators is that they
> may not be just pointers. For example, they could be reverse iterators on
> little endian machines.
>
>
How much potential performance are we talking about?  Is it really worth it?
The RFC mandates network byte order (most significant first).  Does that
mean < can be just memcmp?

Being able to use span simplifies a lot.

And I'd like uuid to NOT be a container.  It is an ID.  Container-ness and
bytes are implementation details.

But if performance can be shown to be important, then it is important.


If we had iterator_range, we could use that. As long as we don't, I think
> exposing iterators is the best we can do.
>
> I think we need to standardize the order.  Construction from a sequence of
>> bytes should give the same uuid on all machines.
>>
>
> The order of bytes exposed by uuid's iterators must be fixed, as it is
> fixed in RFC. The important part is that the bytes stored in the
> implementation can have a different order and, actually, can be stored not
> as bytes but as words or a SIMD vector. The conversion logic is hidden in
> the iterators.
>
> The constructor from bytes would accept the portable representation
> (equivalent to RFC) and convert it to the internal representation.
>
> And we also need to define how the bytes turn into strings.
>>
>> Basically, I would say the byte order turns directly into string order.
>> For bytes a,b,c,d... you get string "aabbccdd-eeff-gghh-iijj-kkllm
>> mnnoopp"
>>
>
> The string format is described in the RFC, we could reproduce it in the
> wording.
>
> - remove state_size.  sizeof(uuid) is good enough (Hmm, although it is
>> technically not guaranteed to be  == 16, unless we add that in writing.
>> But it doesn't matter - use size() on the returned span)
>>
>
> I think, uuid::size() should do. Using sizeof to determine the size of the
> UUID doesn't feel right.
>

If it is not a container, you don't need size or sizeof at all. It is 16 by
definition.  (Hmmm, what if you are on a system with 9 or 16 bit bytes? I
guess there are still 16 *octets* and the iterators or span would still
have 16 entries.

I guess uint8_t is better than std::byte, for that reason.


- rename nil to is_nil (or remove altogether - checking == {} works)



> is_nil could be more efficient.
>
> Basically, we want a class that is not much more than 16 bytes gathered
>> up.  They should almost always be treated as a whole, not parts.  So once
>> you have the unique bytes inside the uuid, you can be sure that they stay
>> unique (as unique as wherever you constructed them from).
>> The invariant of the class is the uniqueness.  You can't actually
>> guarantee that, but you can at least guarantee that a uuid (if not nil)
>> _maintains_ the invariant, if you assume all uuids are correct on
>> construction.
>>
>
> I don't agree. Uniqueness is not an invariant of a UUID. It's an invariant
> of a random UUID generator, although technically it's not guaranteed. As
> for UUID, as soon as it it constructed, it's just an id. It doesn't have to
> be unique (e.g. you can copy it or you can construct multiple UUIDs from
> the same bytes).
>
> (Would be interesting to consider move-only, to maintain uniqueness)
>>
>
> I don't think having it movable only would be useful.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/b06d1b8d-a1c9-5d85-c3d0-
> d56d8b93d9ee%40gmail.com.
>



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

--000000000000cd0c01056e9ec4b4
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 14, 2018 at 5:01 AM, Andrey Semashev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semas=
hev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
 class=3D"">On 06/14/18 06:11, Tony V E wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D"">
The committee discussed this paper briefly on Saturday, at the very end of =
the week.<br>
<br>
Some comments (a mix of just my opinions, and LEWG comments)<br>
<br></span><span class=3D"">
- remove container-like stuff: size and iterators, typedefs, etc - just hav=
e a to_span() function that returns a span&lt;const std::byte, 16&gt;<br>
(it probably never should have had mutable iterators, btw - we don&#39;t wa=
nt to allow changing single bytes in a uuid)<br>
<br>
Oh, wait - you were saying that the internal representation might not be ju=
st bytes - is that important?<br>
</span></blockquote>
<br>
This was my suggestion. I don&#39;t think we should use a span to expose th=
e contents of uuid because it mandates representation (an array of bytes, b=
ig endian). This will harm performance. The point of iterators is that they=
 may not be just pointers. For example, they could be reverse iterators on =
little endian machines.<br>
<br></blockquote><div><br></div><div>How much potential performance are we =
talking about?=C2=A0 Is it really worth it?</div><div>The RFC mandates netw=
ork byte order (most significant first).=C2=A0 Does that mean &lt; can be j=
ust memcmp?</div><div><br></div><div>Being able to use span simplifies a lo=
t.</div><div><br></div><div>And I&#39;d like uuid to NOT be a container.=C2=
=A0 It is an ID.=C2=A0 Container-ness and bytes are implementation details.=
</div><div><br></div><div>But if performance can be shown to be important, =
then it is important.<br></div><div><br></div><div> <br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
If we had iterator_range, we could use that. As long as we don&#39;t, I thi=
nk exposing iterators is the best we can do.<span class=3D""><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I think we need to standardize the order.=C2=A0 Construction from a sequenc=
e of bytes should give the same uuid on all machines.<br>
</blockquote>
<br></span>
The order of bytes exposed by uuid&#39;s iterators must be fixed, as it is =
fixed in RFC. The important part is that the bytes stored in the implementa=
tion can have a different order and, actually, can be stored not as bytes b=
ut as words or a SIMD vector. The conversion logic is hidden in the iterato=
rs.<br>
<br>
The constructor from bytes would accept the portable representation (equiva=
lent to RFC) and convert it to the internal representation.<span class=3D""=
><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
And we also need to define how the bytes turn into strings.<br>
<br>
Basically, I would say the byte order turns directly into string order.=C2=
=A0 For bytes a,b,c,d... you get string &quot;aabbccdd-eeff-gghh-iijj-kkllm=
<wbr>mnnoopp&quot;<br>
</blockquote>
<br></span>
The string format is described in the RFC, we could reproduce it in the wor=
ding.<span class=3D""><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
- remove state_size.=C2=A0 sizeof(uuid) is good enough (Hmm, although it is=
 technically not guaranteed to be=C2=A0 =3D=3D 16, unless we add that in wr=
iting.=C2=A0 But it doesn&#39;t matter - use size() on the returned span)<b=
r>
</blockquote>
<br></span>
I think, uuid::size() should do. Using sizeof to determine the size of the =
UUID doesn&#39;t feel right.<span class=3D""><br></span></blockquote><div><=
br></div><div>If it is not a container, you don&#39;t need size or sizeof a=
t all. It is 16 by definition.=C2=A0 (Hmmm, what if you are on a system wit=
h 9 or 16 bit bytes? I guess there are still 16 *octets* and the iterators =
or span would still have 16 entries.</div><div><br></div><div>I guess uint8=
_t is better than std::byte, for that reason.<br></div><div><br></div><div>=
<br><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">- rename nil to is_nil =
(or remove altogether - checking =3D=3D {} works)</blockquote></span><br><s=
pan class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></span></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
<br></span>
is_nil could be more efficient.<span class=3D""><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Basically, we want a class that is not much more than 16 bytes gathered up.=
=C2=A0 They should almost always be treated as a whole, not parts.=C2=A0 So=
 once you have the unique bytes inside the uuid, you can be sure that they =
stay unique (as unique as wherever you constructed them from).<br>
The invariant of the class is the uniqueness.=C2=A0 You can&#39;t actually =
guarantee that, but you can at least guarantee that a uuid (if not nil) _ma=
intains_ the invariant, if you assume all uuids are correct on construction=
..<br>
</blockquote>
<br></span>
I don&#39;t agree. Uniqueness is not an invariant of a UUID. It&#39;s an in=
variant of a random UUID generator, although technically it&#39;s not guara=
nteed. As for UUID, as soon as it it constructed, it&#39;s just an id. It d=
oesn&#39;t have to be unique (e.g. you can copy it or you can construct mul=
tiple UUIDs from the same bytes).<span class=3D""><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
(Would be interesting to consider move-only, to maintain uniqueness)<br>
</blockquote>
<br></span>
I don&#39;t think having it movable only would be useful.<span class=3D""><=
br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b06d1b8d-a1c9-5d85-c3d0-d56d8b93d9ee%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/b06d1b8d-a1c9-5d85-c3d0-<wbr>=
d56d8b93d9ee%40gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuNmDLMLK8k50dsSQXcaqzOppNaExAA=
O6r8HJ3KXPKKDg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuNmDLMLK8k=
50dsSQXcaqzOppNaExAAO6r8HJ3KXPKKDg%40mail.gmail.com</a>.<br />

--000000000000cd0c01056e9ec4b4--

.

On Thu, Jun 14, 2018 at 9:23 PM, Arthur O'Dwyer
<arthur.j.odwyer@gmail.com> wrote:
> On Thu, Jun 14, 2018 at 2:01 AM, Andrey Semashev <andrey.semashev@gmail.com>
> wrote:
>> On 06/14/18 06:11, Tony V E wrote:
>>>
>>> - rename nil to is_nil (or remove altogether - checking == {} works)
>>
>> is_nil could be more efficient.
>
> FWIW,
> - I forget the motivation for letting a UUID get into the "empty" state
> - I forget why the "empty" state should be considered distinct from the
> perfectly valid "all-bytes-zero" state which is easy to test for and not
> special in any way
> - I forget why the "empty" state is not named "empty"

The nil value is not an empty state, a nil UUID still contains a
value. This value is defined in the RFC and is designated as such:

https://tools.ietf.org/html/rfc4122#section-4.1.7

I would say that having a special function to test against this value
is useful because it is often used as an indicator of
default-constructed or unassigned or unused, etc. value. The RFC
specifically mentions that value, so having a way to explicitly test
for it seems reasonable.

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

.

--000000000000574cb8056e9ef214
Content-Type: text/plain; charset="UTF-8"

On Thu, Jun 14, 2018 at 3:11 PM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On Thu, Jun 14, 2018 at 9:23 PM, Arthur O'Dwyer
> <arthur.j.odwyer@gmail.com> wrote:
> > On Thu, Jun 14, 2018 at 2:01 AM, Andrey Semashev <
> andrey.semashev@gmail.com>
> > wrote:
> >> On 06/14/18 06:11, Tony V E wrote:
> >>>
> >>> - rename nil to is_nil (or remove altogether - checking == {} works)
> >>
> >> is_nil could be more efficient.
> >
> > FWIW,
> > - I forget the motivation for letting a UUID get into the "empty" state
> > - I forget why the "empty" state should be considered distinct from the
> > perfectly valid "all-bytes-zero" state which is easy to test for and not
> > special in any way
> > - I forget why the "empty" state is not named "empty"
>
> The nil value is not an empty state, a nil UUID still contains a
> value. This value is defined in the RFC and is designated as such:
>
> https://tools.ietf.org/html/rfc4122#section-4.1.7
>
> I would say that having a special function to test against this value
> is useful because it is often used as an indicator of
> default-constructed or unassigned or unused, etc. value. The RFC
> specifically mentions that value, so having a way to explicitly test
> for it seems reasonable.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAEhD%2B6CTRS5yDCRikb3zgwkkxzvpZyJf6
> iwRn%2B%2BxzzEP01YDpA%40mail.gmail.com.
>

We definitely don't want size() == 16 and empty() == true.
Which is what a nil uuid would say, if we renamed is_nil to empty.

--
Be seeing you,
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitopNEU2%2Bn0PGyCUpAC55vK8F6PGV_Z180EJ3iQceeFtQ%40mail.gmail.com.

--000000000000574cb8056e9ef214
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 14, 2018 at 3:11 PM, Andrey Semashev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semas=
hev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
 class=3D"">On Thu, Jun 14, 2018 at 9:23 PM, Arthur O&#39;Dwyer<br>
&lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com<=
/a>&gt; wrote:<br>
&gt; On Thu, Jun 14, 2018 at 2:01 AM, Andrey Semashev &lt;<a href=3D"mailto=
:andrey.semashev@gmail.com">andrey.semashev@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt; On 06/14/18 06:11, Tony V E wrote:<br>
&gt;&gt;&gt;<br>
</span><span class=3D"">&gt;&gt;&gt; - rename nil to is_nil (or remove alto=
gether - checking =3D=3D {} works)<br>
&gt;&gt;<br>
&gt;&gt; is_nil could be more efficient.<br>
&gt;<br>
&gt; FWIW,<br>
&gt; - I forget the motivation for letting a UUID get into the &quot;empty&=
quot; state<br>
&gt; - I forget why the &quot;empty&quot; state should be considered distin=
ct from the<br>
&gt; perfectly valid &quot;all-bytes-zero&quot; state which is easy to test=
 for and not<br>
&gt; special in any way<br>
&gt; - I forget why the &quot;empty&quot; state is not named &quot;empty&qu=
ot;<br>
<br>
</span>The nil value is not an empty state, a nil UUID still contains a<br>
value. This value is defined in the RFC and is designated as such:<br>
<br>
<a href=3D"https://tools.ietf.org/html/rfc4122#section-4.1.7" rel=3D"norefe=
rrer" target=3D"_blank">https://tools.ietf.org/html/<wbr>rfc4122#section-4.=
1.7</a><br>
<br>
I would say that having a special function to test against this value<br>
is useful because it is often used as an indicator of<br>
default-constructed or unassigned or unused, etc. value. The RFC<br>
specifically mentions that value, so having a way to explicitly test<br>
for it seems reasonable.<br>
<span class=3D""><br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B6CTRS5yDCRikb3zgwkkxzv=
pZyJf6iwRn%2B%2BxzzEP01YDpA%40mail.gmail.com" rel=3D"noreferrer" target=3D"=
_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>propos=
als/CAEhD%<wbr>2B6CTRS5yDCRikb3zgwkkxzvpZyJf6<wbr>iwRn%2B%2BxzzEP01YDpA%40m=
ail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div><div class=3D"gmail_extra">We definitely don&#=
39;t want size() =3D=3D 16 and empty() =3D=3D true.</div><div class=3D"gmai=
l_extra">Which is what a nil uuid would say, if we renamed is_nil to empty.=
<br clear=3D"all"></div><div class=3D"gmail_extra"><br>-- <br><div class=3D=
"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>=
Be seeing you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbitopNEU2%2Bn0PGyCUpAC55vK8F6PGV=
_Z180EJ3iQceeFtQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitopNEU2%=
2Bn0PGyCUpAC55vK8F6PGV_Z180EJ3iQceeFtQ%40mail.gmail.com</a>.<br />

--000000000000574cb8056e9ef214--

.

On Thu, Jun 14, 2018 at 10:03 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On Thursday, 14 June 2018 02:01:16 PDT Andrey Semashev wrote:
>> > - remove container-like stuff: size and iterators, typedefs, etc - just
>> > have a to_span() function that returns a span<const std::byte, 16>
>> > (it probably never should have had mutable iterators, btw - we don't
>> > want to allow changing single bytes in a uuid)
>> >
>> > Oh, wait - you were saying that the internal representation might not be
>> > just bytes - is that important?
>>
>> This was my suggestion. I don't think we should use a span to expose the
>> contents of uuid because it mandates representation (an array of bytes,
>> big endian). This will harm performance. The point of iterators is that
>> they may not be just pointers. For example, they could be reverse
>> iterators on little endian machines.
>
> Right, it may not work to provide a function returning std::span<byte, 16>,
> but instead a std::array<byte, 16> to get the actual bytes, if one needs them
> for some reason.

This would mean that in order to export portable representation one
would have to copy the bytes as std::array first and then copy bytes
from that array to where they need to be (e.g. a shared memory region
or write to a file). In this case it might be better to have an export
method of std::uuid that takes an output iterator, which will receive
the bytes.

> For example, the implementation on Windows may want to be layout-compatible
> with the GUID structure[1] to facilitate copying to and from that type (QUuid
> does that). As a side-effect, it means the first 8 bytes are not in the
> correct order for a byte-level access on little-endian machines.

I'm not sure having std::uuid layout compatible with GUID would be
helpful. Users would have to perform a reinterpret_cast in order to
employ this feature, and this would be generally UB and certainly not
something we want to encourage.

> By the way, what's the policy on allowing the implementation to provide member
> functions to convert to and from native structures like GUID?

We have native_handle() in std::mutex and std::condition_variable. We
could add something like this to std::uuid, but frankly, I would
prefer if std::uuid didn't use GUID as implementation as it would make
its ordering inefficient.

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

.

On Thu, Jun 14, 2018 at 10:04 PM, Tony V E <tvaneerd@gmail.com> wrote:
> On Thu, Jun 14, 2018 at 5:01 AM, Andrey Semashev <andrey.semashev@gmail.com>
> wrote:
>> On 06/14/18 06:11, Tony V E wrote:
>>>
>>> - remove container-like stuff: size and iterators, typedefs, etc - just
>>> have a to_span() function that returns a span<const std::byte, 16>
>>> (it probably never should have had mutable iterators, btw - we don't want
>>> to allow changing single bytes in a uuid)
>>>
>>> Oh, wait - you were saying that the internal representation might not be
>>> just bytes - is that important?
>>
>>
>> This was my suggestion. I don't think we should use a span to expose the
>> contents of uuid because it mandates representation (an array of bytes, big
>> endian). This will harm performance. The point of iterators is that they may
>> not be just pointers. For example, they could be reverse iterators on little
>> endian machines.
>
> How much potential performance are we talking about?  Is it really worth it?
> The RFC mandates network byte order (most significant first).  Does that
> mean < can be just memcmp?
>
> Being able to use span simplifies a lot.
>
> And I'd like uuid to NOT be a container.  It is an ID.  Container-ness and
> bytes are implementation details.
>
> But if performance can be shown to be important, then it is important.

My primary concern is about the ordering operators. For example, in
Boost.UUID there is an optimized implementation of operator< for SSE
[1], in which you can see additional trickery that had to be
implemented to accommodate for little endian native byte order.
Ordering operators are often used in associative containers and
sorting, which means lots of calls in a tight loop, so I would expect
this to be a rather hot operation. I would really like if std::uuid
didn't enforce this kind of implementation.

[1] https://github.com/boostorg/uuid/blob/develop/include/boost/uuid/detail/uuid_x86.ipp#L98

>>> - remove state_size.  sizeof(uuid) is good enough (Hmm, although it is
>>> technically not guaranteed to be  == 16, unless we add that in writing.  But
>>> it doesn't matter - use size() on the returned span)
>>
>> I think, uuid::size() should do. Using sizeof to determine the size of the
>> UUID doesn't feel right.
>
> If it is not a container, you don't need size or sizeof at all. It is 16 by
> definition.

You do need a size if you want to export or import bytes into UUID.
Yes, the size is always 16, but having it as a constant or another
symbolic way would allow to avoid magic constants and silly typos in
the user's code.

>  (Hmmm, what if you are on a system with 9 or 16 bit bytes? I
> guess there are still 16 *octets* and the iterators or span would still have
> 16 entries.
>
> I guess uint8_t is better than std::byte, for that reason.

Yes, we had this discussion before. The net result is that though the
RFC defines UUID as an object 128-bit long, a platform with non-8-bit
bytes would leave the excess bits of every byte unused and set to a
predefined value so that they don't participate in the UUID value.

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

.

--00000000000082e5e5056e9f9075
Content-Type: text/plain; charset="UTF-8"

On Thu, Jun 14, 2018 at 8:26 PM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On Thu, Jun 14, 2018 at 10:03 PM, Thiago Macieira <thiago@macieira.org>
> wrote:
> > On Thursday, 14 June 2018 02:01:16 PDT Andrey Semashev wrote:
> >> > - remove container-like stuff: size and iterators, typedefs, etc -
> just
> >> > have a to_span() function that returns a span<const std::byte, 16>
> >> > (it probably never should have had mutable iterators, btw - we don't
> >> > want to allow changing single bytes in a uuid)
> >> >
> >> > Oh, wait - you were saying that the internal representation might not
> be
> >> > just bytes - is that important?
> >>
> >> This was my suggestion. I don't think we should use a span to expose the
> >> contents of uuid because it mandates representation (an array of bytes,
> >> big endian). This will harm performance. The point of iterators is that
> >> they may not be just pointers. For example, they could be reverse
> >> iterators on little endian machines.
> >
> > Right, it may not work to provide a function returning std::span<byte,
> 16>,
> > but instead a std::array<byte, 16> to get the actual bytes, if one needs
> them
> > for some reason.
>
> This would mean that in order to export portable representation one
> would have to copy the bytes as std::array first and then copy bytes
> from that array to where they need to be (e.g. a shared memory region
> or write to a file). In this case it might be better to have an export
> method of std::uuid that takes an output iterator, which will receive
> the bytes.
>

With Ranges TS one can write ranges::copy(uuid.as_bytes(), OutputIterator).
I don't think an export() method would really add anything.


> > For example, the implementation on Windows may want to be
> layout-compatible
> > with the GUID structure[1] to facilitate copying to and from that type
> (QUuid
> > does that). As a side-effect, it means the first 8 bytes are not in the
> > correct order for a byte-level access on little-endian machines.
>
> I'm not sure having std::uuid layout compatible with GUID would be
> helpful. Users would have to perform a reinterpret_cast in order to
> employ this feature, and this would be generally UB and certainly not
> something we want to encourage.
>

Or memcpy, or bit_cast. It doesn't have to be UB. However this would still
encourage unobviously platform-dependent code, which should be avoided.


> > By the way, what's the policy on allowing the implementation to provide
> member
> > functions to convert to and from native structures like GUID?
>
> We have native_handle() in std::mutex and std::condition_variable. We
> could add something like this to std::uuid, but frankly, I would
> prefer if std::uuid didn't use GUID as implementation as it would make
> its ordering inefficient.
>

That wouldn't imply using GUID internally, native() could convert and
return by value. But what about platforms that don't have a native uuid
type?

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

--00000000000082e5e5056e9f9075
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 14, 2018 at 8:26 PM, Andrey Semashev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semas=
hev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Th=
u, Jun 14, 2018 at 10:03 PM, Thiago Macieira &lt;<a href=3D"mailto:thiago@m=
acieira.org">thiago@macieira.org</a>&gt; wrote:<br>
&gt; On Thursday, 14 June 2018 02:01:16 PDT Andrey Semashev wrote:<br>
&gt;&gt; &gt; - remove container-like stuff: size and iterators, typedefs, =
etc - just<br>
&gt;&gt; &gt; have a to_span() function that returns a span&lt;const std::b=
yte, 16&gt;<br>
&gt;&gt; &gt; (it probably never should have had mutable iterators, btw - w=
e don&#39;t<br>
&gt;&gt; &gt; want to allow changing single bytes in a uuid)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Oh, wait - you were saying that the internal representation m=
ight not be<br>
&gt;&gt; &gt; just bytes - is that important?<br>
&gt;&gt;<br>
&gt;&gt; This was my suggestion. I don&#39;t think we should use a span to =
expose the<br>
&gt;&gt; contents of uuid because it mandates representation (an array of b=
ytes,<br>
&gt;&gt; big endian). This will harm performance. The point of iterators is=
 that<br>
&gt;&gt; they may not be just pointers. For example, they could be reverse<=
br>
&gt;&gt; iterators on little endian machines.<br>
&gt;<br>
&gt; Right, it may not work to provide a function returning std::span&lt;by=
te, 16&gt;,<br>
&gt; but instead a std::array&lt;byte, 16&gt; to get the actual bytes, if o=
ne needs them<br>
&gt; for some reason.<br>
<br>
This would mean that in order to export portable representation one<br>
would have to copy the bytes as std::array first and then copy bytes<br>
from that array to where they need to be (e.g. a shared memory region<br>
or write to a file). In this case it might be better to have an export<br>
method of std::uuid that takes an output iterator, which will receive<br>
the bytes.<br></blockquote><div><br></div><div>With Ranges TS one can write=
 ranges::copy(uuid.as_bytes(), OutputIterator). I don&#39;t think an export=
() method would really add anything.</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
&gt; For example, the implementation on Windows may want to be layout-compa=
tible<br>
&gt; with the GUID structure[1] to facilitate copying to and from that type=
 (QUuid<br>
&gt; does that). As a side-effect, it means the first 8 bytes are not in th=
e<br>
&gt; correct order for a byte-level access on little-endian machines.<br>
<br>
I&#39;m not sure having std::uuid layout compatible with GUID would be<br>
helpful. Users would have to perform a reinterpret_cast in order to<br>
employ this feature, and this would be generally UB and certainly not<br>
something we want to encourage.<br></blockquote><div><br></div><div>Or memc=
py, or bit_cast. It doesn&#39;t have to be UB. However this would still enc=
ourage unobviously platform-dependent code, which should be avoided.</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">&gt; By the way, what&#39;s =
the policy on allowing the implementation to provide member<br>
&gt; functions to convert to and from native structures like GUID?<br>
<br>
We have native_handle() in std::mutex and std::condition_variable. We<br>
could add something like this to std::uuid, but frankly, I would<br>
prefer if std::uuid didn&#39;t use GUID as implementation as it would make<=
br>
its ordering inefficient.<br></blockquote><div><br></div><div>That wouldn&#=
39;t imply using GUID internally, native() could convert and return by valu=
e. But what about platforms that don&#39;t have a native uuid type?</div></=
div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaWykyC2cLbdZcK-p9NJfwKBekQJwiV=
XCDKAWMt4KFuJw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaWykyC2cLb=
dZcK-p9NJfwKBekQJwiVXCDKAWMt4KFuJw%40mail.gmail.com</a>.<br />

--00000000000082e5e5056e9f9075--

.

--0000000000009dfbcc056e9fadfb
Content-Type: text/plain; charset="UTF-8"

OK, revising, based on latest emails:


On Wed, Jun 13, 2018 at 11:11 PM, Tony V E <tvaneerd@gmail.com> wrote:

> The committee discussed this paper briefly on Saturday, at the very end of
> the week.
>
> Some comments (a mix of just my opinions, and LEWG comments)
>
> - don't construct from a string_view.  Make that a "factory" function.  ie
> a static member function uuid from_string(string_view).  Either return nil
> uuid on error, or throw an exception. (Note that nil is a valid result, so
> returning nil means you don't know if it is an error or a valid parse,
> unfortunately.  Might also consider expected<uuid> but nothing else in the
> STL uses expected (and it is not in the STL yet))
> It should be a function because it is doing parsing, which feels more like
> a function (takes input, gives output) than a constructor.
>
>
still yes to the above


> - construct from a fixed-size span<const std::byte, 16>. This makes "wrong
> size" not your problem.
>

still yes.  Except uint8_t.
We need to say that the order matches the RFC



> - not sure whether the iterator constructor should stay - I suppose it is
> useful for non-contiguous cases.  Committee might make it UB if it is not
> 16 bytes.
>
>
Do we even need the end iterator?



> - remove container-like stuff: size and iterators, typedefs, etc - just
> have a to_span() function that returns a span<const std::byte, 16>
> (it probably never should have had mutable iterators, btw - we don't want
> to allow changing single bytes in a uuid)
>
> Oh, wait - you were saying that the internal representation might not be
> just bytes - is that important?
>

OK, so keep the container interface.  But only const_iterators.  Not
mutable.
Is that a problem for writing into an existing uuid?  Construct a new one
and assign?  Let the compiler optimize it.
Or do we need the mutable iterators?  They seem wrong to me.



> I think we need to standardize the order.  Construction from a sequence of
> bytes should give the same uuid on all machines.
>
>
yes (refer to RFC)

And we also need to define how the bytes turn into strings.
>
>
yes  (refer to RFC)


> - remove state_size.  sizeof(uuid) is good enough (Hmm, although it is
> technically not guaranteed to be  == 16, unless we add that in writing.
> But it doesn't matter - use size() on the returned span)
>
>
size()

- rename nil to is_nil (or remove altogether - checking == {} works)
>
>
yes

- add assignment from another uuid
>
>
yes

- should be trivially copyable, etc
>
>
yes?



>
> Basically, we want a class that is not much more than 16 bytes gathered
> up.  They should almost always be treated as a whole, not parts.  So once
> you have the unique bytes inside the uuid, you can be sure that they stay
> unique (as unique as wherever you constructed them from).
> The invariant of the class is the uniqueness.  You can't actually
> guarantee that, but you can at least guarantee that a uuid (if not nil)
> _maintains_ the invariant, if you assume all uuids are correct on
> construction.
>
> (Would be interesting to consider move-only, to maintain uniqueness)
>

no.


>
--
Be seeing you,
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu-Xs2CMg42OJnhaunq6OKFTvfqMBnc7jY9n9bm8ZL3zA%40mail.gmail.com.

--0000000000009dfbcc056e9fadfb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>OK, revising, based on latest emails:<br></div><div><=
br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, =
Jun 13, 2018 at 11:11 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:=
tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wro=
te:<br><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>The committee d=
iscussed this paper briefly on Saturday, at the very end of the week.</div>=
<div><br></div><div>Some comments (a mix of just my opinions, and LEWG comm=
ents)</div><div><br></div><div>- don&#39;t construct from a string_view.=C2=
=A0 Make that a &quot;factory&quot; function.=C2=A0 ie a static member func=
tion uuid from_string(string_view).=C2=A0 Either return nil uuid on error, =
or throw an exception. (Note that nil is a valid result, so returning nil m=
eans you don&#39;t know if it is an error or a valid parse, unfortunately.=
=C2=A0 Might also consider expected&lt;uuid&gt; but nothing else in the STL=
 uses expected (and it is not in the STL yet))</div><div>It should be a fun=
ction because it is doing parsing, which feels more like a function (takes =
input, gives output) than a constructor.</div><div><br></div></div></blockq=
uote><div><br></div><div>still yes to the above<br></div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>- construct from a fixe=
d-size span&lt;const std::byte, 16&gt;. This makes &quot;wrong size&quot; n=
ot your problem.<br></div></div></blockquote><div><br></div><div>
<div>still yes.=C2=A0 Except uint8_t.</div><div>We need to say that the ord=
er matches the RFC</div><div><br></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>- not sure=
 whether the iterator constructor should stay - I suppose it is useful for =
non-contiguous cases.=C2=A0 Committee might make it UB if it is not 16 byte=
s.</div><div><br></div></div></blockquote><div><br></div>Do we even need th=
e end iterator?</div><div class=3D"gmail_quote"><br></div><div class=3D"gma=
il_quote"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div></div><div>- remove container-like stuff: size and iterators, typedefs=
, etc - just have a to_span() function that returns a span&lt;const std::by=
te, 16&gt;</div><div>(it probably never should have had mutable iterators, =
btw - we don&#39;t want to allow changing single bytes in a uuid)</div><div=
><br></div><div>Oh, wait - you were saying that the internal representation=
 might not be just bytes - is that important?</div></div></blockquote><div>=
<br></div><div>OK, so keep the container interface.=C2=A0 But only const_it=
erators.=C2=A0 Not mutable.</div><div>Is that a problem for writing into an=
 existing uuid?=C2=A0 Construct a new one and assign?=C2=A0 Let the compile=
r optimize it.</div><div>Or do we need the mutable iterators?=C2=A0 They se=
em wrong to me.<br></div><div><br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>I think we need to standardize the orde=
r.=C2=A0 Construction from a sequence of bytes should give the same uuid on=
 all machines.<br></div><div><br></div></div></blockquote><div><br></div><d=
iv>yes (refer to RFC)<br></div><div> <br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div></div><div>And we also need to define how the byte=
s turn into strings.</div><div><br></div></div></blockquote><div><br></div>=
<div>yes=C2=A0 (refer to RFC)<br></div><div> <br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div></div><br><div>- remove state_size.=C2=A0 =
sizeof(uuid) is good enough (Hmm, although it is technically not guaranteed=
 to be=C2=A0 =3D=3D 16, unless we add that in writing.=C2=A0 But it doesn&#=
39;t matter - use size() on the returned span)</div><div><br></div></div></=
blockquote><div><br></div><div>size()</div><div> <br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div></div><div>- rename nil to is_nil (or =
remove altogether - checking =3D=3D {} works)<br></div><div><br></div></div=
></blockquote><div><br></div><div>yes</div><div> <br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div></div><div>- add assignment from anoth=
er uuid<br></div><div><br></div></div></blockquote><div><br></div><div>yes<=
/div><div> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><=
/div><div>- should be trivially copyable, etc<br></div><div><br></div></div=
></blockquote><div><br></div><div>yes?</div><div><br></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"><div></div><div><br></div>=
<div>Basically, we want a class that is not much more than 16 bytes gathere=
d up.=C2=A0 They should almost always be treated as a whole, not parts.=C2=
=A0 So once you have the unique bytes inside the uuid, you can be sure that=
 they stay unique (as unique as wherever you constructed them from).</div><=
div>The invariant of the class is the uniqueness.=C2=A0 You can&#39;t actua=
lly guarantee that, but you can at least guarantee that a uuid (if not nil)=
 _maintains_ the invariant, if you assume all uuids are correct on construc=
tion.<br></div><div><br></div><div>(Would be interesting to consider move-o=
nly, to maintain uniqueness)<br></div></div></blockquote><div><br></div><di=
v>no.</div><div> <br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div></div><br clear=3D"all"></div></blockquote></div><br>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><d=
iv>Be seeing you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu-Xs2CMg42OJnhaunq6OKFTvfqMBnc=
7jY9n9bm8ZL3zA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu-Xs2CMg42=
OJnhaunq6OKFTvfqMBnc7jY9n9bm8ZL3zA%40mail.gmail.com</a>.<br />

--0000000000009dfbcc056e9fadfb--

.

On Thu, Jun 14, 2018 at 10:43 PM, Andrey Semashev
<andrey.semashev@gmail.com> wrote:
> On Thu, Jun 14, 2018 at 10:04 PM, Tony V E <tvaneerd@gmail.com> wrote:
>> On Thu, Jun 14, 2018 at 5:01 AM, Andrey Semashev <andrey.semashev@gmail.com>
>> wrote:
>>> On 06/14/18 06:11, Tony V E wrote:
>>>>
>>>> - remove container-like stuff: size and iterators, typedefs, etc - just
>>>> have a to_span() function that returns a span<const std::byte, 16>
>>>> (it probably never should have had mutable iterators, btw - we don't want
>>>> to allow changing single bytes in a uuid)
>>>>
>>>> Oh, wait - you were saying that the internal representation might not be
>>>> just bytes - is that important?
>>>
>>>
>>> This was my suggestion. I don't think we should use a span to expose the
>>> contents of uuid because it mandates representation (an array of bytes, big
>>> endian). This will harm performance. The point of iterators is that they may
>>> not be just pointers. For example, they could be reverse iterators on little
>>> endian machines.
>>
>> How much potential performance are we talking about?  Is it really worth it?
>> The RFC mandates network byte order (most significant first).  Does that
>> mean < can be just memcmp?
>>
>> Being able to use span simplifies a lot.
>>
>> And I'd like uuid to NOT be a container.  It is an ID.  Container-ness and
>> bytes are implementation details.
>>
>> But if performance can be shown to be important, then it is important.
>
> My primary concern is about the ordering operators. For example, in
> Boost.UUID there is an optimized implementation of operator< for SSE
> [1], in which you can see additional trickery that had to be
> implemented to accommodate for little endian native byte order.
> Ordering operators are often used in associative containers and
> sorting, which means lots of calls in a tight loop, so I would expect
> this to be a rather hot operation. I would really like if std::uuid
> didn't enforce this kind of implementation.
>
> [1] https://github.com/boostorg/uuid/blob/develop/include/boost/uuid/detail/uuid_x86.ipp#L98

In case you're interested, here are some benchmarks, including against
a memcmp-based version:

https://svn.boost.org/trac10/ticket/8509
https://svn.boost.org/trac10/attachment/ticket/8509/uuid_operators.txt

I didn't test a version that doesn't account for endianness, though.

>>>> - remove state_size.  sizeof(uuid) is good enough (Hmm, although it is
>>>> technically not guaranteed to be  == 16, unless we add that in writing.  But
>>>> it doesn't matter - use size() on the returned span)
>>>
>>> I think, uuid::size() should do. Using sizeof to determine the size of the
>>> UUID doesn't feel right.
>>
>> If it is not a container, you don't need size or sizeof at all. It is 16 by
>> definition.
>
> You do need a size if you want to export or import bytes into UUID.
> Yes, the size is always 16, but having it as a constant or another
> symbolic way would allow to avoid magic constants and silly typos in
> the user's code.
>
>>  (Hmmm, what if you are on a system with 9 or 16 bit bytes? I
>> guess there are still 16 *octets* and the iterators or span would still have
>> 16 entries.
>>
>> I guess uint8_t is better than std::byte, for that reason.
>
> Yes, we had this discussion before. The net result is that though the
> RFC defines UUID as an object 128-bit long, a platform with non-8-bit
> bytes would leave the excess bits of every byte unused and set to a
> predefined value so that they don't participate in the UUID value.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B6Bxzm_A4d%3DwOcUvQeOmq%3D4_oVxc2pPNhF0PjhDSAqqLHg%40mail.gmail.com.

.

On Thu, Jun 14, 2018 at 11:01 PM, 'Edward Catmur' via ISO C++ Standard
- Future Proposals <std-proposals@isocpp.org> wrote:
> On Thu, Jun 14, 2018 at 8:26 PM, Andrey Semashev <andrey.semashev@gmail.com>
> wrote:
>> On Thu, Jun 14, 2018 at 10:03 PM, Thiago Macieira <thiago@macieira.org>
>> wrote:
>> >
>> > Right, it may not work to provide a function returning std::span<byte,
>> > 16>,
>> > but instead a std::array<byte, 16> to get the actual bytes, if one needs
>> > them
>> > for some reason.
>>
>> This would mean that in order to export portable representation one
>> would have to copy the bytes as std::array first and then copy bytes
>> from that array to where they need to be (e.g. a shared memory region
>> or write to a file). In this case it might be better to have an export
>> method of std::uuid that takes an output iterator, which will receive
>> the bytes.
>
> With Ranges TS one can write ranges::copy(uuid.as_bytes(), OutputIterator).
> I don't think an export() method would really add anything.

If as_bytes() returns std::span<std::byte, 16> then the problem with
enforced internal representation remains.

>> We have native_handle() in std::mutex and std::condition_variable. We
>> could add something like this to std::uuid, but frankly, I would
>> prefer if std::uuid didn't use GUID as implementation as it would make
>> its ordering inefficient.
>
> That wouldn't imply using GUID internally, native() could convert and return
> by value.

Oh, right.

> But what about platforms that don't have a native uuid type?

AFAIR, the standard says that native_handle() may not be present if
the platform doesn't provide it. std::uuid::native() could be defined
similarly.

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

.

--00000000000061d972056ea00c52
Content-Type: text/plain; charset="UTF-8"

On Thu, Jun 14, 2018 at 4:28 PM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On Thu, Jun 14, 2018 at 11:01 PM, 'Edward Catmur' via ISO C++ Standard
> - Future Proposals <std-proposals@isocpp.org> wrote:
> > On Thu, Jun 14, 2018 at 8:26 PM, Andrey Semashev <
> andrey.semashev@gmail.com>
> > wrote:
> >> On Thu, Jun 14, 2018 at 10:03 PM, Thiago Macieira <thiago@macieira.org>
> >> wrote:
> >> >
> >> > Right, it may not work to provide a function returning std::span<byte,
> >> > 16>,
> >> > but instead a std::array<byte, 16> to get the actual bytes, if one
> needs
> >> > them
> >> > for some reason.
> >>
> >> This would mean that in order to export portable representation one
> >> would have to copy the bytes as std::array first and then copy bytes
> >> from that array to where they need to be (e.g. a shared memory region
> >> or write to a file). In this case it might be better to have an export
> >> method of std::uuid that takes an output iterator, which will receive
> >> the bytes.
> >
> > With Ranges TS one can write ranges::copy(uuid.as_bytes(),
> OutputIterator).
> > I don't think an export() method would really add anything.
>
> If as_bytes() returns std::span<std::byte, 16> then the problem with
> enforced internal representation remains.
>
> >> We have native_handle() in std::mutex and std::condition_variable. We
> >> could add something like this to std::uuid, but frankly, I would
> >> prefer if std::uuid didn't use GUID as implementation as it would make
> >> its ordering inefficient.
> >
> > That wouldn't imply using GUID internally, native() could convert and
> return
> > by value.
>
> Oh, right.
>
> > But what about platforms that don't have a native uuid type?
>
> AFAIR, the standard says that native_handle() may not be present if
> the platform doesn't provide it. std::uuid::native() could be defined
> similarly.
>


I'd rather just make it easy to write to_GUID as a free function.
It is a good test case to see whether we defined the API well.


--
Be seeing you,
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivTP%2Bbasi_PtDgMhgjto%2BWoBWaXi3%2BzFYbowzcxvzU6_A%40mail.gmail.com.

--00000000000061d972056ea00c52
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 14, 2018 at 4:28 PM, Andrey Semashev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semas=
hev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
 class=3D"">On Thu, Jun 14, 2018 at 11:01 PM, &#39;Edward Catmur&#39; via I=
SO C++ Standard<br>
- Future Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org">std-prop=
osals@isocpp.org</a>&gt; wrote:<br>
&gt; On Thu, Jun 14, 2018 at 8:26 PM, Andrey Semashev &lt;<a href=3D"mailto=
:andrey.semashev@gmail.com">andrey.semashev@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt; On Thu, Jun 14, 2018 at 10:03 PM, Thiago Macieira &lt;<a href=3D"m=
ailto:thiago@macieira.org">thiago@macieira.org</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt; &gt;<br>
</span><span class=3D"">&gt;&gt; &gt; Right, it may not work to provide a f=
unction returning std::span&lt;byte,<br>
&gt;&gt; &gt; 16&gt;,<br>
&gt;&gt; &gt; but instead a std::array&lt;byte, 16&gt; to get the actual by=
tes, if one needs<br>
&gt;&gt; &gt; them<br>
&gt;&gt; &gt; for some reason.<br>
&gt;&gt;<br>
&gt;&gt; This would mean that in order to export portable representation on=
e<br>
&gt;&gt; would have to copy the bytes as std::array first and then copy byt=
es<br>
&gt;&gt; from that array to where they need to be (e.g. a shared memory reg=
ion<br>
&gt;&gt; or write to a file). In this case it might be better to have an ex=
port<br>
&gt;&gt; method of std::uuid that takes an output iterator, which will rece=
ive<br>
&gt;&gt; the bytes.<br>
&gt;<br>
&gt; With Ranges TS one can write ranges::copy(uuid.as_bytes(), OutputItera=
tor).<br>
&gt; I don&#39;t think an export() method would really add anything.<br>
<br>
</span>If as_bytes() returns std::span&lt;std::byte, 16&gt; then the proble=
m with<br>
enforced internal representation remains.<br>
<span class=3D""><br>
&gt;&gt; We have native_handle() in std::mutex and std::condition_variable.=
 We<br>
&gt;&gt; could add something like this to std::uuid, but frankly, I would<b=
r>
&gt;&gt; prefer if std::uuid didn&#39;t use GUID as implementation as it wo=
uld make<br>
&gt;&gt; its ordering inefficient.<br>
&gt;<br>
&gt; That wouldn&#39;t imply using GUID internally, native() could convert =
and return<br>
&gt; by value.<br>
<br>
</span>Oh, right.<br>
<span class=3D""><br>
&gt; But what about platforms that don&#39;t have a native uuid type?<br>
<br>
</span>AFAIR, the standard says that native_handle() may not be present if<=
br>
the platform doesn&#39;t provide it. std::uuid::native() could be defined<b=
r>
similarly.<br>
<span class=3D""></span></blockquote></div></div><br><div class=3D"gmail_ex=
tra"><br></div><div class=3D"gmail_extra">I&#39;d rather just make it easy =
to write to_GUID as a free function.</div><div class=3D"gmail_extra">It is =
a good test case to see whether we defined the API well.</div><div class=3D=
"gmail_extra"><br clear=3D"all"></div><div class=3D"gmail_extra"><br>-- <br=
><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=
=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivTP%2Bbasi_PtDgMhgjto%2BWoBWaX=
i3%2BzFYbowzcxvzU6_A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivTP%=
2Bbasi_PtDgMhgjto%2BWoBWaXi3%2BzFYbowzcxvzU6_A%40mail.gmail.com</a>.<br />

--00000000000061d972056ea00c52--

.

On Thu, Jun 14, 2018 at 11:09 PM, Tony V E <tvaneerd@gmail.com> wrote:
> OK, revising, based on latest emails:
>
> On Wed, Jun 13, 2018 at 11:11 PM, Tony V E <tvaneerd@gmail.com> wrote:
>>
>> - construct from a fixed-size span<const std::byte, 16>. This makes "wrong
>> size" not your problem.
>
> still yes.  Except uint8_t.
> We need to say that the order matches the RFC

Personally, I'd prefer span<const T, 16> where T is one of std::byte,
unsigned char, signed char or char. std::byte is rather cumbersome to
use, most of the time you get some variant of char from external
sources.

uint8_t would limit std::uuid to only platforms with 8-bit bytes. This
is probably unnecessary.

>> - not sure whether the iterator constructor should stay - I suppose it is
>> useful for non-contiguous cases.  Committee might make it UB if it is not 16
>> bytes.
>
> Do we even need the end iterator?

Some implementations might want to use it for debugging purposes.

>> - remove container-like stuff: size and iterators, typedefs, etc - just
>> have a to_span() function that returns a span<const std::byte, 16>
>> (it probably never should have had mutable iterators, btw - we don't want
>> to allow changing single bytes in a uuid)
>>
>> Oh, wait - you were saying that the internal representation might not be
>> just bytes - is that important?
>
> OK, so keep the container interface.  But only const_iterators.  Not
> mutable.
> Is that a problem for writing into an existing uuid?  Construct a new one
> and assign?  Let the compiler optimize it.
> Or do we need the mutable iterators?  They seem wrong to me.

I'd be ok with only const_iterators.

>> - should be trivially copyable, etc
>
> yes?

I don't see an immediate use case that requires trivial copyability,
but if it happens to be trivially copyable, why not.

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

.

--000000000000399af9056ea05dd2
Content-Type: text/plain; charset="UTF-8"

On Thu, Jun 14, 2018 at 4:43 PM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On Thu, Jun 14, 2018 at 11:09 PM, Tony V E <tvaneerd@gmail.com> wrote:
> > OK, revising, based on latest emails:
> >
> > On Wed, Jun 13, 2018 at 11:11 PM, Tony V E <tvaneerd@gmail.com> wrote:
> >>
> >> - construct from a fixed-size span<const std::byte, 16>. This makes
> "wrong
> >> size" not your problem.
> >
> > still yes.  Except uint8_t.
> > We need to say that the order matches the RFC
>
> Personally, I'd prefer span<const T, 16> where T is one of std::byte,
> unsigned char, signed char or char. std::byte is rather cumbersome to
> use, most of the time you get some variant of char from external
> sources.
>

Let's keep signed char and char out of it.  We are really talking numbers
between 0 and 255.
So
unsigned char - fine
byte - hard to use
uint8_t - not guaranteed to exist

uint_least8_t?
short short short int?



> uint8_t would limit std::uuid to only platforms with 8-bit bytes. This
> is probably unnecessary.
>
> >> - not sure whether the iterator constructor should stay - I suppose it
> is
> >> useful for non-contiguous cases.  Committee might make it UB if it is
> not 16
> >> bytes.
> >
> > Do we even need the end iterator?
>
> Some implementations might want to use it for debugging purposes.
>
> >> - remove container-like stuff: size and iterators, typedefs, etc - just
> >> have a to_span() function that returns a span<const std::byte, 16>
> >> (it probably never should have had mutable iterators, btw - we don't
> want
> >> to allow changing single bytes in a uuid)
> >>
> >> Oh, wait - you were saying that the internal representation might not be
> >> just bytes - is that important?
> >
> > OK, so keep the container interface.  But only const_iterators.  Not
> > mutable.
> > Is that a problem for writing into an existing uuid?  Construct a new one
> > and assign?  Let the compiler optimize it.
> > Or do we need the mutable iterators?  They seem wrong to me.
>
> I'd be ok with only const_iterators.
>
> >> - should be trivially copyable, etc
> >
> > yes?
>
> I don't see an immediate use case that requires trivial copyability,
> but if it happens to be trivially copyable, why not.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAEhD%2B6Djfqg17%
> 2BCRyX4qxWA0YuEAk6doySZQ6Q-e5MFp5V9zYA%40mail.gmail.com.
>



--
Be seeing you,
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbit7ijVu_Q4eKFFUR-vDoEUCSOvA_Y-LMJPaAHRwgn074w%40mail.gmail.com.

--000000000000399af9056ea05dd2
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 14, 2018 at 4:43 PM, Andrey Semashev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semas=
hev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
 class=3D"">On Thu, Jun 14, 2018 at 11:09 PM, Tony V E &lt;<a href=3D"mailt=
o:tvaneerd@gmail.com">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt; OK, revising, based on latest emails:<br>
&gt;<br>
&gt; On Wed, Jun 13, 2018 at 11:11 PM, Tony V E &lt;<a href=3D"mailto:tvane=
erd@gmail.com">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
</span><span class=3D"">&gt;&gt; - construct from a fixed-size span&lt;cons=
t std::byte, 16&gt;. This makes &quot;wrong<br>
&gt;&gt; size&quot; not your problem.<br>
&gt;<br>
&gt; still yes.=C2=A0 Except uint8_t.<br>
&gt; We need to say that the order matches the RFC<br>
<br>
</span>Personally, I&#39;d prefer span&lt;const T, 16&gt; where T is one of=
 std::byte,<br>
unsigned char, signed char or char. std::byte is rather cumbersome to<br>
use, most of the time you get some variant of char from external<br>
sources.<br></blockquote><div><br></div><div>Let&#39;s keep signed char and=
 char out of it.=C2=A0 We are really talking numbers between 0 and 255.</di=
v><div>So</div><div>unsigned char - fine</div><div>byte - hard to use</div>=
<div>uint8_t - not guaranteed to exist</div><div><br></div><div>uint_least8=
_t?<br></div><div></div><div>short short short int?<br></div><div><br></div=
><div> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
uint8_t would limit std::uuid to only platforms with 8-bit bytes. This<br>
is probably unnecessary.<br>
<span class=3D""><br>
&gt;&gt; - not sure whether the iterator constructor should stay - I suppos=
e it is<br>
&gt;&gt; useful for non-contiguous cases.=C2=A0 Committee might make it UB =
if it is not 16<br>
&gt;&gt; bytes.<br>
&gt;<br>
&gt; Do we even need the end iterator?<br>
<br>
</span>Some implementations might want to use it for debugging purposes.<br=
>
<span class=3D""><br>
&gt;&gt; - remove container-like stuff: size and iterators, typedefs, etc -=
 just<br>
&gt;&gt; have a to_span() function that returns a span&lt;const std::byte, =
16&gt;<br>
&gt;&gt; (it probably never should have had mutable iterators, btw - we don=
&#39;t want<br>
&gt;&gt; to allow changing single bytes in a uuid)<br>
&gt;&gt;<br>
&gt;&gt; Oh, wait - you were saying that the internal representation might =
not be<br>
&gt;&gt; just bytes - is that important?<br>
&gt;<br>
&gt; OK, so keep the container interface.=C2=A0 But only const_iterators.=
=C2=A0 Not<br>
&gt; mutable.<br>
&gt; Is that a problem for writing into an existing uuid?=C2=A0 Construct a=
 new one<br>
&gt; and assign?=C2=A0 Let the compiler optimize it.<br>
&gt; Or do we need the mutable iterators?=C2=A0 They seem wrong to me.<br>
<br>
</span>I&#39;d be ok with only const_iterators.<br>
<span class=3D""><br>
&gt;&gt; - should be trivially copyable, etc<br>
&gt;<br>
&gt; yes?<br>
<br>
</span>I don&#39;t see an immediate use case that requires trivial copyabil=
ity,<br>
but if it happens to be trivially copyable, why not.<br>
<span class=3D""><br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B6Djfqg17%2BCRyX4qxWA0Y=
uEAk6doySZQ6Q-e5MFp5V9zYA%40mail.gmail.com" rel=3D"noreferrer" target=3D"_b=
lank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposal=
s/CAEhD%2B6Djfqg17%<wbr>2BCRyX4qxWA0YuEAk6doySZQ6Q-<wbr>e5MFp5V9zYA%40mail.=
gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbit7ijVu_Q4eKFFUR-vDoEUCSOvA_Y-L=
MJPaAHRwgn074w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbit7ijVu_Q4e=
KFFUR-vDoEUCSOvA_Y-LMJPaAHRwgn074w%40mail.gmail.com</a>.<br />

--000000000000399af9056ea05dd2--

.

--000000000000b916c1056ea0aa8d
Content-Type: text/plain; charset="UTF-8"

On Thu, Jun 14, 2018 at 9:28 PM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On Thu, Jun 14, 2018 at 11:01 PM, 'Edward Catmur' via ISO C++ Standard
> - Future Proposals <std-proposals@isocpp.org> wrote:
> > On Thu, Jun 14, 2018 at 8:26 PM, Andrey Semashev <
> andrey.semashev@gmail.com>
> > wrote:
> >> On Thu, Jun 14, 2018 at 10:03 PM, Thiago Macieira <thiago@macieira.org>
> >> wrote:
> >> >
> >> > Right, it may not work to provide a function returning std::span<byte,
> >> > 16>,
> >> > but instead a std::array<byte, 16> to get the actual bytes, if one
> needs
> >> > them
> >> > for some reason.
> >>
> >> This would mean that in order to export portable representation one
> >> would have to copy the bytes as std::array first and then copy bytes
> >> from that array to where they need to be (e.g. a shared memory region
> >> or write to a file). In this case it might be better to have an export
> >> method of std::uuid that takes an output iterator, which will receive
> >> the bytes.
> >
> > With Ranges TS one can write ranges::copy(uuid.as_bytes(),
> OutputIterator).
> > I don't think an export() method would really add anything.
>
> If as_bytes() returns std::span<std::byte, 16> then the problem with
> enforced internal representation remains.
>

Sure, that's why it should return std::array.

If you're concerned about runtime efficiency, std::array<std::byte, 16> can
fit into the two return registers (%rax, %rdx). But far more likely it
would be inlined and the codegen for copy(as_bytes(), OutputIterator) would
be identical to that for an export() member function.

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

--000000000000b916c1056ea0aa8d
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 14, 2018 at 9:28 PM, Andrey Semashev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semas=
hev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Th=
u, Jun 14, 2018 at 11:01 PM, &#39;Edward Catmur&#39; via ISO C++ Standard<b=
r>
- Future Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org">std-prop=
osals@isocpp.org</a>&gt; wrote:<br>
&gt; On Thu, Jun 14, 2018 at 8:26 PM, Andrey Semashev &lt;<a href=3D"mailto=
:andrey.semashev@gmail.com">andrey.semashev@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt; On Thu, Jun 14, 2018 at 10:03 PM, Thiago Macieira &lt;<a href=3D"m=
ailto:thiago@macieira.org">thiago@macieira.org</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Right, it may not work to provide a function returning std::s=
pan&lt;byte,<br>
&gt;&gt; &gt; 16&gt;,<br>
&gt;&gt; &gt; but instead a std::array&lt;byte, 16&gt; to get the actual by=
tes, if one needs<br>
&gt;&gt; &gt; them<br>
&gt;&gt; &gt; for some reason.<br>
&gt;&gt;<br>
&gt;&gt; This would mean that in order to export portable representation on=
e<br>
&gt;&gt; would have to copy the bytes as std::array first and then copy byt=
es<br>
&gt;&gt; from that array to where they need to be (e.g. a shared memory reg=
ion<br>
&gt;&gt; or write to a file). In this case it might be better to have an ex=
port<br>
&gt;&gt; method of std::uuid that takes an output iterator, which will rece=
ive<br>
&gt;&gt; the bytes.<br>
&gt;<br>
&gt; With Ranges TS one can write ranges::copy(uuid.as_bytes(), OutputItera=
tor).<br>
&gt; I don&#39;t think an export() method would really add anything.<br>
<br>
If as_bytes() returns std::span&lt;std::byte, 16&gt; then the problem with<=
br>
enforced internal representation remains.<br></blockquote><div>=C2=A0</div>=
<div>Sure, that&#39;s why it should return std::array.</div><div><br></div>=
<div>If you&#39;re concerned about runtime efficiency, std::array&lt;std::b=
yte, 16&gt; can fit into the two return registers (%rax, %rdx). But far mor=
e likely it would be inlined and the codegen for copy(<span style=3D"font-s=
ize:small;background-color:rgb(255,255,255);text-decoration-style:initial;t=
ext-decoration-color:initial;float:none;display:inline">as_bytes(), OutputI=
terator</span>) would be identical to that for an export() member function.=
</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdObUuJiiD7qQBSPRVbYwQ0n_4dKCF62R=
QACw0UxQ6-tt8w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObUuJiiD7qQ=
BSPRVbYwQ0n_4dKCF62RQACw0UxQ6-tt8w%40mail.gmail.com</a>.<br />

--000000000000b916c1056ea0aa8d--

.

--0000000000006e34af056ea0d9b5
Content-Type: text/plain; charset="UTF-8"

On Thu, Jun 14, 2018 at 9:36 PM, Tony V E <tvaneerd@gmail.com> wrote:

>
>
> On Thu, Jun 14, 2018 at 4:28 PM, Andrey Semashev <
> andrey.semashev@gmail.com> wrote:
>
>> On Thu, Jun 14, 2018 at 11:01 PM, 'Edward Catmur' via ISO C++ Standard
>> - Future Proposals <std-proposals@isocpp.org> wrote:
>> > On Thu, Jun 14, 2018 at 8:26 PM, Andrey Semashev <
>> andrey.semashev@gmail.com>
>> > wrote:
>> >> On Thu, Jun 14, 2018 at 10:03 PM, Thiago Macieira <thiago@macieira.org
>> >
>> >> wrote:
>> >> >
>> >> > Right, it may not work to provide a function returning
>> std::span<byte,
>> >> > 16>,
>> >> > but instead a std::array<byte, 16> to get the actual bytes, if one
>> needs
>> >> > them
>> >> > for some reason.
>> >>
>> >> This would mean that in order to export portable representation one
>> >> would have to copy the bytes as std::array first and then copy bytes
>> >> from that array to where they need to be (e.g. a shared memory region
>> >> or write to a file). In this case it might be better to have an export
>> >> method of std::uuid that takes an output iterator, which will receive
>> >> the bytes.
>> >
>> > With Ranges TS one can write ranges::copy(uuid.as_bytes(),
>> OutputIterator).
>> > I don't think an export() method would really add anything.
>>
>> If as_bytes() returns std::span<std::byte, 16> then the problem with
>> enforced internal representation remains.
>>
>> >> We have native_handle() in std::mutex and std::condition_variable. We
>> >> could add something like this to std::uuid, but frankly, I would
>> >> prefer if std::uuid didn't use GUID as implementation as it would make
>> >> its ordering inefficient.
>> >
>> > That wouldn't imply using GUID internally, native() could convert and
>> return
>> > by value.
>>
>> Oh, right.
>>
>> > But what about platforms that don't have a native uuid type?
>>
>> AFAIR, the standard says that native_handle() may not be present if
>> the platform doesn't provide it. std::uuid::native() could be defined
>> similarly.
>>
>
>
> I'd rather just make it easy to write to_GUID as a free function.
> It is a good test case to see whether we defined the API well.
>
>
We'd need access to the individual parts:

struct _GUID to_GUID(std::uuid u) {
    struct _GUID g{u.time_low(), u.time_mid(), uuid.time_hi_and_version()};
    ranges::copy(u.as_bytes() | view::slice(8, 16), g.Data4);
    return g;
}

But this is still non-trivial to write.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZmx%3D47WEWJW11mk5bM-1qAP_DdnVAEX0uGJRmPxy%3DKig%40mail.gmail.com.

--0000000000006e34af056ea0d9b5
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 14, 2018 at 9:36 PM, Tony V E <span dir=3D"ltr">&lt;<a href=
=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div=
 class=3D"h5"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On Thu, Jun 14, 2018 at 4:28 PM, Andrey Semashev <span dir=3D"ltr">&lt;<a =
href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev=
@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On=
 Thu, Jun 14, 2018 at 11:01 PM, &#39;Edward Catmur&#39; via ISO C++ Standar=
d<br>
- Future Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org" target=
=3D"_blank">std-proposals@isocpp.org</a>&gt; wrote:<br>
&gt; On Thu, Jun 14, 2018 at 8:26 PM, Andrey Semashev &lt;<a href=3D"mailto=
:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gmail.com</a>=
&gt;<br>
&gt; wrote:<br>
&gt;&gt; On Thu, Jun 14, 2018 at 10:03 PM, Thiago Macieira &lt;<a href=3D"m=
ailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;<br=
>
&gt;&gt; wrote:<br>
&gt;&gt; &gt;<br>
</span><span>&gt;&gt; &gt; Right, it may not work to provide a function ret=
urning std::span&lt;byte,<br>
&gt;&gt; &gt; 16&gt;,<br>
&gt;&gt; &gt; but instead a std::array&lt;byte, 16&gt; to get the actual by=
tes, if one needs<br>
&gt;&gt; &gt; them<br>
&gt;&gt; &gt; for some reason.<br>
&gt;&gt;<br>
&gt;&gt; This would mean that in order to export portable representation on=
e<br>
&gt;&gt; would have to copy the bytes as std::array first and then copy byt=
es<br>
&gt;&gt; from that array to where they need to be (e.g. a shared memory reg=
ion<br>
&gt;&gt; or write to a file). In this case it might be better to have an ex=
port<br>
&gt;&gt; method of std::uuid that takes an output iterator, which will rece=
ive<br>
&gt;&gt; the bytes.<br>
&gt;<br>
&gt; With Ranges TS one can write ranges::copy(uuid.as_bytes(), OutputItera=
tor).<br>
&gt; I don&#39;t think an export() method would really add anything.<br>
<br>
</span>If as_bytes() returns std::span&lt;std::byte, 16&gt; then the proble=
m with<br>
enforced internal representation remains.<br>
<span><br>
&gt;&gt; We have native_handle() in std::mutex and std::condition_variable.=
 We<br>
&gt;&gt; could add something like this to std::uuid, but frankly, I would<b=
r>
&gt;&gt; prefer if std::uuid didn&#39;t use GUID as implementation as it wo=
uld make<br>
&gt;&gt; its ordering inefficient.<br>
&gt;<br>
&gt; That wouldn&#39;t imply using GUID internally, native() could convert =
and return<br>
&gt; by value.<br>
<br>
</span>Oh, right.<br>
<span><br>
&gt; But what about platforms that don&#39;t have a native uuid type?<br>
<br>
</span>AFAIR, the standard says that native_handle() may not be present if<=
br>
the platform doesn&#39;t provide it. std::uuid::native() could be defined<b=
r>
similarly.<br>
<span></span></blockquote></div></div><br><div class=3D"gmail_extra"><br></=
div></div></div><div class=3D"gmail_extra">I&#39;d rather just make it easy=
 to write to_GUID as a free function.</div><div class=3D"gmail_extra">It is=
 a good test case to see whether we defined the API well.</div><div class=
=3D"gmail_extra"><br></div></div></blockquote><div><br></div><div>We&#39;d =
need access to the individual parts:</div><div><br></div><div><font face=3D=
"monospace, monospace">struct _GUID to_GUID(std::uuid u) {</font></div><div=
><font face=3D"monospace, monospace">=C2=A0 =C2=A0 struct _GUID g{u.time_lo=
w(), u.time_mid(), uuid.time_hi_and_version()};</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 ranges::copy(u.as_bytes() | view::s=
lice(8, 16), g.Data4);</font></div><div><font face=3D"monospace, monospace"=
>=C2=A0 =C2=A0 return g;</font></div><div><font face=3D"monospace, monospac=
e">}</font></div><div><br></div><div>But this is still non-trivial to write=
..</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZmx%3D47WEWJW11mk5bM-1qAP_DdnV=
AEX0uGJRmPxy%3DKig%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZmx%3D=
47WEWJW11mk5bM-1qAP_DdnVAEX0uGJRmPxy%3DKig%40mail.gmail.com</a>.<br />

--0000000000006e34af056ea0d9b5--

.

On Thursday, 14 June 2018 12:26:10 PDT Andrey Semashev wrote:
> > For example, the implementation on Windows may want to be
> > layout-compatible
> > with the GUID structure[1] to facilitate copying to and from that type
> > (QUuid does that). As a side-effect, it means the first 8 bytes are not
> > in the correct order for a byte-level access on little-endian machines.
>
> I'm not sure having std::uuid layout compatible with GUID would be
> helpful. Users would have to perform a reinterpret_cast in order to
> employ this feature, and this would be generally UB and certainly not
> something we want to encourage.

I didn't mean to have this as a front-end visible feature. Instead, it would
be an internal optimisation for the conversion function:

> > By the way, what's the policy on allowing the implementation to provide
> > member functions to convert to and from native structures like GUID?
>
> We have native_handle() in std::mutex and std::condition_variable. We
> could add something like this to std::uuid, but frankly, I would
> prefer if std::uuid didn't use GUID as implementation as it would make
> its ordering inefficient.

It's a QoI on what it chooses to make efficient: the copy to the byte
representation specified by RFC 4122 or the GUID representation.

One of the two will have three byte-swap operations.

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



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

.

On Thu, Jun 14, 2018 at 11:58 PM, Tony V E <tvaneerd@gmail.com> wrote:
> On Thu, Jun 14, 2018 at 4:43 PM, Andrey Semashev <andrey.semashev@gmail.com>
> wrote:
>>
>> On Thu, Jun 14, 2018 at 11:09 PM, Tony V E <tvaneerd@gmail.com> wrote:
>> > OK, revising, based on latest emails:
>> >
>> > On Wed, Jun 13, 2018 at 11:11 PM, Tony V E <tvaneerd@gmail.com> wrote:
>> >>
>> >> - construct from a fixed-size span<const std::byte, 16>. This makes
>> >> "wrong
>> >> size" not your problem.
>> >
>> > still yes.  Except uint8_t.
>> > We need to say that the order matches the RFC
>>
>> Personally, I'd prefer span<const T, 16> where T is one of std::byte,
>> unsigned char, signed char or char. std::byte is rather cumbersome to
>> use, most of the time you get some variant of char from external
>> sources.
>
> Let's keep signed char and char out of it.  We are really talking numbers
> between 0 and 255.
> So
> unsigned char - fine
> byte - hard to use
> uint8_t - not guaranteed to exist
>
> uint_least8_t?
> short short short int?

I think, unsigned char, std::byte and uint8_t (if supported) are fine.

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

.

--000000000000577178056ea0e305
Content-Type: text/plain; charset="UTF-8"

On Thu, Jun 14, 2018 at 9:43 PM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On Thu, Jun 14, 2018 at 11:09 PM, Tony V E <tvaneerd@gmail.com> wrote:
> > OK, revising, based on latest emails:
> >
> > On Wed, Jun 13, 2018 at 11:11 PM, Tony V E <tvaneerd@gmail.com> wrote:
> >>
> >> - construct from a fixed-size span<const std::byte, 16>. This makes
> "wrong
> >> size" not your problem.
> >
> > still yes.  Except uint8_t.
> > We need to say that the order matches the RFC
>
> Personally, I'd prefer span<const T, 16> where T is one of std::byte,
> unsigned char, signed char or char. std::byte is rather cumbersome to
> use, most of the time you get some variant of char from external
> sources.
>
> uint8_t would limit std::uuid to only platforms with 8-bit bytes. This
> is probably unnecessary.
>
> >> - not sure whether the iterator constructor should stay - I suppose it
> is
> >> useful for non-contiguous cases.  Committee might make it UB if it is
> not 16
> >> bytes.
> >
> > Do we even need the end iterator?
>
> Some implementations might want to use it for debugging purposes.
>
> >> - remove container-like stuff: size and iterators, typedefs, etc - just
> >> have a to_span() function that returns a span<const std::byte, 16>
> >> (it probably never should have had mutable iterators, btw - we don't
> want
> >> to allow changing single bytes in a uuid)
> >>
> >> Oh, wait - you were saying that the internal representation might not be
> >> just bytes - is that important?
> >
> > OK, so keep the container interface.  But only const_iterators.  Not
> > mutable.
> > Is that a problem for writing into an existing uuid?  Construct a new one
> > and assign?  Let the compiler optimize it.
> > Or do we need the mutable iterators?  They seem wrong to me.
>
> I'd be ok with only const_iterators.
>
> >> - should be trivially copyable, etc
> >
> > yes?
>
> I don't see an immediate use case that requires trivial copyability,
> but if it happens to be trivially copyable, why not.
>

We want to be able to pass uuid by value, in registers (2 general-purpose
or 1 SSE). This requires trivial copyability (or [[trivial_abi]], but
that's platform-dependent at present).

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

--000000000000577178056ea0e305
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jun 14, 2018 at 9:43 PM, Andrey Semashev <span dir=3D"ltr">&lt;<a href=
=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Jun =
14, 2018 at 11:09 PM, Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com">tv=
aneerd@gmail.com</a>&gt; wrote:<br>
&gt; OK, revising, based on latest emails:<br>
&gt;<br>
&gt; On Wed, Jun 13, 2018 at 11:11 PM, Tony V E &lt;<a href=3D"mailto:tvane=
erd@gmail.com">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; - construct from a fixed-size span&lt;const std::byte, 16&gt;. Thi=
s makes &quot;wrong<br>
&gt;&gt; size&quot; not your problem.<br>
&gt;<br>
&gt; still yes.=C2=A0 Except uint8_t.<br>
&gt; We need to say that the order matches the RFC<br>
<br>
Personally, I&#39;d prefer span&lt;const T, 16&gt; where T is one of std::b=
yte,<br>
unsigned char, signed char or char. std::byte is rather cumbersome to<br>
use, most of the time you get some variant of char from external<br>
sources.<br>
<br>
uint8_t would limit std::uuid to only platforms with 8-bit bytes. This<br>
is probably unnecessary.<br>
<br>
&gt;&gt; - not sure whether the iterator constructor should stay - I suppos=
e it is<br>
&gt;&gt; useful for non-contiguous cases.=C2=A0 Committee might make it UB =
if it is not 16<br>
&gt;&gt; bytes.<br>
&gt;<br>
&gt; Do we even need the end iterator?<br>
<br>
Some implementations might want to use it for debugging purposes.<br>
<br>
&gt;&gt; - remove container-like stuff: size and iterators, typedefs, etc -=
 just<br>
&gt;&gt; have a to_span() function that returns a span&lt;const std::byte, =
16&gt;<br>
&gt;&gt; (it probably never should have had mutable iterators, btw - we don=
&#39;t want<br>
&gt;&gt; to allow changing single bytes in a uuid)<br>
&gt;&gt;<br>
&gt;&gt; Oh, wait - you were saying that the internal representation might =
not be<br>
&gt;&gt; just bytes - is that important?<br>
&gt;<br>
&gt; OK, so keep the container interface.=C2=A0 But only const_iterators.=
=C2=A0 Not<br>
&gt; mutable.<br>
&gt; Is that a problem for writing into an existing uuid?=C2=A0 Construct a=
 new one<br>
&gt; and assign?=C2=A0 Let the compiler optimize it.<br>
&gt; Or do we need the mutable iterators?=C2=A0 They seem wrong to me.<br>
<br>
I&#39;d be ok with only const_iterators.<br>
<br>
&gt;&gt; - should be trivially copyable, etc<br>
&gt;<br>
&gt; yes?<br>
<br>
I don&#39;t see an immediate use case that requires trivial copyability,<br=
>
but if it happens to be trivially copyable, why not.<br></blockquote><div><=
br></div><div>We want to be able to pass uuid by value, in registers (2 gen=
eral-purpose or 1 SSE). This requires trivial copyability (or [[trivial_abi=
]], but that&#39;s platform-dependent at present).</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYoLqez8d-XbSR8EjJtT3V_96ybwDFR=
ffsgmR1%2BNXx8FA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYoLqez8d=
-XbSR8EjJtT3V_96ybwDFRffsgmR1%2BNXx8FA%40mail.gmail.com</a>.<br />

--000000000000577178056ea0e305--

.

On Thursday, 14 June 2018 14:20:20 PDT 'Edward Catmur' via ISO C++ Standard -
Future Proposals wrote:
> If you're concerned about runtime efficiency, std::array<std::byte, 16> can
> fit into the two return registers (%rax, %rdx).

Right. Code gen leaves a bit to be desired though:
 https://godbolt.org/g/r8jw4g

Windows ABI requires this type to be returned by implicit first parameter,
though. But as you say:

> But far more likely it
> would be inlined and the codegen for copy(as_bytes(), OutputIterator) would
> be identical to that for an export() member function.

I agree. That applies as well for the byte-swapping version.

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



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

.

On Fri, Jun 15, 2018 at 12:33 AM, 'Edward Catmur' via ISO C++ Standard
- Future Proposals <std-proposals@isocpp.org> wrote:
> On Thu, Jun 14, 2018 at 9:36 PM, Tony V E <tvaneerd@gmail.com> wrote:
>>
>> I'd rather just make it easy to write to_GUID as a free function.
>> It is a good test case to see whether we defined the API well.
>
> We'd need access to the individual parts:
>
> struct _GUID to_GUID(std::uuid u) {
>     struct _GUID g{u.time_low(), u.time_mid(), uuid.time_hi_and_version()};
>     ranges::copy(u.as_bytes() | view::slice(8, 16), g.Data4);
>     return g;
> }
>
> But this is still non-trivial to write.

It doesn't have to have access to individual parts. to_GUID could
populate GUID members from portable bytes in RFC format. With SSE it
might be possible to do with a single byte shuffle.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B6A_S3gsYqAXX-BqsgWk-c5kjdgDZejzKJgoWOre9q5W%3DQ%40mail.gmail.com.

.

--0000000000003ad2f3056eadb801
Content-Type: text/plain; charset="UTF-8"

On Thu, Jun 14, 2018 at 4:43 PM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On Thu, Jun 14, 2018 at 11:09 PM, Tony V E <tvaneerd@gmail.com> wrote:
> > OK, revising, based on latest emails:
> >
> > On Wed, Jun 13, 2018 at 11:11 PM, Tony V E <tvaneerd@gmail.com> wrote:
> >>
> >> - construct from a fixed-size span<const std::byte, 16>. This makes
> "wrong
> >> size" not your problem.
> >
> > still yes.  Except uint8_t.
> > We need to say that the order matches the RFC
>
> Personally, I'd prefer span<const T, 16> where T is one of std::byte,
> unsigned char, signed char or char. std::byte is rather cumbersome to
> use, most of the time you get some variant of char from external
> sources.
>
> uint8_t would limit std::uuid to only platforms with 8-bit bytes. This
> is probably unnecessary.
>
> >> - not sure whether the iterator constructor should stay - I suppose it
> is
> >> useful for non-contiguous cases.  Committee might make it UB if it is
> not 16
> >> bytes.
> >
> > Do we even need the end iterator?
>
> Some implementations might want to use it for debugging purposes.
>

That reminds me - the end iterator should be a separate type from the begin
iterator - ie Iterator begin, Sentinel end, like Ranges.
Or, actually, just take a Range, since Ranges are likely in C++20.



> >> - remove container-like stuff: size and iterators, typedefs, etc - just
> >> have a to_span() function that returns a span<const std::byte, 16>
> >> (it probably never should have had mutable iterators, btw - we don't
> want
> >> to allow changing single bytes in a uuid)
> >>
> >> Oh, wait - you were saying that the internal representation might not be
> >> just bytes - is that important?
> >
> > OK, so keep the container interface.  But only const_iterators.  Not
> > mutable.
> > Is that a problem for writing into an existing uuid?  Construct a new one
> > and assign?  Let the compiler optimize it.
> > Or do we need the mutable iterators?  They seem wrong to me.
>
> I'd be ok with only const_iterators.
>
> >> - should be trivially copyable, etc
> >
> > yes?
>
> I don't see an immediate use case that requires trivial copyability,
> but if it happens to be trivially copyable, why not.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAEhD%2B6Djfqg17%
> 2BCRyX4qxWA0YuEAk6doySZQ6Q-e5MFp5V9zYA%40mail.gmail.com.
>



--
Be seeing you,
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivzYngSA3G0yLr42Yap-Pn7C9TvdWdQsq0vbwUVZRKdmA%40mail.gmail.com.

--0000000000003ad2f3056eadb801
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 14, 2018 at 4:43 PM, Andrey Semashev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semas=
hev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
 class=3D"">On Thu, Jun 14, 2018 at 11:09 PM, Tony V E &lt;<a href=3D"mailt=
o:tvaneerd@gmail.com">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt; OK, revising, based on latest emails:<br>
&gt;<br>
&gt; On Wed, Jun 13, 2018 at 11:11 PM, Tony V E &lt;<a href=3D"mailto:tvane=
erd@gmail.com">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
</span><span class=3D"">&gt;&gt; - construct from a fixed-size span&lt;cons=
t std::byte, 16&gt;. This makes &quot;wrong<br>
&gt;&gt; size&quot; not your problem.<br>
&gt;<br>
&gt; still yes.=C2=A0 Except uint8_t.<br>
&gt; We need to say that the order matches the RFC<br>
<br>
</span>Personally, I&#39;d prefer span&lt;const T, 16&gt; where T is one of=
 std::byte,<br>
unsigned char, signed char or char. std::byte is rather cumbersome to<br>
use, most of the time you get some variant of char from external<br>
sources.<br>
<br>
uint8_t would limit std::uuid to only platforms with 8-bit bytes. This<br>
is probably unnecessary.<br>
<span class=3D""><br>
&gt;&gt; - not sure whether the iterator constructor should stay - I suppos=
e it is<br>
&gt;&gt; useful for non-contiguous cases.=C2=A0 Committee might make it UB =
if it is not 16<br>
&gt;&gt; bytes.<br>
&gt;<br>
&gt; Do we even need the end iterator?<br>
<br>
</span>Some implementations might want to use it for debugging purposes.<br=
></blockquote><div><br></div><div>That reminds me - the end iterator should=
 be a separate type from the begin iterator - ie Iterator begin, Sentinel e=
nd, like Ranges.</div><div>Or, actually, just take a Range, since Ranges ar=
e likely in C++20.</div><div><br></div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
<span class=3D""><br>
&gt;&gt; - remove container-like stuff: size and iterators, typedefs, etc -=
 just<br>
&gt;&gt; have a to_span() function that returns a span&lt;const std::byte, =
16&gt;<br>
&gt;&gt; (it probably never should have had mutable iterators, btw - we don=
&#39;t want<br>
&gt;&gt; to allow changing single bytes in a uuid)<br>
&gt;&gt;<br>
&gt;&gt; Oh, wait - you were saying that the internal representation might =
not be<br>
&gt;&gt; just bytes - is that important?<br>
&gt;<br>
&gt; OK, so keep the container interface.=C2=A0 But only const_iterators.=
=C2=A0 Not<br>
&gt; mutable.<br>
&gt; Is that a problem for writing into an existing uuid?=C2=A0 Construct a=
 new one<br>
&gt; and assign?=C2=A0 Let the compiler optimize it.<br>
&gt; Or do we need the mutable iterators?=C2=A0 They seem wrong to me.<br>
<br>
</span>I&#39;d be ok with only const_iterators.<br>
<span class=3D""><br>
&gt;&gt; - should be trivially copyable, etc<br>
&gt;<br>
&gt; yes?<br>
<br>
</span>I don&#39;t see an immediate use case that requires trivial copyabil=
ity,<br>
but if it happens to be trivially copyable, why not.<br>
<span class=3D""><br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B6Djfqg17%2BCRyX4qxWA0Y=
uEAk6doySZQ6Q-e5MFp5V9zYA%40mail.gmail.com" rel=3D"noreferrer" target=3D"_b=
lank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposal=
s/CAEhD%2B6Djfqg17%<wbr>2BCRyX4qxWA0YuEAk6doySZQ6Q-<wbr>e5MFp5V9zYA%40mail.=
gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivzYngSA3G0yLr42Yap-Pn7C9TvdWdQ=
sq0vbwUVZRKdmA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivzYngSA3G0=
yLr42Yap-Pn7C9TvdWdQsq0vbwUVZRKdmA%40mail.gmail.com</a>.<br />

--0000000000003ad2f3056eadb801--

.

--0000000000008a8add056f9f8e47
Content-Type: text/plain; charset="UTF-8"

Thank you for all the feedback here. I was a bit busy but finally made some
time to look into all the recent discussions here and summarize the things
that should be done in order to move further.

Here is a list of changes I have done based on the feedback:

   - Removed string constructors and replaced with free overloaded function
   from_string().
   - Parsing strings to uuid throws exception uuid_error instead of
   creating a nil uuid when the operation fails.
   - {} included in the supported format for parsing, i.e.
   "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}".
   - Removed state_size.
   - Renamed member function nil() to is_nil().
   - The default constructor is defaulted.
   - Added a conversion construct from std::span<std::byte, 16>.
   - Added the free function as_bytes() to convert the uuid into a view of
   its underlying bytes.
   - Constructing a uuid from a range with a size other than 16 is
   undefined behaviour.
   - Removed mutable iterators (but preserved the constant iterators).
   - Removed typedefs and others container-like parts.
   - Defined the correlation between the internal UUID bytes and the string
   representation.
   - Added UUID layout and byte order specification from the RFC 4122
   document.

To be honest, I am unsure whether the member function size() should stay or
not. As we don't want to make the uuid a container-like type perhaps this
should be removed too.

The revised proposal document is available here
https://github.com/mariusbancila/stduuid/blob/master/P0959.md for further
review.

Thank you,
Marius

On Fri, Jun 15, 2018 at 3:54 PM Tony V E <tvaneerd@gmail.com> wrote:

>
>
> On Thu, Jun 14, 2018 at 4:43 PM, Andrey Semashev <
> andrey.semashev@gmail.com> wrote:
>
>> On Thu, Jun 14, 2018 at 11:09 PM, Tony V E <tvaneerd@gmail.com> wrote:
>> > OK, revising, based on latest emails:
>> >
>> > On Wed, Jun 13, 2018 at 11:11 PM, Tony V E <tvaneerd@gmail.com> wrote:
>> >>
>> >> - construct from a fixed-size span<const std::byte, 16>. This makes
>> "wrong
>> >> size" not your problem.
>> >
>> > still yes.  Except uint8_t.
>> > We need to say that the order matches the RFC
>>
>> Personally, I'd prefer span<const T, 16> where T is one of std::byte,
>> unsigned char, signed char or char. std::byte is rather cumbersome to
>> use, most of the time you get some variant of char from external
>> sources.
>>
>> uint8_t would limit std::uuid to only platforms with 8-bit bytes. This
>> is probably unnecessary.
>>
>> >> - not sure whether the iterator constructor should stay - I suppose it
>> is
>> >> useful for non-contiguous cases.  Committee might make it UB if it is
>> not 16
>> >> bytes.
>> >
>> > Do we even need the end iterator?
>>
>> Some implementations might want to use it for debugging purposes.
>>
>
> That reminds me - the end iterator should be a separate type from the
> begin iterator - ie Iterator begin, Sentinel end, like Ranges.
> Or, actually, just take a Range, since Ranges are likely in C++20.
>
>
>
>> >> - remove container-like stuff: size and iterators, typedefs, etc - just
>> >> have a to_span() function that returns a span<const std::byte, 16>
>> >> (it probably never should have had mutable iterators, btw - we don't
>> want
>> >> to allow changing single bytes in a uuid)
>> >>
>> >> Oh, wait - you were saying that the internal representation might not
>> be
>> >> just bytes - is that important?
>> >
>> > OK, so keep the container interface.  But only const_iterators.  Not
>> > mutable.
>> > Is that a problem for writing into an existing uuid?  Construct a new
>> one
>> > and assign?  Let the compiler optimize it.
>> > Or do we need the mutable iterators?  They seem wrong to me.
>>
>> I'd be ok with only const_iterators.
>>
>> >> - should be trivially copyable, etc
>> >
>> > yes?
>>
>> I don't see an immediate use case that requires trivial copyability,
>> but if it happens to be trivially copyable, why not.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B6Djfqg17%2BCRyX4qxWA0YuEAk6doySZQ6Q-e5MFp5V9zYA%40mail.gmail.com
>> .
>>
>
>
>
> --
> Be seeing you,
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivzYngSA3G0yLr42Yap-Pn7C9TvdWdQsq0vbwUVZRKdmA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivzYngSA3G0yLr42Yap-Pn7C9TvdWdQsq0vbwUVZRKdmA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

--0000000000008a8add056f9f8e47
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you for all the feedback here. I was a bit busy but =
finally made some time to look into all the recent discussions here and sum=
marize the things that should be done in order to move further.<div><br></d=
iv><div>Here is a list of changes I have done based on the feedback:</div><=
div><ul><li>Removed string constructors and replaced with free overloaded f=
unction from_string().</li><li>Parsing strings to uuid throws exception uui=
d_error instead of creating a nil uuid when the operation fails.</li><li>{}=
 included in the supported format for parsing, i.e. &quot;{xxxxxxxx-xxxx-xx=
xx-xxxx-xxxxxxxxxxxx}&quot;.</li><li>Removed state_size.</li><li>Renamed me=
mber function nil() to is_nil().</li><li>The default constructor is default=
ed.</li><li>Added a conversion construct from std::span&lt;std::byte, 16&gt=
;.</li><li>Added the free function as_bytes() to convert the uuid into a vi=
ew of its underlying bytes.</li><li>Constructing a uuid from a range with a=
 size other than 16 is undefined behaviour.</li><li>Removed mutable iterato=
rs (but preserved the constant iterators).</li><li>Removed typedefs and oth=
ers container-like parts.</li><li>Defined the correlation between the inter=
nal UUID bytes and the string representation.</li><li>Added UUID layout and=
 byte order specification from the RFC 4122 document.</li></ul><div>To be h=
onest, I am unsure whether the member function size() should stay or not. A=
s we don&#39;t want to make the uuid a container-like type perhaps this sho=
uld be removed too.</div></div><div><br></div><div>The revised proposal doc=
ument is available here=C2=A0<a href=3D"https://github.com/mariusbancila/st=
duuid/blob/master/P0959.md">https://github.com/mariusbancila/stduuid/blob/m=
aster/P0959.md</a> for further review.</div><div><br></div><div>Thank you,<=
/div><div>Marius</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
>On Fri, Jun 15, 2018 at 3:54 PM Tony V E &lt;<a href=3D"mailto:tvaneerd@gm=
ail.com">tvaneerd@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Thu, Jun 14, 2018 at 4:43 PM, Andrey Semashev <span dir=3D"l=
tr">&lt;<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andr=
ey.semashev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><span>On Thu, Jun 14, 2018 at 11:09 PM, Tony V E &lt;<a href=3D"mailto:t=
vaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt; OK, revising, based on latest emails:<br>
&gt;<br>
&gt; On Wed, Jun 13, 2018 at 11:11 PM, Tony V E &lt;<a href=3D"mailto:tvane=
erd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
</span><span>&gt;&gt; - construct from a fixed-size span&lt;const std::byte=
, 16&gt;. This makes &quot;wrong<br>
&gt;&gt; size&quot; not your problem.<br>
&gt;<br>
&gt; still yes.=C2=A0 Except uint8_t.<br>
&gt; We need to say that the order matches the RFC<br>
<br>
</span>Personally, I&#39;d prefer span&lt;const T, 16&gt; where T is one of=
 std::byte,<br>
unsigned char, signed char or char. std::byte is rather cumbersome to<br>
use, most of the time you get some variant of char from external<br>
sources.<br>
<br>
uint8_t would limit std::uuid to only platforms with 8-bit bytes. This<br>
is probably unnecessary.<br>
<span><br>
&gt;&gt; - not sure whether the iterator constructor should stay - I suppos=
e it is<br>
&gt;&gt; useful for non-contiguous cases.=C2=A0 Committee might make it UB =
if it is not 16<br>
&gt;&gt; bytes.<br>
&gt;<br>
&gt; Do we even need the end iterator?<br>
<br>
</span>Some implementations might want to use it for debugging purposes.<br=
></blockquote><div><br></div><div>That reminds me - the end iterator should=
 be a separate type from the begin iterator - ie Iterator begin, Sentinel e=
nd, like Ranges.</div><div>Or, actually, just take a Range, since Ranges ar=
e likely in C++20.</div><div><br></div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
<span><br>
&gt;&gt; - remove container-like stuff: size and iterators, typedefs, etc -=
 just<br>
&gt;&gt; have a to_span() function that returns a span&lt;const std::byte, =
16&gt;<br>
&gt;&gt; (it probably never should have had mutable iterators, btw - we don=
&#39;t want<br>
&gt;&gt; to allow changing single bytes in a uuid)<br>
&gt;&gt;<br>
&gt;&gt; Oh, wait - you were saying that the internal representation might =
not be<br>
&gt;&gt; just bytes - is that important?<br>
&gt;<br>
&gt; OK, so keep the container interface.=C2=A0 But only const_iterators.=
=C2=A0 Not<br>
&gt; mutable.<br>
&gt; Is that a problem for writing into an existing uuid?=C2=A0 Construct a=
 new one<br>
&gt; and assign?=C2=A0 Let the compiler optimize it.<br>
&gt; Or do we need the mutable iterators?=C2=A0 They seem wrong to me.<br>
<br>
</span>I&#39;d be ok with only const_iterators.<br>
<span><br>
&gt;&gt; - should be trivially copyable, etc<br>
&gt;<br>
&gt; yes?<br>
<br>
</span>I don&#39;t see an immediate use case that requires trivial copyabil=
ity,<br>
but if it happens to be trivially copyable, why not.<br>
<span><br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B6Djfqg17%2BCRyX4qxWA0Y=
uEAk6doySZQ6Q-e5MFp5V9zYA%40mail.gmail.com" rel=3D"noreferrer" target=3D"_b=
lank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B=
6Djfqg17%2BCRyX4qxWA0YuEAk6doySZQ6Q-e5MFp5V9zYA%40mail.gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"m_-640981=
6038175448163gmail_signature" data-smartmail=3D"gmail_signature"><div dir=
=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivzYngSA3G0yLr42Yap-Pn7C9TvdWdQ=
sq0vbwUVZRKdmA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAOHCbivzYngSA3G0yLr42Yap-Pn7C9TvdWdQsq0vbwUVZRKdmA%40mail.gmail.com</=
a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxNbbrEPSycOPJPAiUtxLY6mTtGqj=
kGhYoT%2B9M5g4ByrA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxNbb=
rEPSycOPJPAiUtxLY6mTtGqjkGhYoT%2B9M5g4ByrA%40mail.gmail.com</a>.<br />

--0000000000008a8add056f9f8e47--

.

--0000000000003e0d83056fa0d2c9
Content-Type: text/plain; charset="UTF-8"

You seem to have a lot of functions/constructors that need constexpr :)

- uuid(std::span) -> std::span is constexpr enabled, so I don't see a
reason for this not to be constexpr
- uuid(FwdIt, FwdIt) -> this can also be constexpr
- swaps are now constexpr if possible (P0879), which in your case is okay
- begin and end can also be constexpr, there isn't a reason not to
- as_bytes can also be constexpr as std::span is constexpr enabled
- operator==, operator!= and operator< can also be constexpr

Is there a reason why there are a member and non member functions for
operator== and operator<?

Does it really make sense to provide a free function as_bytes? I don't
think we want that, at least I don't :)

I think it makes sense to use operator<=> instead of operator== and
operator!= (as an additional benefit, you can then use uuid as a non-type
template parameter).

I'm not an LWG person, but I think that everywhere in the standard library
using type = ... is used instead of typedef.

On Wed, Jun 27, 2018 at 3:26 PM Marius Bancila <marius.bancila@gmail.com>
wrote:

> Thank you for all the feedback here. I was a bit busy but finally made
> some time to look into all the recent discussions here and summarize the
> things that should be done in order to move further.
>
> Here is a list of changes I have done based on the feedback:
>
>    - Removed string constructors and replaced with free overloaded
>    function from_string().
>    - Parsing strings to uuid throws exception uuid_error instead of
>    creating a nil uuid when the operation fails.
>    - {} included in the supported format for parsing, i.e.
>    "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}".
>    - Removed state_size.
>    - Renamed member function nil() to is_nil().
>    - The default constructor is defaulted.
>    - Added a conversion construct from std::span<std::byte, 16>.
>    - Added the free function as_bytes() to convert the uuid into a view
>    of its underlying bytes.
>    - Constructing a uuid from a range with a size other than 16 is
>    undefined behaviour.
>    - Removed mutable iterators (but preserved the constant iterators).
>    - Removed typedefs and others container-like parts.
>    - Defined the correlation between the internal UUID bytes and the
>    string representation.
>    - Added UUID layout and byte order specification from the RFC 4122
>    document.
>
> To be honest, I am unsure whether the member function size() should stay
> or not. As we don't want to make the uuid a container-like type perhaps
> this should be removed too.
>
> The revised proposal document is available here
> https://github.com/mariusbancila/stduuid/blob/master/P0959.md for further
> review.
>
> Thank you,
> Marius
>
> On Fri, Jun 15, 2018 at 3:54 PM Tony V E <tvaneerd@gmail.com> wrote:
>
>>
>>
>> On Thu, Jun 14, 2018 at 4:43 PM, Andrey Semashev <
>> andrey.semashev@gmail.com> wrote:
>>
>>> On Thu, Jun 14, 2018 at 11:09 PM, Tony V E <tvaneerd@gmail.com> wrote:
>>> > OK, revising, based on latest emails:
>>> >
>>> > On Wed, Jun 13, 2018 at 11:11 PM, Tony V E <tvaneerd@gmail.com> wrote:
>>> >>
>>> >> - construct from a fixed-size span<const std::byte, 16>. This makes
>>> "wrong
>>> >> size" not your problem.
>>> >
>>> > still yes.  Except uint8_t.
>>> > We need to say that the order matches the RFC
>>>
>>> Personally, I'd prefer span<const T, 16> where T is one of std::byte,
>>> unsigned char, signed char or char. std::byte is rather cumbersome to
>>> use, most of the time you get some variant of char from external
>>> sources.
>>>
>>> uint8_t would limit std::uuid to only platforms with 8-bit bytes. This
>>> is probably unnecessary.
>>>
>>> >> - not sure whether the iterator constructor should stay - I suppose
>>> it is
>>> >> useful for non-contiguous cases.  Committee might make it UB if it is
>>> not 16
>>> >> bytes.
>>> >
>>> > Do we even need the end iterator?
>>>
>>> Some implementations might want to use it for debugging purposes.
>>>
>>
>> That reminds me - the end iterator should be a separate type from the
>> begin iterator - ie Iterator begin, Sentinel end, like Ranges.
>> Or, actually, just take a Range, since Ranges are likely in C++20.
>>
>>
>>
>>> >> - remove container-like stuff: size and iterators, typedefs, etc -
>>> just
>>> >> have a to_span() function that returns a span<const std::byte, 16>
>>> >> (it probably never should have had mutable iterators, btw - we don't
>>> want
>>> >> to allow changing single bytes in a uuid)
>>> >>
>>> >> Oh, wait - you were saying that the internal representation might not
>>> be
>>> >> just bytes - is that important?
>>> >
>>> > OK, so keep the container interface.  But only const_iterators.  Not
>>> > mutable.
>>> > Is that a problem for writing into an existing uuid?  Construct a new
>>> one
>>> > and assign?  Let the compiler optimize it.
>>> > Or do we need the mutable iterators?  They seem wrong to me.
>>>
>>> I'd be ok with only const_iterators.
>>>
>>> >> - should be trivially copyable, etc
>>> >
>>> > yes?
>>>
>>> I don't see an immediate use case that requires trivial copyability,
>>> but if it happens to be trivially copyable, why not.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B6Djfqg17%2BCRyX4qxWA0YuEAk6doySZQ6Q-e5MFp5V9zYA%40mail.gmail.com
>>> .
>>>
>>
>>
>>
>> --
>> Be seeing you,
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivzYngSA3G0yLr42Yap-Pn7C9TvdWdQsq0vbwUVZRKdmA%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivzYngSA3G0yLr42Yap-Pn7C9TvdWdQsq0vbwUVZRKdmA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxNbbrEPSycOPJPAiUtxLY6mTtGqjkGhYoT%2B9M5g4ByrA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxNbbrEPSycOPJPAiUtxLY6mTtGqjkGhYoT%2B9M5g4ByrA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

--0000000000003e0d83056fa0d2c9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You seem to have a lot of functions/constructors that need=
 constexpr :)<div><br></div><div>- uuid(std::span) -&gt; std::span is const=
expr enabled, so I don&#39;t see a reason for this not to be constexpr</div=
><div>- uuid(FwdIt, FwdIt) -&gt; this can also be constexpr</div><div>- swa=
ps are now constexpr if possible (P0879), which in your case is okay</div><=
div>- begin and end can also be constexpr, there isn&#39;t a reason not to<=
/div><div>- as_bytes can also be constexpr as std::span is constexpr enable=
d</div><div>- operator=3D=3D, operator!=3D and operator&lt; can also be con=
stexpr</div><div><br></div><div>Is there a reason why there are a member an=
d non member functions for operator=3D=3D and operator&lt;?</div><div><br><=
/div><div>Does it really make sense to provide a free function as_bytes? I =
don&#39;t think we want that, at least I don&#39;t :)</div><div><br></div><=
div>I think it makes sense to use operator&lt;=3D&gt; instead of operator=
=3D=3D and operator!=3D (as an additional benefit, you can then use uuid as=
 a non-type template parameter).</div><div><br></div><div>I&#39;m not an LW=
G person, but I think that everywhere in the standard library using type =
=3D ... is used instead of typedef.</div></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr">On Wed, Jun 27, 2018 at 3:26 PM Marius Bancila &lt;<a h=
ref=3D"mailto:marius.bancila@gmail.com">marius.bancila@gmail.com</a>&gt; wr=
ote:<br></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">Thank you for=
 all the feedback here. I was a bit busy but finally made some time to look=
 into all the recent discussions here and summarize the things that should =
be done in order to move further.<div><br></div><div>Here is a list of chan=
ges I have done based on the feedback:</div><div><ul><li>Removed string con=
structors and replaced with free overloaded function from_string().</li><li=
>Parsing strings to uuid throws exception uuid_error instead of creating a =
nil uuid when the operation fails.</li><li>{} included in the supported for=
mat for parsing, i.e. &quot;{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}&quot;.</=
li><li>Removed state_size.</li><li>Renamed member function nil() to is_nil(=
).</li><li>The default constructor is defaulted.</li><li>Added a conversion=
 construct from std::span&lt;std::byte, 16&gt;.</li><li>Added the free func=
tion as_bytes() to convert the uuid into a view of its underlying bytes.</l=
i><li>Constructing a uuid from a range with a size other than 16 is undefin=
ed behaviour.</li><li>Removed mutable iterators (but preserved the constant=
 iterators).</li><li>Removed typedefs and others container-like parts.</li>=
<li>Defined the correlation between the internal UUID bytes and the string =
representation.</li><li>Added UUID layout and byte order specification from=
 the RFC 4122 document.</li></ul><div>To be honest, I am unsure whether the=
 member function size() should stay or not. As we don&#39;t want to make th=
e uuid a container-like type perhaps this should be removed too.</div></div=
><div><br></div><div>The revised proposal document is available here=C2=A0<=
a href=3D"https://github.com/mariusbancila/stduuid/blob/master/P0959.md" ta=
rget=3D"_blank">https://github.com/mariusbancila/stduuid/blob/master/P0959.=
md</a> for further review.</div><div><br></div><div>Thank you,</div><div>Ma=
rius</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Jun=
 15, 2018 at 3:54 PM Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com" tar=
get=3D"_blank">tvaneerd@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On Thu, Jun 14, 2018 at 4:43 PM, Andrey Semashev <span di=
r=3D"ltr">&lt;<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank=
">andrey.semashev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><span>On Thu, Jun 14, 2018 at 11:09 PM, Tony V E &lt;<a href=3D"ma=
ilto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt; wrote=
:<br>
&gt; OK, revising, based on latest emails:<br>
&gt;<br>
&gt; On Wed, Jun 13, 2018 at 11:11 PM, Tony V E &lt;<a href=3D"mailto:tvane=
erd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
</span><span>&gt;&gt; - construct from a fixed-size span&lt;const std::byte=
, 16&gt;. This makes &quot;wrong<br>
&gt;&gt; size&quot; not your problem.<br>
&gt;<br>
&gt; still yes.=C2=A0 Except uint8_t.<br>
&gt; We need to say that the order matches the RFC<br>
<br>
</span>Personally, I&#39;d prefer span&lt;const T, 16&gt; where T is one of=
 std::byte,<br>
unsigned char, signed char or char. std::byte is rather cumbersome to<br>
use, most of the time you get some variant of char from external<br>
sources.<br>
<br>
uint8_t would limit std::uuid to only platforms with 8-bit bytes. This<br>
is probably unnecessary.<br>
<span><br>
&gt;&gt; - not sure whether the iterator constructor should stay - I suppos=
e it is<br>
&gt;&gt; useful for non-contiguous cases.=C2=A0 Committee might make it UB =
if it is not 16<br>
&gt;&gt; bytes.<br>
&gt;<br>
&gt; Do we even need the end iterator?<br>
<br>
</span>Some implementations might want to use it for debugging purposes.<br=
></blockquote><div><br></div><div>That reminds me - the end iterator should=
 be a separate type from the begin iterator - ie Iterator begin, Sentinel e=
nd, like Ranges.</div><div>Or, actually, just take a Range, since Ranges ar=
e likely in C++20.</div><div><br></div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
<span><br>
&gt;&gt; - remove container-like stuff: size and iterators, typedefs, etc -=
 just<br>
&gt;&gt; have a to_span() function that returns a span&lt;const std::byte, =
16&gt;<br>
&gt;&gt; (it probably never should have had mutable iterators, btw - we don=
&#39;t want<br>
&gt;&gt; to allow changing single bytes in a uuid)<br>
&gt;&gt;<br>
&gt;&gt; Oh, wait - you were saying that the internal representation might =
not be<br>
&gt;&gt; just bytes - is that important?<br>
&gt;<br>
&gt; OK, so keep the container interface.=C2=A0 But only const_iterators.=
=C2=A0 Not<br>
&gt; mutable.<br>
&gt; Is that a problem for writing into an existing uuid?=C2=A0 Construct a=
 new one<br>
&gt; and assign?=C2=A0 Let the compiler optimize it.<br>
&gt; Or do we need the mutable iterators?=C2=A0 They seem wrong to me.<br>
<br>
</span>I&#39;d be ok with only const_iterators.<br>
<span><br>
&gt;&gt; - should be trivially copyable, etc<br>
&gt;<br>
&gt; yes?<br>
<br>
</span>I don&#39;t see an immediate use case that requires trivial copyabil=
ity,<br>
but if it happens to be trivially copyable, why not.<br>
<span><br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B6Djfqg17%2BCRyX4qxWA0Y=
uEAk6doySZQ6Q-e5MFp5V9zYA%40mail.gmail.com" rel=3D"noreferrer" target=3D"_b=
lank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B=
6Djfqg17%2BCRyX4qxWA0YuEAk6doySZQ6Q-e5MFp5V9zYA%40mail.gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"m_-581945=
7999872631488m_-6409816038175448163gmail_signature" data-smartmail=3D"gmail=
_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></d=
iv>
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivzYngSA3G0yLr42Yap-Pn7C9TvdWdQ=
sq0vbwUVZRKdmA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAOHCbivzYngSA3G0yLr42Yap-Pn7C9TvdWdQsq0vbwUVZRKdmA%40mail.gmail.com</=
a>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxNbbrEPSycOPJPAiUtxLY6mTtGqj=
kGhYoT%2B9M5g4ByrA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CA%2BgtASxNbbrEPSycOPJPAiUtxLY6mTtGqjkGhYoT%2B9M5g4ByrA%40mail.gma=
il.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq2KRLURMoSynh5n7VrL6ekNSDdqJ1Aw=
yvoHEimz2m15ew%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq2KRLURMoSy=
nh5n7VrL6ekNSDdqJ1AwyvoHEimz2m15ew%40mail.gmail.com</a>.<br />

--0000000000003e0d83056fa0d2c9--

.

------=_Part_9466_1347045457.1530112431151
Content-Type: multipart/alternative;
 boundary="----=_Part_9467_2131488587.1530112431151"

------=_Part_9467_2131488587.1530112431151
Content-Type: text/plain; charset="UTF-8"

On Wednesday, June 27, 2018 at 10:56:38 AM UTC-4, Nicolas Lesser wrote:
>
> Does it really make sense to provide a free function as_bytes? I don't
> think we want that, at least I don't :)
>

Yes. `std::as_bytes` is a free function from `span` that takes any `span`
and returns a byte array to its sequence. So it makes sense that if a UUID
is considered span-like, then it should be convertible with a similar
interface.

Now granted, I'm not sure it's a good idea, but that's more due to lifetime
issues.

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

------=_Part_9467_2131488587.1530112431151
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, June 27, 2018 at 10:56:38 AM UTC-4, Nicolas =
Lesser wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>Does it really make sense to provide a free function as_bytes? I don&#=
39;t think we want that, at least I don&#39;t :)</div></div></blockquote><d=
iv><br></div><div>Yes. `std::as_bytes` is a free function from `span` that =
takes any `span` and returns a byte array to its sequence. So it makes sens=
e that if a UUID is considered span-like, then it should be convertible wit=
h a similar interface.</div><div><br></div><div>Now granted, I&#39;m not su=
re it&#39;s a good idea, but that&#39;s more due to lifetime issues.</div><=
div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/83b7b53d-957a-4de8-a840-88b8f8c3831f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/83b7b53d-957a-4de8-a840-88b8f8c3831f=
%40isocpp.org</a>.<br />

------=_Part_9467_2131488587.1530112431151--

------=_Part_9466_1347045457.1530112431151--

.

--0000000000008a2950056fa13cbe
Content-Type: text/plain; charset="UTF-8"

On Wed, Jun 27, 2018 at 5:13 PM Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, June 27, 2018 at 10:56:38 AM UTC-4, Nicolas Lesser wrote:
>>
>> Does it really make sense to provide a free function as_bytes? I don't
>> think we want that, at least I don't :)
>>
>
> Yes. `std::as_bytes` is a free function from `span` that takes any `span`
> and returns a byte array to its sequence. So it makes sense that if a UUID
> is considered span-like, then it should be convertible with a similar
> interface.
>
> Didn't know about this :) Thanks for mentioning it.


> Now granted, I'm not sure it's a good idea, but that's more due to
> lifetime issues.
>

I agree.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1NC4Z8%2BqdYw54zo_DOS%3D%3DwKOFmMfj9NVm%3DgjHEVu5LXQ%40mail.gmail.com.

--0000000000008a2950056fa13cbe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Jun 27=
, 2018 at 5:13 PM Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com">jm=
ckesson@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">On Wednesday, June 27, 2018 at 10:56:38 AM UTC-4, Nicolas Le=
sser wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Do=
es it really make sense to provide a free function as_bytes? I don&#39;t th=
ink we want that, at least I don&#39;t :)</div></div></blockquote><div><br>=
</div><div>Yes. `std::as_bytes` is a free function from `span` that takes a=
ny `span` and returns a byte array to its sequence. So it makes sense that =
if a UUID is considered span-like, then it should be convertible with a sim=
ilar interface.</div><div><br></div></div></blockquote><div>Didn&#39;t know=
 about this :) Thanks for mentioning it.</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></div><div>Now granted, I&#39;m no=
t sure it&#39;s a good idea, but that&#39;s more due to lifetime issues.</d=
iv></div></blockquote><div><br></div><div>I agree.</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq1NC4Z8%2BqdYw54zo_DOS%3D%3DwKO=
FmMfj9NVm%3DgjHEVu5LXQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1N=
C4Z8%2BqdYw54zo_DOS%3D%3DwKOFmMfj9NVm%3DgjHEVu5LXQ%40mail.gmail.com</a>.<br=
 />

--0000000000008a2950056fa13cbe--

.

--0000000000002a4bbb056fa2e7a3
Content-Type: text/plain; charset="UTF-8"

I'm not a big fan of std::as_bytes.

Particularly the non-const version.  Basically asking for UB.

I've been considering writing a paper...

On Wed, Jun 27, 2018 at 11:24 AM, Nicolas Lesser <blitzrakete@gmail.com>
wrote:

> On Wed, Jun 27, 2018 at 5:13 PM Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Wednesday, June 27, 2018 at 10:56:38 AM UTC-4, Nicolas Lesser wrote:
>>>
>>> Does it really make sense to provide a free function as_bytes? I don't
>>> think we want that, at least I don't :)
>>>
>>
>> Yes. `std::as_bytes` is a free function from `span` that takes any `span`
>> and returns a byte array to its sequence. So it makes sense that if a UUID
>> is considered span-like, then it should be convertible with a similar
>> interface.
>>
>> Didn't know about this :) Thanks for mentioning it.
>
>
>> Now granted, I'm not sure it's a good idea, but that's more due to
>> lifetime issues.
>>
>
> I agree.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CALmDwq1NC4Z8%2BqdYw54zo_DOS%3D%
> 3DwKOFmMfj9NVm%3DgjHEVu5LXQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1NC4Z8%2BqdYw54zo_DOS%3D%3DwKOFmMfj9NVm%3DgjHEVu5LXQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>



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

--0000000000002a4bbb056fa2e7a3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I&#39;m not a big fan of std::as_bytes.</div><div><br=
></div><div>Particularly the non-const version.=C2=A0 Basically asking for =
UB.</div><div><br></div><div>I&#39;ve been considering writing a paper...<b=
r></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Wed, Jun 27, 2018 at 11:24 AM, Nicolas Lesser <span dir=3D"ltr">&lt;<a href=
=3D"mailto:blitzrakete@gmail.com" target=3D"_blank">blitzrakete@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v class=3D"gmail_quote"><span class=3D""><div dir=3D"ltr">On Wed, Jun 27, 2=
018 at 5:13 PM Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com" targe=
t=3D"_blank">jmckesson@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">On Wednesday, June 27, 2018 at 10:56:38 AM U=
TC-4, Nicolas Lesser wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>Does it really make sense to provide a free function as_bytes=
? I don&#39;t think we want that, at least I don&#39;t :)</div></div></bloc=
kquote><div><br></div><div>Yes. `std::as_bytes` is a free function from `sp=
an` that takes any `span` and returns a byte array to its sequence. So it m=
akes sense that if a UUID is considered span-like, then it should be conver=
tible with a similar interface.</div><div><br></div></div></blockquote></sp=
an><div>Didn&#39;t know about this :) Thanks for mentioning it.</div><span =
class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div></div><div>Now granted, I&#39;m not sure it&#39;s a good idea, but th=
at&#39;s more due to lifetime issues.</div></div></blockquote><div><br></di=
v></span><div>I agree.</div></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq1NC4Z8%2BqdYw54zo_DOS%3D%3DwKO=
FmMfj9NVm%3DgjHEVu5LXQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/=
msgid/std-<wbr>proposals/CALmDwq1NC4Z8%<wbr>2BqdYw54zo_DOS%3D%<wbr>3DwKOFmM=
fj9NVm%3DgjHEVu5LXQ%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuh5Qez8FV2JJu9gsKOu_eXr1DERHXG=
TbUbj06hupsTYA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuh5Qez8FV2=
JJu9gsKOu_eXr1DERHXGTbUbj06hupsTYA%40mail.gmail.com</a>.<br />

--0000000000002a4bbb056fa2e7a3--

.

--000000000000600386056fa32a46
Content-Type: text/plain; charset="UTF-8"

On Wed, Jun 27, 2018 at 9:25 AM, Marius Bancila <marius.bancila@gmail.com>
wrote:

> Thank you for all the feedback here. I was a bit busy but finally made
> some time to look into all the recent discussions here and summarize the
> things that should be done in order to move further.
>
> Here is a list of changes I have done based on the feedback:
>
>    - Removed string constructors and replaced with free overloaded
>    function from_string().
>
>
from_string needs to be a static function inside of uuid. ie

    uuid id = uuid::from_string("00....");

We can't take the name "from_string" for all of std and use it only for
uuid.  If anything, some day there may be a templatized from_string

    int x = from_string<int>("00...");
    uuid id = from_string<uuid>("00....");

But uuid::from_string is easier, as it doesn't open up a big discussion
about a generalized from_string<>



>
>    - Parsing strings to uuid throws exception uuid_error instead of
>    creating a nil uuid when the operation fails.
>    - {} included in the supported format for parsing, i.e.
>    "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}".
>    - Removed state_size.
>    - Renamed member function nil() to is_nil().
>    - The default constructor is defaulted.
>    - Added a conversion construct from std::span<std::byte, 16>.
>    - Added the free function as_bytes() to convert the uuid into a view
>    of its underlying bytes.
>
>
why allow the non-const access version of as_bytes?


>    - Constructing a uuid from a range with a size other than 16 is
>    undefined behaviour.
>    - Removed mutable iterators (but preserved the constant iterators).
>    - Removed typedefs and others container-like parts.
>
>
>    - Defined the correlation between the internal UUID bytes and the
>    string representation.
>
>
Is this the same as RFC 4122?


>    - Added UUID layout and byte order specification from the RFC 4122
>    document.
>
> To be honest, I am unsure whether the member function size() should stay
> or not. As we don't want to make the uuid a container-like type perhaps
> this should be removed too.
>


We need to decide to have either as_bytes, or a container-like interface,
not both.

We go with container-like if we think that implementations will use a
non-byte representation (ie SIMD, etc) internally.
Exposing as_bytes forces a byte order representation.  Fine, but then
container-like is unnecessary.

Maybe you should include a discussion of this in the paper, along with
pros/cons of non-byte-order representations.



>
> The revised proposal document is available here https://github.com/
> mariusbancila/stduuid/blob/master/P0959.md for further review.
>
> Thank you,
> Marius
>
> On Fri, Jun 15, 2018 at 3:54 PM Tony V E <tvaneerd@gmail.com> wrote:
>
>>
>>
>> On Thu, Jun 14, 2018 at 4:43 PM, Andrey Semashev <
>> andrey.semashev@gmail.com> wrote:
>>
>>> On Thu, Jun 14, 2018 at 11:09 PM, Tony V E <tvaneerd@gmail.com> wrote:
>>> > OK, revising, based on latest emails:
>>> >
>>> > On Wed, Jun 13, 2018 at 11:11 PM, Tony V E <tvaneerd@gmail.com> wrote:
>>> >>
>>> >> - construct from a fixed-size span<const std::byte, 16>. This makes
>>> "wrong
>>> >> size" not your problem.
>>> >
>>> > still yes.  Except uint8_t.
>>> > We need to say that the order matches the RFC
>>>
>>> Personally, I'd prefer span<const T, 16> where T is one of std::byte,
>>> unsigned char, signed char or char. std::byte is rather cumbersome to
>>> use, most of the time you get some variant of char from external
>>> sources.
>>>
>>> uint8_t would limit std::uuid to only platforms with 8-bit bytes. This
>>> is probably unnecessary.
>>>
>>> >> - not sure whether the iterator constructor should stay - I suppose
>>> it is
>>> >> useful for non-contiguous cases.  Committee might make it UB if it is
>>> not 16
>>> >> bytes.
>>> >
>>> > Do we even need the end iterator?
>>>
>>> Some implementations might want to use it for debugging purposes.
>>>
>>
>> That reminds me - the end iterator should be a separate type from the
>> begin iterator - ie Iterator begin, Sentinel end, like Ranges.
>> Or, actually, just take a Range, since Ranges are likely in C++20.
>>
>>
>>
>>> >> - remove container-like stuff: size and iterators, typedefs, etc -
>>> just
>>> >> have a to_span() function that returns a span<const std::byte, 16>
>>> >> (it probably never should have had mutable iterators, btw - we don't
>>> want
>>> >> to allow changing single bytes in a uuid)
>>> >>
>>> >> Oh, wait - you were saying that the internal representation might not
>>> be
>>> >> just bytes - is that important?
>>> >
>>> > OK, so keep the container interface.  But only const_iterators.  Not
>>> > mutable.
>>> > Is that a problem for writing into an existing uuid?  Construct a new
>>> one
>>> > and assign?  Let the compiler optimize it.
>>> > Or do we need the mutable iterators?  They seem wrong to me.
>>>
>>> I'd be ok with only const_iterators.
>>>
>>> >> - should be trivially copyable, etc
>>> >
>>> > yes?
>>>
>>> I don't see an immediate use case that requires trivial copyability,
>>> but if it happens to be trivially copyable, why not.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/
>>> isocpp.org/d/msgid/std-proposals/CAEhD%2B6Djfqg17%
>>> 2BCRyX4qxWA0YuEAk6doySZQ6Q-e5MFp5V9zYA%40mail.gmail.com.
>>>
>>
>>
>>
>> --
>> Be seeing you,
>> 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.
>> To view this discussion on the web visit https://groups.google.com/a/
>> isocpp.org/d/msgid/std-proposals/CAOHCbivzYngSA3G0yLr42Yap-
>> Pn7C9TvdWdQsq0vbwUVZRKdmA%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivzYngSA3G0yLr42Yap-Pn7C9TvdWdQsq0vbwUVZRKdmA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CA%2BgtASxNbbrEPSycOPJPAiUtxLY6mT
> tGqjkGhYoT%2B9M5g4ByrA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxNbbrEPSycOPJPAiUtxLY6mTtGqjkGhYoT%2B9M5g4ByrA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>



--
Be seeing you,
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuO%3D6vMbwCnaDUD%3DdZ1bc0-Xf5qqyzJhfisqpubW-2gaA%40mail.gmail.com.

--000000000000600386056fa32a46
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 Wed, Jun 27, 2018 at 9:25 AM, Marius Bancila <span dir=3D"ltr">&lt;<=
a href=3D"mailto:marius.bancila@gmail.com" target=3D"_blank">marius.bancila=
@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">Thank you for all the feedback here. I was a bit busy but finally =
made some time to look into all the recent discussions here and summarize t=
he things that should be done in order to move further.<div><br></div><div>=
Here is a list of changes I have done based on the feedback:</div><div><ul>=
<li>Removed string constructors and replaced with free overloaded function =
from_string().</li></ul></div></div></blockquote><div><br></div><div>from_s=
tring needs to be a static function inside of uuid. ie</div><div><br></div>=
<div>=C2=A0=C2=A0=C2=A0 uuid id =3D uuid::from_string(&quot;00....&quot;);<=
/div><div><br></div><div>We can&#39;t take the name &quot;from_string&quot;=
 for all of std and use it only for uuid.=C2=A0 If anything, some day there=
 may be a templatized from_string</div><div><br></div><div>=C2=A0=C2=A0=C2=
=A0 int x =3D from_string&lt;int&gt;(&quot;00...&quot;);</div><div>=C2=A0=
=C2=A0=C2=A0 uuid id =3D from_string&lt;uuid&gt;(&quot;00....&quot;);</div>=
<div><br></div><div>But uuid::from_string is easier, as it doesn&#39;t open=
 up a big discussion about a generalized from_string&lt;&gt;</div><div><br>=
</div><div></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><ul><li>Parsing strings to uuid throws exception uuid_error i=
nstead of creating a nil uuid when the operation fails.</li><li>{} included=
 in the supported format for parsing, i.e. &quot;{xxxxxxxx-xxxx-xxxx-xxxx-<=
wbr>xxxxxxxxxxxx}&quot;.</li><li>Removed state_size.</li><li>Renamed member=
 function nil() to is_nil().</li><li>The default constructor is defaulted.<=
/li><li>Added a conversion construct from std::span&lt;std::byte, 16&gt;.</=
li><li>Added the free function as_bytes() to convert the uuid into a view o=
f its underlying bytes.</li></ul></div></div></blockquote><div><br></div><d=
iv>why allow the non-const access version of as_bytes?</div><div> <br></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"><div><ul><li>Constructing =
a uuid from a range with a size other than 16 is undefined behaviour.</li><=
li>Removed mutable iterators (but preserved the constant iterators).</li><l=
i>Removed typedefs and others container-like parts.</li></ul></div></div></=
blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><ul><li>Def=
ined the correlation between the internal UUID bytes and the string represe=
ntation.</li></ul></div></div></blockquote><div><br></div><div>Is this the =
same as RFC 4122? <br></div><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div><ul><li>Added UUID layout and byte order specification=
 from the RFC 4122 document.</li></ul><div>To be honest, I am unsure whethe=
r the member function size() should stay or not. As we don&#39;t want to ma=
ke the uuid a container-like type perhaps this should be removed too.</div>=
</div></div></blockquote><div><br></div><div><br></div><div>We need to deci=
de to have either as_bytes, or a container-like interface, not both.</div><=
div><br></div><div>We go with container-like if we think that implementatio=
ns will use a non-byte representation (ie SIMD, etc) internally.</div><div>=
Exposing as_bytes forces a byte order representation.=C2=A0 Fine, but then =
container-like is unnecessary.</div><div><br></div><div>Maybe you should in=
clude a discussion of this in the paper, along with pros/cons of non-byte-o=
rder representations.</div><div><br></div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><br></div><div>The revised proposal do=
cument is available here=C2=A0<a href=3D"https://github.com/mariusbancila/s=
tduuid/blob/master/P0959.md" target=3D"_blank">https://github.com/<wbr>mari=
usbancila/stduuid/blob/<wbr>master/P0959.md</a> for further review.</div><d=
iv><br></div><div>Thank you,</div><div>Marius</div></div><br><div class=3D"=
gmail_quote"><div><div class=3D"h5"><div dir=3D"ltr">On Fri, Jun 15, 2018 a=
t 3:54 PM Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_bla=
nk">tvaneerd@gmail.com</a>&gt; wrote:<br></div></div></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr"><br><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Thu, Jun 14, 2018 at 4:43 PM, =
Andrey Semashev <span dir=3D"ltr">&lt;<a href=3D"mailto:andrey.semashev@gma=
il.com" target=3D"_blank">andrey.semashev@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><span>On Thu, Jun 14, 2018 at 11:09 PM, To=
ny V E &lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd=
@gmail.com</a>&gt; wrote:<br>
&gt; OK, revising, based on latest emails:<br>
&gt;<br>
&gt; On Wed, Jun 13, 2018 at 11:11 PM, Tony V E &lt;<a href=3D"mailto:tvane=
erd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
</span><span>&gt;&gt; - construct from a fixed-size span&lt;const std::byte=
, 16&gt;. This makes &quot;wrong<br>
&gt;&gt; size&quot; not your problem.<br>
&gt;<br>
&gt; still yes.=C2=A0 Except uint8_t.<br>
&gt; We need to say that the order matches the RFC<br>
<br>
</span>Personally, I&#39;d prefer span&lt;const T, 16&gt; where T is one of=
 std::byte,<br>
unsigned char, signed char or char. std::byte is rather cumbersome to<br>
use, most of the time you get some variant of char from external<br>
sources.<br>
<br>
uint8_t would limit std::uuid to only platforms with 8-bit bytes. This<br>
is probably unnecessary.<br>
<span><br>
&gt;&gt; - not sure whether the iterator constructor should stay - I suppos=
e it is<br>
&gt;&gt; useful for non-contiguous cases.=C2=A0 Committee might make it UB =
if it is not 16<br>
&gt;&gt; bytes.<br>
&gt;<br>
&gt; Do we even need the end iterator?<br>
<br>
</span>Some implementations might want to use it for debugging purposes.<br=
></blockquote><div><br></div><div>That reminds me - the end iterator should=
 be a separate type from the begin iterator - ie Iterator begin, Sentinel e=
nd, like Ranges.</div><div>Or, actually, just take a Range, since Ranges ar=
e likely in C++20.</div><div><br></div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
<span><br>
&gt;&gt; - remove container-like stuff: size and iterators, typedefs, etc -=
 just<br>
&gt;&gt; have a to_span() function that returns a span&lt;const std::byte, =
16&gt;<br>
&gt;&gt; (it probably never should have had mutable iterators, btw - we don=
&#39;t want<br>
&gt;&gt; to allow changing single bytes in a uuid)<br>
&gt;&gt;<br>
&gt;&gt; Oh, wait - you were saying that the internal representation might =
not be<br>
&gt;&gt; just bytes - is that important?<br>
&gt;<br>
&gt; OK, so keep the container interface.=C2=A0 But only const_iterators.=
=C2=A0 Not<br>
&gt; mutable.<br>
&gt; Is that a problem for writing into an existing uuid?=C2=A0 Construct a=
 new one<br>
&gt; and assign?=C2=A0 Let the compiler optimize it.<br>
&gt; Or do we need the mutable iterators?=C2=A0 They seem wrong to me.<br>
<br>
</span>I&#39;d be ok with only const_iterators.<br>
<span><br>
&gt;&gt; - should be trivially copyable, etc<br>
&gt;<br>
&gt; yes?<br>
<br>
</span>I don&#39;t see an immediate use case that requires trivial copyabil=
ity,<br>
but if it happens to be trivially copyable, why not.<br>
<span><br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B6Djfqg17%2BCRyX4qxWA0Y=
uEAk6doySZQ6Q-e5MFp5V9zYA%40mail.gmail.com" rel=3D"noreferrer" target=3D"_b=
lank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposal=
s/CAEhD%2B6Djfqg17%<wbr>2BCRyX4qxWA0YuEAk6doySZQ6Q-<wbr>e5MFp5V9zYA%40mail.=
gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"m_2906600=
713733491105m_-6409816038175448163gmail_signature" data-smartmail=3D"gmail_=
signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></di=
v>
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivzYngSA3G0yLr42Yap-Pn7C9TvdWdQ=
sq0vbwUVZRKdmA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CAOHCbivzYngSA3G0yLr42Yap-<wbr>Pn7C9TvdWdQsq0vbwUVZRKdm=
A%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxNbbrEPSycOPJPAiUtxLY6mTtGqj=
kGhYoT%2B9M5g4ByrA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CA%<wbr>2BgtASxNbbrEPSycOPJPAiUtxLY6mT<wbr>tGqjkGhYoT%2B=
9M5g4ByrA%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuO%3D6vMbwCnaDUD%3DdZ1bc0-Xf5q=
qyzJhfisqpubW-2gaA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuO%3D6=
vMbwCnaDUD%3DdZ1bc0-Xf5qqyzJhfisqpubW-2gaA%40mail.gmail.com</a>.<br />

--000000000000600386056fa32a46--

.

--0000000000006602b0056fc2dc3b
Content-Type: text/plain; charset="UTF-8"

>
> You seem to have a lot of functions/constructors that need constexpr :)
> - uuid(std::span) -> std::span is constexpr enabled, so I don't see a
> reason for this not to be constexpr
> - uuid(FwdIt, FwdIt) -> this can also be constexpr
> - swaps are now constexpr if possible (P0879), which in your case is okay
> - begin and end can also be constexpr, there isn't a reason not to
> - as_bytes can also be constexpr as std::span is constexpr enabled
> - operator==, operator!= and operator< can also be constexpr


Right, that's correct. The idea was that I worked on the paper and
implemented the library altogether. Some of these functions use copy or
swap which are indeed constexpr in C++20, but no compiler supports that
yet. But sure, they should be specified as constexpr and I did so now in
the paper.

Is there a reason why there are a member and non member functions for
> operator== and operator<?


They are all non-member.

Does it really make sense to provide a free function as_bytes? I don't
> think we want that, at least I don't :)


It was a mistake I did. I first put it a free function and I updated the
parer and then while doing other changes I realized it should be a member
function and did so but forgot to properly update the proposal. But I fixed
that now.

I think it makes sense to use operator<=> instead of operator== and
> operator!= (as an additional benefit, you can then use uuid as a non-type
> template parameter).


My initial idea was to only be able to compare uuid for equality. operator
< is necessary to be able to use uuids with associative containers. It does
not really make sense to compare whether a uuid is less than another for
any other reasons. Should we want to have all these comparison operators,
then yes, it makes more sense to use the <=> operator.

constexpr auto operator <=>(uuid const & lhs, uuid const & rhs) noexcept;

I'm not an LWG person, but I think that everywhere in the standard library
> using type = ... is used instead of typedef.


You're probably right on that. I replaced the typedefs with using
statements.

from_string needs to be a static function inside of uuid. ie
>     uuid id = uuid::from_string("00....");
> We can't take the name "from_string" for all of std and use it only for
> uuid.  If anything, some day there may be a templatized from_string
>     int x = from_string<int>("00...");
>     uuid id = from_string<uuid>("00....");
> But uuid::from_string is easier, as it doesn't open up a big discussion
> about a generalized from_string<>


Yes, you are definitely right about that. That was kinda stupid from me to
do.

why allow the non-const access version of as_bytes?


Indeed, that doesn't make too much sense either, so I removed it and only
kept the const version.

Is this the same as RFC 4122?


Yes, RFC 4122 specifies that (and I put that in the proposal too) "*The
fields are encoded as 16 octets, with the sizes and order of the fields
defined above, and with each field encoded with the Most Significant Byte
first (known as network byte order).*"

Marius

On Wed, Jun 27, 2018 at 8:44 PM Tony V E <tvaneerd@gmail.com> wrote:

>
>
> On Wed, Jun 27, 2018 at 9:25 AM, Marius Bancila <marius.bancila@gmail.com>
> wrote:
>
>> Thank you for all the feedback here. I was a bit busy but finally made
>> some time to look into all the recent discussions here and summarize the
>> things that should be done in order to move further.
>>
>> Here is a list of changes I have done based on the feedback:
>>
>>    - Removed string constructors and replaced with free overloaded
>>    function from_string().
>>
>>
> from_string needs to be a static function inside of uuid. ie
>
>     uuid id = uuid::from_string("00....");
>
> We can't take the name "from_string" for all of std and use it only for
> uuid.  If anything, some day there may be a templatized from_string
>
>     int x = from_string<int>("00...");
>     uuid id = from_string<uuid>("00....");
>
> But uuid::from_string is easier, as it doesn't open up a big discussion
> about a generalized from_string<>
>
>
>
>>
>>    - Parsing strings to uuid throws exception uuid_error instead of
>>    creating a nil uuid when the operation fails.
>>    - {} included in the supported format for parsing, i.e.
>>    "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}".
>>    - Removed state_size.
>>    - Renamed member function nil() to is_nil().
>>    - The default constructor is defaulted.
>>    - Added a conversion construct from std::span<std::byte, 16>.
>>    - Added the free function as_bytes() to convert the uuid into a view
>>    of its underlying bytes.
>>
>>
> why allow the non-const access version of as_bytes?
>
>
>>    - Constructing a uuid from a range with a size other than 16 is
>>    undefined behaviour.
>>    - Removed mutable iterators (but preserved the constant iterators).
>>    - Removed typedefs and others container-like parts.
>>
>>
>>    - Defined the correlation between the internal UUID bytes and the
>>    string representation.
>>
>>
> Is this the same as RFC 4122?
>
>
>>    - Added UUID layout and byte order specification from the RFC 4122
>>    document.
>>
>> To be honest, I am unsure whether the member function size() should stay
>> or not. As we don't want to make the uuid a container-like type perhaps
>> this should be removed too.
>>
>
>
> We need to decide to have either as_bytes, or a container-like interface,
> not both.
>
> We go with container-like if we think that implementations will use a
> non-byte representation (ie SIMD, etc) internally.
> Exposing as_bytes forces a byte order representation.  Fine, but then
> container-like is unnecessary.
>
> Maybe you should include a discussion of this in the paper, along with
> pros/cons of non-byte-order representations.
>
>
>
>>
>> The revised proposal document is available here
>> https://github.com/mariusbancila/stduuid/blob/master/P0959.md for
>> further review.
>>
>> Thank you,
>> Marius
>>
>> On Fri, Jun 15, 2018 at 3:54 PM Tony V E <tvaneerd@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Jun 14, 2018 at 4:43 PM, Andrey Semashev <
>>> andrey.semashev@gmail.com> wrote:
>>>
>>>> On Thu, Jun 14, 2018 at 11:09 PM, Tony V E <tvaneerd@gmail.com> wrote:
>>>> > OK, revising, based on latest emails:
>>>> >
>>>> > On Wed, Jun 13, 2018 at 11:11 PM, Tony V E <tvaneerd@gmail.com>
>>>> wrote:
>>>> >>
>>>> >> - construct from a fixed-size span<const std::byte, 16>. This makes
>>>> "wrong
>>>> >> size" not your problem.
>>>> >
>>>> > still yes.  Except uint8_t.
>>>> > We need to say that the order matches the RFC
>>>>
>>>> Personally, I'd prefer span<const T, 16> where T is one of std::byte,
>>>> unsigned char, signed char or char. std::byte is rather cumbersome to
>>>> use, most of the time you get some variant of char from external
>>>> sources.
>>>>
>>>> uint8_t would limit std::uuid to only platforms with 8-bit bytes. This
>>>> is probably unnecessary.
>>>>
>>>> >> - not sure whether the iterator constructor should stay - I suppose
>>>> it is
>>>> >> useful for non-contiguous cases.  Committee might make it UB if it
>>>> is not 16
>>>> >> bytes.
>>>> >
>>>> > Do we even need the end iterator?
>>>>
>>>> Some implementations might want to use it for debugging purposes.
>>>>
>>>
>>> That reminds me - the end iterator should be a separate type from the
>>> begin iterator - ie Iterator begin, Sentinel end, like Ranges.
>>> Or, actually, just take a Range, since Ranges are likely in C++20.
>>>
>>>
>>>
>>>> >> - remove container-like stuff: size and iterators, typedefs, etc -
>>>> just
>>>> >> have a to_span() function that returns a span<const std::byte, 16>
>>>> >> (it probably never should have had mutable iterators, btw - we don't
>>>> want
>>>> >> to allow changing single bytes in a uuid)
>>>> >>
>>>> >> Oh, wait - you were saying that the internal representation might
>>>> not be
>>>> >> just bytes - is that important?
>>>> >
>>>> > OK, so keep the container interface.  But only const_iterators.  Not
>>>> > mutable.
>>>> > Is that a problem for writing into an existing uuid?  Construct a new
>>>> one
>>>> > and assign?  Let the compiler optimize it.
>>>> > Or do we need the mutable iterators?  They seem wrong to me.
>>>>
>>>> I'd be ok with only const_iterators.
>>>>
>>>> >> - should be trivially copyable, etc
>>>> >
>>>> > yes?
>>>>
>>>> I don't see an immediate use case that requires trivial copyability,
>>>> but if it happens to be trivially copyable, why not.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to std-proposals+unsubscribe@isocpp.org.
>>>> To post to this group, send email to std-proposals@isocpp.org.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B6Djfqg17%2BCRyX4qxWA0YuEAk6doySZQ6Q-e5MFp5V9zYA%40mail.gmail.com
>>>> .
>>>>
>>>
>>>
>>>
>>> --
>>> Be seeing you,
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivzYngSA3G0yLr42Yap-Pn7C9TvdWdQsq0vbwUVZRKdmA%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivzYngSA3G0yLr42Yap-Pn7C9TvdWdQsq0vbwUVZRKdmA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxNbbrEPSycOPJPAiUtxLY6mTtGqjkGhYoT%2B9M5g4ByrA%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxNbbrEPSycOPJPAiUtxLY6mTtGqjkGhYoT%2B9M5g4ByrA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
>
> --
> Be seeing you,
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuO%3D6vMbwCnaDUD%3DdZ1bc0-Xf5qqyzJhfisqpubW-2gaA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuO%3D6vMbwCnaDUD%3DdZ1bc0-Xf5qqyzJhfisqpubW-2gaA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

--0000000000006602b0056fc2dc3b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You seem=
 to have a lot of functions/constructors that need constexpr :)<br>- uuid(s=
td::span) -&gt; std::span is constexpr enabled, so I don&#39;t see a reason=
 for this not to be constexpr<br>- uuid(FwdIt, FwdIt) -&gt; this can also b=
e constexpr<br>- swaps are now constexpr if possible (P0879), which in your=
 case is okay<br>- begin and end can also be constexpr, there isn&#39;t a r=
eason not to<br>- as_bytes can also be constexpr as std::span is constexpr =
enabled<br>- operator=3D=3D, operator!=3D and operator&lt; can also be cons=
texpr</blockquote><div><br></div><div>Right, that&#39;s correct. The idea w=
as that I worked on the paper and implemented the library altogether. Some =
of these functions use copy or swap which are indeed constexpr in C++20, bu=
t no compiler supports that yet. But sure, they should be specified as cons=
texpr and I did so now in the paper.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Is there a reason why there are a member a=
nd non member functions for operator=3D=3D and operator&lt;?</blockquote><d=
iv><br></div><div>They are all non-member.</div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">Does it really make sense to provide =
a free function as_bytes? I don&#39;t think we want that, at least I don&#3=
9;t :)</blockquote><div><br></div><div>It was a mistake I did. I first put =
it a free function and I updated the parer and then while doing other chang=
es I realized it should be a member function and did so but forgot to prope=
rly update the proposal. But I fixed that now.</div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">I think it makes sense to use ope=
rator&lt;=3D&gt; instead of operator=3D=3D and operator!=3D (as an addition=
al benefit, you can then use uuid as a non-type template parameter).</block=
quote><div><br></div><div>My initial idea was to only be able to compare uu=
id for equality. operator &lt; is necessary to be able to use uuids with as=
sociative containers. It does not really make sense to compare whether a uu=
id is less than another for any other reasons. Should we want to have all t=
hese comparison operators, then yes, it makes more sense to use the &lt;=3D=
&gt; operator.</div><div><br></div><div>constexpr auto operator &lt;=3D&gt;=
(uuid const &amp; lhs, uuid const &amp; rhs) noexcept;<br></div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">I&#39;m not an LWG pe=
rson, but I think that everywhere in the standard library using type =3D ..=
.. is used instead of typedef.</blockquote><div><br></div><div>You&#39;re pr=
obably right on that. I replaced the typedefs with using statements.</div><=
div><br></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">from_s=
tring needs to be a static function inside of uuid. ie<br>=C2=A0 =C2=A0 uui=
d id =3D uuid::from_string(&quot;00....&quot;);<br>We can&#39;t take the na=
me &quot;from_string&quot; for all of std and use it only for uuid.=C2=A0 I=
f anything, some day there may be a templatized from_string<br>=C2=A0 =C2=
=A0 int x =3D from_string&lt;int&gt;(&quot;00...&quot;);<br>=C2=A0 =C2=A0 u=
uid id =3D from_string&lt;uuid&gt;(&quot;00....&quot;);<br>But uuid::from_s=
tring is easier, as it doesn&#39;t open up a big discussion about a general=
ized from_string&lt;&gt;</blockquote></div><div><br></div><div>Yes, you are=
 definitely right about that. That was kinda stupid from me to do.</div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">why allow the=
 non-const access version of as_bytes?</blockquote><div><br></div><div>Inde=
ed, that doesn&#39;t make too much sense either, so I removed it and only k=
ept the const version.</div><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">Is this the same as RFC 4122?=C2=A0</blockquote><div><br>=
</div><div>Yes, RFC 4122 specifies that (and I put that in the proposal too=
) &quot;<i>The fields are encoded as 16 octets, with the sizes and order of=
 the fields defined above, and with each field encoded with the Most Signif=
icant Byte first (known as network byte order).</i>&quot;</div><div><br></d=
iv><div>Marius</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">O=
n Wed, Jun 27, 2018 at 8:44 PM Tony V E &lt;<a href=3D"mailto:tvaneerd@gmai=
l.com">tvaneerd@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Wed, Jun 27, 2018 at 9:25 AM, Marius Bancila <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:marius.bancila@gmail.com" target=3D"_blank">marius.b=
ancila@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">Thank you for all the feedback here. I was a bit busy but fi=
nally made some time to look into all the recent discussions here and summa=
rize the things that should be done in order to move further.<div><br></div=
><div>Here is a list of changes I have done based on the feedback:</div><di=
v><ul><li>Removed string constructors and replaced with free overloaded fun=
ction from_string().</li></ul></div></div></blockquote><div><br></div><div>=
from_string needs to be a static function inside of uuid. ie</div><div><br>=
</div><div>=C2=A0=C2=A0=C2=A0 uuid id =3D uuid::from_string(&quot;00....&qu=
ot;);</div><div><br></div><div>We can&#39;t take the name &quot;from_string=
&quot; for all of std and use it only for uuid.=C2=A0 If anything, some day=
 there may be a templatized from_string</div><div><br></div><div>=C2=A0=C2=
=A0=C2=A0 int x =3D from_string&lt;int&gt;(&quot;00...&quot;);</div><div>=
=C2=A0=C2=A0=C2=A0 uuid id =3D from_string&lt;uuid&gt;(&quot;00....&quot;);=
</div><div><br></div><div>But uuid::from_string is easier, as it doesn&#39;=
t open up a big discussion about a generalized from_string&lt;&gt;</div><di=
v><br></div><div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div><ul><li>Parsing strings to uuid throws exception uuid_err=
or instead of creating a nil uuid when the operation fails.</li><li>{} incl=
uded in the supported format for parsing, i.e. &quot;{xxxxxxxx-xxxx-xxxx-xx=
xx-xxxxxxxxxxxx}&quot;.</li><li>Removed state_size.</li><li>Renamed member =
function nil() to is_nil().</li><li>The default constructor is defaulted.</=
li><li>Added a conversion construct from std::span&lt;std::byte, 16&gt;.</l=
i><li>Added the free function as_bytes() to convert the uuid into a view of=
 its underlying bytes.</li></ul></div></div></blockquote><div><br></div><di=
v>why allow the non-const access version of as_bytes?</div><div> <br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><ul><li>Constructing a=
 uuid from a range with a size other than 16 is undefined behaviour.</li><l=
i>Removed mutable iterators (but preserved the constant iterators).</li><li=
>Removed typedefs and others container-like parts.</li></ul></div></div></b=
lockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><ul><li>Defi=
ned the correlation between the internal UUID bytes and the string represen=
tation.</li></ul></div></div></blockquote><div><br></div><div>Is this the s=
ame as RFC 4122? <br></div><div><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><ul><li>Added UUID layout and byte order specification =
from the RFC 4122 document.</li></ul><div>To be honest, I am unsure whether=
 the member function size() should stay or not. As we don&#39;t want to mak=
e the uuid a container-like type perhaps this should be removed too.</div><=
/div></div></blockquote><div><br></div><div><br></div><div>We need to decid=
e to have either as_bytes, or a container-like interface, not both.</div><d=
iv><br></div><div>We go with container-like if we think that implementation=
s will use a non-byte representation (ie SIMD, etc) internally.</div><div>E=
xposing as_bytes forces a byte order representation.=C2=A0 Fine, but then c=
ontainer-like is unnecessary.</div><div><br></div><div>Maybe you should inc=
lude a discussion of this in the paper, along with pros/cons of non-byte-or=
der representations.</div><div><br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><br></div><div>The revised proposal doc=
ument is available here=C2=A0<a href=3D"https://github.com/mariusbancila/st=
duuid/blob/master/P0959.md" target=3D"_blank">https://github.com/mariusbanc=
ila/stduuid/blob/master/P0959.md</a> for further review.</div><div><br></di=
v><div>Thank you,</div><div>Marius</div></div><br><div class=3D"gmail_quote=
"><div><div class=3D"m_-8414290127036000456h5"><div dir=3D"ltr">On Fri, Jun=
 15, 2018 at 3:54 PM Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com" tar=
get=3D"_blank">tvaneerd@gmail.com</a>&gt; wrote:<br></div></div></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div><div class=3D"m_-8414290127036000456h5"><div=
 dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Jun 14, 2018 at 4:43 PM, Andrey Semashev <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On=
 Thu, Jun 14, 2018 at 11:09 PM, Tony V E &lt;<a href=3D"mailto:tvaneerd@gma=
il.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt; OK, revising, based on latest emails:<br>
&gt;<br>
&gt; On Wed, Jun 13, 2018 at 11:11 PM, Tony V E &lt;<a href=3D"mailto:tvane=
erd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
</span><span>&gt;&gt; - construct from a fixed-size span&lt;const std::byte=
, 16&gt;. This makes &quot;wrong<br>
&gt;&gt; size&quot; not your problem.<br>
&gt;<br>
&gt; still yes.=C2=A0 Except uint8_t.<br>
&gt; We need to say that the order matches the RFC<br>
<br>
</span>Personally, I&#39;d prefer span&lt;const T, 16&gt; where T is one of=
 std::byte,<br>
unsigned char, signed char or char. std::byte is rather cumbersome to<br>
use, most of the time you get some variant of char from external<br>
sources.<br>
<br>
uint8_t would limit std::uuid to only platforms with 8-bit bytes. This<br>
is probably unnecessary.<br>
<span><br>
&gt;&gt; - not sure whether the iterator constructor should stay - I suppos=
e it is<br>
&gt;&gt; useful for non-contiguous cases.=C2=A0 Committee might make it UB =
if it is not 16<br>
&gt;&gt; bytes.<br>
&gt;<br>
&gt; Do we even need the end iterator?<br>
<br>
</span>Some implementations might want to use it for debugging purposes.<br=
></blockquote><div><br></div><div>That reminds me - the end iterator should=
 be a separate type from the begin iterator - ie Iterator begin, Sentinel e=
nd, like Ranges.</div><div>Or, actually, just take a Range, since Ranges ar=
e likely in C++20.</div><div><br></div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
<span><br>
&gt;&gt; - remove container-like stuff: size and iterators, typedefs, etc -=
 just<br>
&gt;&gt; have a to_span() function that returns a span&lt;const std::byte, =
16&gt;<br>
&gt;&gt; (it probably never should have had mutable iterators, btw - we don=
&#39;t want<br>
&gt;&gt; to allow changing single bytes in a uuid)<br>
&gt;&gt;<br>
&gt;&gt; Oh, wait - you were saying that the internal representation might =
not be<br>
&gt;&gt; just bytes - is that important?<br>
&gt;<br>
&gt; OK, so keep the container interface.=C2=A0 But only const_iterators.=
=C2=A0 Not<br>
&gt; mutable.<br>
&gt; Is that a problem for writing into an existing uuid?=C2=A0 Construct a=
 new one<br>
&gt; and assign?=C2=A0 Let the compiler optimize it.<br>
&gt; Or do we need the mutable iterators?=C2=A0 They seem wrong to me.<br>
<br>
</span>I&#39;d be ok with only const_iterators.<br>
<span><br>
&gt;&gt; - should be trivially copyable, etc<br>
&gt;<br>
&gt; yes?<br>
<br>
</span>I don&#39;t see an immediate use case that requires trivial copyabil=
ity,<br>
but if it happens to be trivially copyable, why not.<br>
<span><br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B6Djfqg17%2BCRyX4qxWA0Y=
uEAk6doySZQ6Q-e5MFp5V9zYA%40mail.gmail.com" rel=3D"noreferrer" target=3D"_b=
lank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEhD%2B=
6Djfqg17%2BCRyX4qxWA0YuEAk6doySZQ6Q-e5MFp5V9zYA%40mail.gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"m_-841429=
0127036000456m_2906600713733491105m_-6409816038175448163gmail_signature" da=
ta-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></=
div>Tony<br></div></div>
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivzYngSA3G0yLr42Yap-Pn7C9TvdWdQ=
sq0vbwUVZRKdmA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAOHCbivzYngSA3G0yLr42Yap-Pn7C9TvdWdQsq0vbwUVZRKdmA%40mail.gmail.com</=
a>.<br>
</blockquote></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxNbbrEPSycOPJPAiUtxLY6mTtGqj=
kGhYoT%2B9M5g4ByrA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CA%2BgtASxNbbrEPSycOPJPAiUtxLY6mTtGqjkGhYoT%2B9M5g4ByrA%40mail.gma=
il.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"m_-841429=
0127036000456gmail_signature" data-smartmail=3D"gmail_signature"><div dir=
=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuO%3D6vMbwCnaDUD%3DdZ1bc0-Xf5q=
qyzJhfisqpubW-2gaA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAOHCbiuO%3D6vMbwCnaDUD%3DdZ1bc0-Xf5qqyzJhfisqpubW-2gaA%40mail.gma=
il.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxZWuGysb8hKSyYM8tvDgCzwcEghh=
Bu45cLiSvO0e8RYg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxZWuGy=
sb8hKSyYM8tvDgCzwcEghhBu45cLiSvO0e8RYg%40mail.gmail.com</a>.<br />

--0000000000006602b0056fc2dc3b--

.

--000000000000295c8c056fc30078
Content-Type: text/plain; charset="UTF-8"

>
> Is there a reason why there are a member and non member functions for
>> operator== and operator<?
>
>
> They are all non-member.
>

Whoops, didn't realize they were were friends.

>
> I think it makes sense to use operator<=> instead of operator== and
>> operator!= (as an additional benefit, you can then use uuid as a non-type
>> template parameter).
>
>
> My initial idea was to only be able to compare uuid for equality. operator
> < is necessary to be able to use uuids with associative containers. It does
> not really make sense to compare whether a uuid is less than another for
> any other reasons. Should we want to have all these comparison operators,
> then yes, it makes more sense to use the <=> operator.
>
> constexpr auto operator <=>(uuid const & lhs, uuid const & rhs) noexcept;
>

Just because we don't want the others operators doesn't mean we can't use
the spaceship operator:

    constexpr std::strong_equality operator<=>(uuid const&, uuid const&)
noexcept = default;

The operator< can always be provided as an extra overload.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq3Arjy%2Bu_qh_qDHrXrEuiQ2riCtGhy-rwUkvS3i%3D1JfzQ%40mail.gmail.com.

--000000000000295c8c056fc30078
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is=
 there a reason why there are a member and non member functions for operato=
r=3D=3D and operator&lt;?</blockquote><div><br></div><div>They are all non-=
member.</div></div></blockquote></div></div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">Whoops, didn&#39;t realize they were were friends.</div><div=
 dir=3D"auto"><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"><di=
v dir=3D"ltr"><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">I think it makes sense to use operator&lt;=3D&gt; instead of operator=
=3D=3D and operator!=3D (as an additional benefit, you can then use uuid as=
 a non-type template parameter).</blockquote><div><br></div><div>My initial=
 idea was to only be able to compare uuid for equality. operator &lt; is ne=
cessary to be able to use uuids with associative containers. It does not re=
ally make sense to compare whether a uuid is less than another for any othe=
r reasons. Should we want to have all these comparison operators, then yes,=
 it makes more sense to use the &lt;=3D&gt; operator.</div><div><br></div><=
div>constexpr auto operator &lt;=3D&gt;(uuid const &amp; lhs, uuid const &a=
mp; rhs) noexcept;<br></div></div></blockquote></div></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">Just because we don&#39;t want the others ope=
rators doesn&#39;t mean we can&#39;t use the spaceship operator:</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">=C2=A0 =C2=A0 constexpr std::stron=
g_equality operator&lt;=3D&gt;(uuid const&amp;, uuid const&amp;) noexcept =
=3D default;</div><div dir=3D"auto"><br></div><div dir=3D"auto">The operato=
r&lt; can always be provided as an extra overload.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq3Arjy%2Bu_qh_qDHrXrEuiQ2riCtGh=
y-rwUkvS3i%3D1JfzQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq3Arjy%=
2Bu_qh_qDHrXrEuiQ2riCtGhy-rwUkvS3i%3D1JfzQ%40mail.gmail.com</a>.<br />

--000000000000295c8c056fc30078--

.

--000000000000976e6605701ab394
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 29, 2018 at 3:43 AM, Nicolas Lesser <blitzrakete@gmail.com>
wrote:

> Is there a reason why there are a member and non member functions for
>>> operator== and operator<?
>>
>>
>> They are all non-member.
>>
>
> Whoops, didn't realize they were were friends.
>
>>
>> I think it makes sense to use operator<=> instead of operator== and
>>> operator!= (as an additional benefit, you can then use uuid as a non-type
>>> template parameter).
>>
>>
>> My initial idea was to only be able to compare uuid for equality.
>> operator < is necessary to be able to use uuids with associative
>> containers. It does not really make sense to compare whether a uuid is less
>> than another for any other reasons. Should we want to have all these
>> comparison operators, then yes, it makes more sense to use the <=> operator.
>>
>> constexpr auto operator <=>(uuid const & lhs, uuid const & rhs) noexcept;
>>
>
> Just because we don't want the others operators doesn't mean we can't use
> the spaceship operator:
>
>     constexpr std::strong_equality operator<=>(uuid const&, uuid const&)
> noexcept = default;
>
> The operator< can always be provided as an extra overload.
>


If we only want map/set interop, then define a std::less<uuid>, not
operator<.

Alternatively, recognize that unordered_map/set are associative containers
that don't require an ordering.

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

--000000000000976e6605701ab394
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 29, 2018 at 3:43 AM, Nicolas Lesser <span dir=3D"ltr">&lt;<=
a href=3D"mailto:blitzrakete@gmail.com" target=3D"_blank">blitzrakete@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"au=
to"><span class=3D""><div><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>Is there a reason why there are a member and non member functions for oper=
ator=3D=3D and operator&lt;?</blockquote><div><br></div><div>They are all n=
on-member.</div></div></blockquote></div></div><div dir=3D"auto"><br></div>=
</span><div dir=3D"auto">Whoops, didn&#39;t realize they were were friends.=
</div><span class=3D""><div dir=3D"auto"><div class=3D"gmail_quote"><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><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">I think it makes sense to use operator&lt;=
=3D&gt; instead of operator=3D=3D and operator!=3D (as an additional benefi=
t, you can then use uuid as a non-type template parameter).</blockquote><di=
v><br></div><div>My initial idea was to only be able to compare uuid for eq=
uality. operator &lt; is necessary to be able to use uuids with associative=
 containers. It does not really make sense to compare whether a uuid is les=
s than another for any other reasons. Should we want to have all these comp=
arison operators, then yes, it makes more sense to use the &lt;=3D&gt; oper=
ator.</div><div><br></div><div>constexpr auto operator &lt;=3D&gt;(uuid con=
st &amp; lhs, uuid const &amp; rhs) noexcept;<br></div></div></blockquote><=
/div></div><div dir=3D"auto"><br></div></span><div dir=3D"auto">Just becaus=
e we don&#39;t want the others operators doesn&#39;t mean we can&#39;t use =
the spaceship operator:</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
=C2=A0 =C2=A0 constexpr std::strong_equality operator&lt;=3D&gt;(uuid const=
&amp;, uuid const&amp;) noexcept =3D default;</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">The operator&lt; can always be provided as an extra o=
verload.</div></div></blockquote><div><br></div><div><br></div>If we only w=
ant map/set interop, then define a std::less&lt;uuid&gt;, not operator&lt;.=
</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Alter=
natively, recognize that unordered_map/set are associative containers that =
don&#39;t require an ordering.<br clear=3D"all"></div><br>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><d=
iv>Be seeing you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbisNio5vqJO2OL0vyx5fFvvjPz2yVgWQ=
Yrjr83wGm9E00w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbisNio5vqJO2=
OL0vyx5fFvvjPz2yVgWQYrjr83wGm9E00w%40mail.gmail.com</a>.<br />

--000000000000976e6605701ab394--

.

--00000000000059bb2205701b15d6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 3, 2018 at 9:21 AM, Tony V E <tvaneerd@gmail.com> wrote:

> On Fri, Jun 29, 2018 at 3:43 AM, Nicolas Lesser <blitzrakete@gmail.com>
> wrote:
>
>> Is there a reason why there are a member and non member functions for
>>>> operator=3D=3D and operator<?
>>>
>>>
>>> They are all non-member.
>>>
>>
>> Whoops, didn't realize they were were friends.
>>
>>>
>>> I think it makes sense to use operator<=3D> instead of operator=3D=3D a=
nd
>>>> operator!=3D (as an additional benefit, you can then use uuid as a non=
-type
>>>> template parameter).
>>>
>>>
>>> My initial idea was to only be able to compare uuid for equality.
>>> operator < is necessary to be able to use uuids with associative
>>> containers. It does not really make sense to compare whether a uuid is =
less
>>> than another for any other reasons. Should we want to have all these
>>> comparison operators, then yes, it makes more sense to use the <=3D> op=
erator.
>>>
>>> constexpr auto operator <=3D>(uuid const & lhs, uuid const & rhs) noexc=
ept;
>>>
>>
>> Just because we don't want the others operators doesn't mean we can't us=
e
>> the spaceship operator:
>>
>>     constexpr std::strong_equality operator<=3D>(uuid const&, uuid const=
&)
>> noexcept =3D default;
>>
>> The operator< can always be provided as an extra overload.
>>
>
> If we only want map/set interop, then define a std::less<uuid>, not
> operator<.
>

Please don't do this.
You should never explicitly specialize std::less<T> for any type, ever.
The primary reason is that it breaks all the user's expectations. The
secondary reason is that it won't always work! Heterogeneous containers use
std::less<>, not std::less<T>.

If your type has operator<, then it should have the full complement of < <=
=3D
=3D=3D >=3D > !=3D (which in C++2a means "it should have operator<=3D>").
Orthogonally to that consideration, std::less<T>'s whole purpose is to
expose the semantics of everybody's operator< in a consistent and
functorish way.
Your proposal has nothing to do with std::less, and therefore should not
touch it.

If you really hate comparison operators for some reason, then the
STL-favored thing to do is add a free function named *foo*_less with the
semantics you want for your comparator, and force people to type out
    using uuidset_t =3D std::set<std::uuid, std::foo_less>;
Prior art: https://en.cppreference.com/w/cpp/memory/owner_less
However, we can tell that this is probably a bad idea in your case by
considering what is the appropriate name for "foo_less" in this case. It's
comparing uuids, and it's comparing them on the only thing it makes sense
to compare uuids on =E2=80=94 their values =E2=80=94 so the logical name fo=
r the free
function is "uuid_less".
    using uuidset_t =3D std::set<std::uuid, std::uuid_less>;
But C++ has a better way to spell "uuid_less(const uuid&, const uuid&)"!
That spelling is very old-school-C.  The C++-ish spelling for "uuid_less"
is...
    bool operator<(const uuid&, const uuid&);
This conveys the same information =E2=80=94 "compares uuids, for less-than"=
 =E2=80=94 but
it conveys it in a shorter and simpler way that also composes (semi)nicely
with generic containers such as std::set and std::map.


Alternatively, recognize that unordered_map/set are associative containers
> that don't require an ordering.
>

I personally wouldn't mind if std::uuid, like std::byte, didn't have any
"less-than" operation at all, and if you wanted to compare them
(binary-search an array of them, whatever) you had to cast them to string
or something. But that's because I wouldn't use std::uuid much. If I did
use it, I'd probably notice the lack and complain about it.

(And I say this as someone who has often railed against the dangers of
tuple::operator< and optional::operator<. Consistency is, etc.)

=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0Jx%3DUAqczN0FVNu9DqxWrahjf8Wk-tELna_KCMCJ=
OHPRg%40mail.gmail.com.

--00000000000059bb2205701b15d6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Jul 3, 2018 at 9:21 AM, Tony V E <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail=
..com</a>&gt;</span> wrote:<div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote">On Fri, Jun 29, 2018 at 3:43 AM, Nicolas Lesser <span dir=
=3D"ltr">&lt;<a href=3D"mailto:blitzrakete@gmail.com" target=3D"_blank">bli=
tzrakete@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-styl=
e:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"au=
to"><span><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-style:=
solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);=
padding-left:1ex">Is there a reason why there are a member and non member f=
unctions for operator=3D=3D and operator&lt;?</blockquote><div><br></div><d=
iv>They are all non-member.</div></div></blockquote></div></div><div dir=3D=
"auto"><br></div></span><div dir=3D"auto">Whoops, didn&#39;t realize they w=
ere were friends.</div><span><div dir=3D"auto"><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I think it=
 makes sense to use operator&lt;=3D&gt; instead of operator=3D=3D and opera=
tor!=3D (as an additional benefit, you can then use uuid as a non-type temp=
late parameter).</blockquote><div><br></div><div>My initial idea was to onl=
y be able to compare uuid for equality. operator &lt; is necessary to be ab=
le to use uuids with associative containers. It does not really make sense =
to compare whether a uuid is less than another for any other reasons. Shoul=
d we want to have all these comparison operators, then yes, it makes more s=
ense to use the &lt;=3D&gt; operator.</div><div><br></div><div>constexpr au=
to operator &lt;=3D&gt;(uuid const &amp; lhs, uuid const &amp; rhs) noexcep=
t;<br></div></div></blockquote></div></div><div dir=3D"auto"><br></div></sp=
an><div dir=3D"auto">Just because we don&#39;t want the others operators do=
esn&#39;t mean we can&#39;t use the spaceship operator:</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">=C2=A0 =C2=A0 constexpr std::strong_equalit=
y operator&lt;=3D&gt;(uuid const&amp;, uuid const&amp;) noexcept =3D defaul=
t;</div><div dir=3D"auto"><br></div><div dir=3D"auto">The operator&lt; can =
always be provided as an extra overload.</div></div></blockquote><div><br><=
/div>If we only want map/set interop, then define a std::less&lt;uuid&gt;, =
not operator&lt;.</div></div></div></blockquote><div><br></div><div>Please =
don&#39;t do this.</div><div>You should never explicitly specialize std::le=
ss&lt;T&gt; for any type, ever.=C2=A0 The primary reason is that it breaks =
all the user&#39;s expectations. The secondary reason is that it won&#39;t =
always work! Heterogeneous containers use std::less&lt;&gt;, not std::less&=
lt;T&gt;.</div><div><br></div><div>If your type has operator&lt;, then it s=
hould have the full complement of &lt; &lt;=3D =3D=3D &gt;=3D &gt; !=3D (wh=
ich in C++2a means &quot;it should have operator&lt;=3D&gt;&quot;).</div><d=
iv>Orthogonally to that consideration, std::less&lt;T&gt;&#39;s whole purpo=
se is to expose the semantics of everybody&#39;s operator&lt; in a consiste=
nt and functorish way.</div><div>Your proposal has nothing to do with std::=
less, and therefore should not touch it.</div><div><br></div><div>If you re=
ally hate comparison operators for some reason, then the STL-favored thing =
to do is add a free function named <i>foo</i>_less with the semantics you w=
ant for your comparator, and force people to type out</div><div>=C2=A0 =C2=
=A0 using uuidset_t =3D std::set&lt;std::uuid, std::foo_less&gt;;</div><div=
>Prior art: <a href=3D"https://en.cppreference.com/w/cpp/memory/owner_less"=
>https://en.cppreference.com/w/cpp/memory/owner_less</a><br></div><div>Howe=
ver, we can tell that this is probably a bad idea in your case by consideri=
ng what is the appropriate name for &quot;foo_less&quot; in this case. It&#=
39;s comparing uuids, and it&#39;s comparing them on the only thing it make=
s sense to compare uuids on =E2=80=94 their values =E2=80=94 so the logical=
 name for the free function is &quot;uuid_less&quot;.</div><div><div>=C2=A0=
 =C2=A0 using uuidset_t =3D std::set&lt;std::uuid, std::uuid_less&gt;;</div=
></div><div>But C++ has a better way to spell &quot;uuid_less(const uuid&am=
p;, const uuid&amp;)&quot;!=C2=A0 That spelling is very old-school-C.=C2=A0=
 The C++-ish spelling for &quot;uuid_less&quot; is...</div><div>=C2=A0 =C2=
=A0 bool operator&lt;(const uuid&amp;, const uuid&amp;);</div><div>This con=
veys the same information =E2=80=94 &quot;compares uuids, for less-than&quo=
t; =E2=80=94 but it conveys it in a shorter and simpler way that also compo=
ses (semi)nicely with generic containers such as std::set and std::map.</di=
v><div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"></div><div class=3D"gmail_quot=
e">Alternatively, recognize that unordered_map/set are associative containe=
rs that don&#39;t require an ordering.</div></div></div></blockquote><div><=
br></div><div>I personally wouldn&#39;t mind if std::uuid, like std::byte, =
didn&#39;t have any &quot;less-than&quot; operation at all, and if you want=
ed to compare them (binary-search an array of them, whatever) you had to ca=
st them to string or something. But that&#39;s because I wouldn&#39;t use s=
td::uuid much. If I did use it, I&#39;d probably notice the lack and compla=
in about it.</div><div><br></div><div>(And I say this as someone who has of=
ten railed against the dangers of tuple::operator&lt; and optional::operato=
r&lt;. Consistency is, etc.)</div><div><br></div><div>=E2=80=93Arthur</div>=
</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx%3DUAqczN0FVNu9DqxWrahjf8Wk-=
tELna_KCMCJOHPRg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx%3DUAq=
czN0FVNu9DqxWrahjf8Wk-tELna_KCMCJOHPRg%40mail.gmail.com</a>.<br />

--00000000000059bb2205701b15d6--

.

--000000000000d523d1057039f2b3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I don't think specializing std::less for uuid is a good idea. I prefer
having operator <, which, as said earlier, should actually be operator <=3D=
>.

On Tue, Jul 3, 2018 at 7:48 PM Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

> On Tue, Jul 3, 2018 at 9:21 AM, Tony V E <tvaneerd@gmail.com> wrote:
>
>> On Fri, Jun 29, 2018 at 3:43 AM, Nicolas Lesser <blitzrakete@gmail.com>
>> wrote:
>>
>>> Is there a reason why there are a member and non member functions for
>>>>> operator=3D=3D and operator<?
>>>>
>>>>
>>>> They are all non-member.
>>>>
>>>
>>> Whoops, didn't realize they were were friends.
>>>
>>>>
>>>> I think it makes sense to use operator<=3D> instead of operator=3D=3D =
and
>>>>> operator!=3D (as an additional benefit, you can then use uuid as a no=
n-type
>>>>> template parameter).
>>>>
>>>>
>>>> My initial idea was to only be able to compare uuid for equality.
>>>> operator < is necessary to be able to use uuids with associative
>>>> containers. It does not really make sense to compare whether a uuid is=
 less
>>>> than another for any other reasons. Should we want to have all these
>>>> comparison operators, then yes, it makes more sense to use the <=3D> o=
perator.
>>>>
>>>> constexpr auto operator <=3D>(uuid const & lhs, uuid const & rhs)
>>>> noexcept;
>>>>
>>>
>>> Just because we don't want the others operators doesn't mean we can't
>>> use the spaceship operator:
>>>
>>>     constexpr std::strong_equality operator<=3D>(uuid const&, uuid cons=
t&)
>>> noexcept =3D default;
>>>
>>> The operator< can always be provided as an extra overload.
>>>
>>
>> If we only want map/set interop, then define a std::less<uuid>, not
>> operator<.
>>
>
> Please don't do this.
> You should never explicitly specialize std::less<T> for any type, ever.
> The primary reason is that it breaks all the user's expectations. The
> secondary reason is that it won't always work! Heterogeneous containers u=
se
> std::less<>, not std::less<T>.
>
> If your type has operator<, then it should have the full complement of <
> <=3D =3D=3D >=3D > !=3D (which in C++2a means "it should have operator<=
=3D>").
> Orthogonally to that consideration, std::less<T>'s whole purpose is to
> expose the semantics of everybody's operator< in a consistent and
> functorish way.
> Your proposal has nothing to do with std::less, and therefore should not
> touch it.
>
> If you really hate comparison operators for some reason, then the
> STL-favored thing to do is add a free function named *foo*_less with the
> semantics you want for your comparator, and force people to type out
>     using uuidset_t =3D std::set<std::uuid, std::foo_less>;
> Prior art: https://en.cppreference.com/w/cpp/memory/owner_less
> However, we can tell that this is probably a bad idea in your case by
> considering what is the appropriate name for "foo_less" in this case. It'=
s
> comparing uuids, and it's comparing them on the only thing it makes sense
> to compare uuids on =E2=80=94 their values =E2=80=94 so the logical name =
for the free
> function is "uuid_less".
>     using uuidset_t =3D std::set<std::uuid, std::uuid_less>;
> But C++ has a better way to spell "uuid_less(const uuid&, const uuid&)"!
> That spelling is very old-school-C.  The C++-ish spelling for "uuid_less"
> is...
>     bool operator<(const uuid&, const uuid&);
> This conveys the same information =E2=80=94 "compares uuids, for less-tha=
n" =E2=80=94 but
> it conveys it in a shorter and simpler way that also composes (semi)nicel=
y
> with generic containers such as std::set and std::map.
>
>
> Alternatively, recognize that unordered_map/set are associative container=
s
>> that don't require an ordering.
>>
>
> I personally wouldn't mind if std::uuid, like std::byte, didn't have any
> "less-than" operation at all, and if you wanted to compare them
> (binary-search an array of them, whatever) you had to cast them to string
> or something. But that's because I wouldn't use std::uuid much. If I did
> use it, I'd probably notice the lack and complain about it.
>
> (And I say this as someone who has often railed against the dangers of
> tuple::operator< and optional::operator<. Consistency is, etc.)
>
> =E2=80=93Arthur
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx%3D=
UAqczN0FVNu9DqxWrahjf8Wk-tELna_KCMCJOHPRg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx%3=
DUAqczN0FVNu9DqxWrahjf8Wk-tELna_KCMCJOHPRg%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CA%2BgtASxTLX6eQa%2BZTR4ay60q_FryMYUucGmw4UVxVW-=
PP4X8ZA%40mail.gmail.com.

--000000000000d523d1057039f2b3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I don&#39;t think specializing std::less for uuid is a goo=
d idea. I prefer having operator &lt;, which, as said earlier, should actua=
lly be operator &lt;=3D&gt;.</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Tue, Jul 3, 2018 at 7:48 PM Arthur O&#39;Dwyer &lt;<a href=3D"m=
ailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>&gt; wrote:<b=
r></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">On Tue, Jul 3, 2018=
 at 9:21 AM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmai=
l.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrote:<div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-styl=
e:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Fri, Jun 29, 20=
18 at 3:43 AM, Nicolas Lesser <span dir=3D"ltr">&lt;<a href=3D"mailto:blitz=
rakete@gmail.com" target=3D"_blank">blitzrakete@gmail.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"auto"><span><div><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:so=
lid;border-left-color:rgb(204,204,204);padding-left:1ex">Is there a reason =
why there are a member and non member functions for operator=3D=3D and oper=
ator&lt;?</blockquote><div><br></div><div>They are all non-member.</div></d=
iv></blockquote></div></div><div dir=3D"auto"><br></div></span><div dir=3D"=
auto">Whoops, didn&#39;t realize they were were friends.</div><span><div di=
r=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:soli=
d;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(20=
4,204,204);padding-left:1ex">I think it makes sense to use operator&lt;=3D&=
gt; instead of operator=3D=3D and operator!=3D (as an additional benefit, y=
ou can then use uuid as a non-type template parameter).</blockquote><div><b=
r></div><div>My initial idea was to only be able to compare uuid for equali=
ty. operator &lt; is necessary to be able to use uuids with associative con=
tainers. It does not really make sense to compare whether a uuid is less th=
an another for any other reasons. Should we want to have all these comparis=
on operators, then yes, it makes more sense to use the &lt;=3D&gt; operator=
..</div><div><br></div><div>constexpr auto operator &lt;=3D&gt;(uuid const &=
amp; lhs, uuid const &amp; rhs) noexcept;<br></div></div></blockquote></div=
></div><div dir=3D"auto"><br></div></span><div dir=3D"auto">Just because we=
 don&#39;t want the others operators doesn&#39;t mean we can&#39;t use the =
spaceship operator:</div><div dir=3D"auto"><br></div><div dir=3D"auto">=C2=
=A0 =C2=A0 constexpr std::strong_equality operator&lt;=3D&gt;(uuid const&am=
p;, uuid const&amp;) noexcept =3D default;</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">The operator&lt; can always be provided as an extra over=
load.</div></div></blockquote><div><br></div>If we only want map/set intero=
p, then define a std::less&lt;uuid&gt;, not operator&lt;.</div></div></div>=
</blockquote><div><br></div><div>Please don&#39;t do this.</div><div>You sh=
ould never explicitly specialize std::less&lt;T&gt; for any type, ever.=C2=
=A0 The primary reason is that it breaks all the user&#39;s expectations. T=
he secondary reason is that it won&#39;t always work! Heterogeneous contain=
ers use std::less&lt;&gt;, not std::less&lt;T&gt;.</div><div><br></div><div=
>If your type has operator&lt;, then it should have the full complement of =
&lt; &lt;=3D =3D=3D &gt;=3D &gt; !=3D (which in C++2a means &quot;it should=
 have operator&lt;=3D&gt;&quot;).</div><div>Orthogonally to that considerat=
ion, std::less&lt;T&gt;&#39;s whole purpose is to expose the semantics of e=
verybody&#39;s operator&lt; in a consistent and functorish way.</div><div>Y=
our proposal has nothing to do with std::less, and therefore should not tou=
ch it.</div><div><br></div><div>If you really hate comparison operators for=
 some reason, then the STL-favored thing to do is add a free function named=
 <i>foo</i>_less with the semantics you want for your comparator, and force=
 people to type out</div><div>=C2=A0 =C2=A0 using uuidset_t =3D std::set&lt=
;std::uuid, std::foo_less&gt;;</div><div>Prior art: <a href=3D"https://en.c=
ppreference.com/w/cpp/memory/owner_less" target=3D"_blank">https://en.cppre=
ference.com/w/cpp/memory/owner_less</a><br></div><div>However, we can tell =
that this is probably a bad idea in your case by considering what is the ap=
propriate name for &quot;foo_less&quot; in this case. It&#39;s comparing uu=
ids, and it&#39;s comparing them on the only thing it makes sense to compar=
e uuids on =E2=80=94 their values =E2=80=94 so the logical name for the fre=
e function is &quot;uuid_less&quot;.</div><div><div>=C2=A0 =C2=A0 using uui=
dset_t =3D std::set&lt;std::uuid, std::uuid_less&gt;;</div></div><div>But C=
++ has a better way to spell &quot;uuid_less(const uuid&amp;, const uuid&am=
p;)&quot;!=C2=A0 That spelling is very old-school-C.=C2=A0 The C++-ish spel=
ling for &quot;uuid_less&quot; is...</div><div>=C2=A0 =C2=A0 bool operator&=
lt;(const uuid&amp;, const uuid&amp;);</div><div>This conveys the same info=
rmation =E2=80=94 &quot;compares uuids, for less-than&quot; =E2=80=94 but i=
t conveys it in a shorter and simpler way that also composes (semi)nicely w=
ith generic containers such as std::set and std::map.</div><div><br></div><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(=
204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"></div><div class=3D"gmail_quote">Alternatively, =
recognize that unordered_map/set are associative containers that don&#39;t =
require an ordering.</div></div></div></blockquote><div><br></div><div>I pe=
rsonally wouldn&#39;t mind if std::uuid, like std::byte, didn&#39;t have an=
y &quot;less-than&quot; operation at all, and if you wanted to compare them=
 (binary-search an array of them, whatever) you had to cast them to string =
or something. But that&#39;s because I wouldn&#39;t use std::uuid much. If =
I did use it, I&#39;d probably notice the lack and complain about it.</div>=
<div><br></div><div>(And I say this as someone who has often railed against=
 the dangers of tuple::operator&lt; and optional::operator&lt;. Consistency=
 is, etc.)</div><div><br></div><div>=E2=80=93Arthur</div></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx%3DUAqczN0FVNu9DqxWrahjf8Wk-=
tELna_KCMCJOHPRg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CADvuK0Jx%3DUAqczN0FVNu9DqxWrahjf8Wk-tELna_KCMCJOHPRg%40mail.gmail.c=
om</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxTLX6eQa%2BZTR4ay60q_FryMYUu=
cGmw4UVxVW-PP4X8ZA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxTLX=
6eQa%2BZTR4ay60q_FryMYUucGmw4UVxVW-PP4X8ZA%40mail.gmail.com</a>.<br />

--000000000000d523d1057039f2b3--

.

--00000000000097054a05703e14dd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The discussion on operator< is interesting.

I had a look at the wikipedia page for UUID and note that there is a
specific warning about using UUIDs as primary keys in ordered indexes.

This begs the question: when would ordering be required for a UUID?

Equality and std::hash I can completely understand, but a UUID itself
encodes no information on relative order. It's salient property is merely
universal uniqueness.

I would argue that the only operators that should be defined are:

binary operator=3D=3D - test for equality
binary operator!=3D - test for inequality
plus a specialisation of std::hash

very much more arguably (i.e. I would expect more argument over these):
operator bool - returns true iff the uuid is not null
unary ! - returns true if the uuid is a null uuid

In my view the following operators make no sense:
operator <
operator << (other than to stream to basic_ostream<>)
operator >
operstor >> (other than to deserialise from basic_istream<>)
operator +, -, /, *,

R

On Thu, 5 Jul 2018 at 07:37, Marius Bancila <marius.bancila@gmail.com>
wrote:

> I don't think specializing std::less for uuid is a good idea. I prefer
> having operator <, which, as said earlier, should actually be operator <=
=3D>.
>
> On Tue, Jul 3, 2018 at 7:48 PM Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
> wrote:
>
>> On Tue, Jul 3, 2018 at 9:21 AM, Tony V E <tvaneerd@gmail.com> wrote:
>>
>>> On Fri, Jun 29, 2018 at 3:43 AM, Nicolas Lesser <blitzrakete@gmail.com>
>>> wrote:
>>>
>>>> Is there a reason why there are a member and non member functions for
>>>>>> operator=3D=3D and operator<?
>>>>>
>>>>>
>>>>> They are all non-member.
>>>>>
>>>>
>>>> Whoops, didn't realize they were were friends.
>>>>
>>>>>
>>>>> I think it makes sense to use operator<=3D> instead of operator=3D=3D=
 and
>>>>>> operator!=3D (as an additional benefit, you can then use uuid as a n=
on-type
>>>>>> template parameter).
>>>>>
>>>>>
>>>>> My initial idea was to only be able to compare uuid for equality.
>>>>> operator < is necessary to be able to use uuids with associative
>>>>> containers. It does not really make sense to compare whether a uuid i=
s less
>>>>> than another for any other reasons. Should we want to have all these
>>>>> comparison operators, then yes, it makes more sense to use the <=3D> =
operator.
>>>>>
>>>>> constexpr auto operator <=3D>(uuid const & lhs, uuid const & rhs)
>>>>> noexcept;
>>>>>
>>>>
>>>> Just because we don't want the others operators doesn't mean we can't
>>>> use the spaceship operator:
>>>>
>>>>     constexpr std::strong_equality operator<=3D>(uuid const&, uuid
>>>> const&) noexcept =3D default;
>>>>
>>>> The operator< can always be provided as an extra overload.
>>>>
>>>
>>> If we only want map/set interop, then define a std::less<uuid>, not
>>> operator<.
>>>
>>
>> Please don't do this.
>> You should never explicitly specialize std::less<T> for any type, ever.
>> The primary reason is that it breaks all the user's expectations. The
>> secondary reason is that it won't always work! Heterogeneous containers =
use
>> std::less<>, not std::less<T>.
>>
>> If your type has operator<, then it should have the full complement of <
>> <=3D =3D=3D >=3D > !=3D (which in C++2a means "it should have operator<=
=3D>").
>> Orthogonally to that consideration, std::less<T>'s whole purpose is to
>> expose the semantics of everybody's operator< in a consistent and
>> functorish way.
>> Your proposal has nothing to do with std::less, and therefore should not
>> touch it.
>>
>> If you really hate comparison operators for some reason, then the
>> STL-favored thing to do is add a free function named *foo*_less with the
>> semantics you want for your comparator, and force people to type out
>>     using uuidset_t =3D std::set<std::uuid, std::foo_less>;
>> Prior art: https://en.cppreference.com/w/cpp/memory/owner_less
>> However, we can tell that this is probably a bad idea in your case by
>> considering what is the appropriate name for "foo_less" in this case. It=
's
>> comparing uuids, and it's comparing them on the only thing it makes sens=
e
>> to compare uuids on =E2=80=94 their values =E2=80=94 so the logical name=
 for the free
>> function is "uuid_less".
>>     using uuidset_t =3D std::set<std::uuid, std::uuid_less>;
>> But C++ has a better way to spell "uuid_less(const uuid&, const uuid&)"!
>> That spelling is very old-school-C.  The C++-ish spelling for "uuid_less=
"
>> is...
>>     bool operator<(const uuid&, const uuid&);
>> This conveys the same information =E2=80=94 "compares uuids, for less-th=
an" =E2=80=94 but
>> it conveys it in a shorter and simpler way that also composes (semi)nice=
ly
>> with generic containers such as std::set and std::map.
>>
>>
>> Alternatively, recognize that unordered_map/set are associative
>>> containers that don't require an ordering.
>>>
>>
>> I personally wouldn't mind if std::uuid, like std::byte, didn't have any
>> "less-than" operation at all, and if you wanted to compare them
>> (binary-search an array of them, whatever) you had to cast them to strin=
g
>> or something. But that's because I wouldn't use std::uuid much. If I did
>> use it, I'd probably notice the lack and complain about it.
>>
>> (And I say this as someone who has often railed against the dangers of
>> tuple::operator< and optional::operator<. Consistency is, etc.)
>>
>> =E2=80=93Arthur
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx%3=
DUAqczN0FVNu9DqxWrahjf8Wk-tELna_KCMCJOHPRg%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx%=
3DUAqczN0FVNu9DqxWrahjf8Wk-tELna_KCMCJOHPRg%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxTL=
X6eQa%2BZTR4ay60q_FryMYUucGmw4UVxVW-PP4X8ZA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxT=
LX6eQa%2BZTR4ay60q_FryMYUucGmw4UVxVW-PP4X8ZA%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>

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

--00000000000097054a05703e14dd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The discussion on operator&lt; is interesting.=C2=A0<div><=
br></div><div>I had a look at the wikipedia page for UUID and note that the=
re is a specific warning about using UUIDs as primary keys in ordered index=
es.<div><br></div><div>This begs the question: when would ordering be requi=
red for a UUID?=C2=A0</div><div><br></div><div><font face=3D"monospace, mon=
ospace">Equality</font> and <font face=3D"monospace, monospace">std::hash</=
font> I can completely understand, but a UUID itself encodes no information=
 on relative order. It&#39;s salient property is merely universal uniquenes=
s.</div><div><br></div><div>I would argue that the only operators that shou=
ld be defined are:</div><div><br></div><div>binary <font face=3D"monospace,=
 monospace">operator=3D=3D</font> - test for equality</div><div>binary <fon=
t face=3D"monospace, monospace">operator!=3D</font> - test for inequality</=
div><div>plus a specialisation of <font face=3D"monospace, monospace">std::=
hash</font></div><div><br></div><div>very much more arguably (i.e. I would =
expect more argument over these):</div><div>operator bool - returns true if=
f the uuid is not null</div><div>unary ! - returns true if the uuid is a nu=
ll uuid</div><div><br></div><div>In my view the following operators make no=
 sense:</div><div><div style=3D"text-decoration-style:initial;text-decorati=
on-color:initial"><div style=3D"background-color:rgb(255,255,255);text-deco=
ration-style:initial;text-decoration-color:initial">operator &lt;</div><div=
 style=3D"background-color:rgb(255,255,255);text-decoration-style:initial;t=
ext-decoration-color:initial">operator &lt;&lt; (other than to stream to ba=
sic_ostream&lt;&gt;)</div>operator &gt;<br></div>operstor &gt;&gt; (other t=
han to deserialise from basic_istream&lt;&gt;)</div><div>operator=C2=A0+, -=
, /, *,=C2=A0<br class=3D"gmail-Apple-interchange-newline"><br></div><div>R=
<br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, 5 Jul 2018 at 0=
7:37, Marius Bancila &lt;<a href=3D"mailto:marius.bancila@gmail.com">marius=
..bancila@gmail.com</a>&gt; wrote:<br></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">I don&#39;t think specializing std::less for uuid is a good=
 idea. I prefer having operator &lt;, which, as said earlier, should actual=
ly be operator &lt;=3D&gt;.</div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr">On Tue, Jul 3, 2018 at 7:48 PM Arthur O&#39;Dwyer &lt;<a href=3D"mail=
to:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.com</=
a>&gt; wrote:<br></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">On T=
ue, Jul 3, 2018 at 9:21 AM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> w=
rote:<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On =
Fri, Jun 29, 2018 at 3:43 AM, Nicolas Lesser <span dir=3D"ltr">&lt;<a href=
=3D"mailto:blitzrakete@gmail.com" target=3D"_blank">blitzrakete@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-=
color:rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><span><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-style:solid;border-left-co=
lor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
Is there a reason why there are a member and non member functions for opera=
tor=3D=3D and operator&lt;?</blockquote><div><br></div><div>They are all no=
n-member.</div></div></blockquote></div></div><div dir=3D"auto"><br></div><=
/span><div dir=3D"auto">Whoops, didn&#39;t realize they were were friends.<=
/div><span><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex">I think it makes sense to =
use operator&lt;=3D&gt; instead of operator=3D=3D and operator!=3D (as an a=
dditional benefit, you can then use uuid as a non-type template parameter).=
</blockquote><div><br></div><div>My initial idea was to only be able to com=
pare uuid for equality. operator &lt; is necessary to be able to use uuids =
with associative containers. It does not really make sense to compare wheth=
er a uuid is less than another for any other reasons. Should we want to hav=
e all these comparison operators, then yes, it makes more sense to use the =
&lt;=3D&gt; operator.</div><div><br></div><div>constexpr auto operator &lt;=
=3D&gt;(uuid const &amp; lhs, uuid const &amp; rhs) noexcept;<br></div></di=
v></blockquote></div></div><div dir=3D"auto"><br></div></span><div dir=3D"a=
uto">Just because we don&#39;t want the others operators doesn&#39;t mean w=
e can&#39;t use the spaceship operator:</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">=C2=A0 =C2=A0 constexpr std::strong_equality operator&lt;=
=3D&gt;(uuid const&amp;, uuid const&amp;) noexcept =3D default;</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">The operator&lt; can always be prov=
ided as an extra overload.</div></div></blockquote><div><br></div>If we onl=
y want map/set interop, then define a std::less&lt;uuid&gt;, not operator&l=
t;.</div></div></div></blockquote><div><br></div><div>Please don&#39;t do t=
his.</div><div>You should never explicitly specialize std::less&lt;T&gt; fo=
r any type, ever.=C2=A0 The primary reason is that it breaks all the user&#=
39;s expectations. The secondary reason is that it won&#39;t always work! H=
eterogeneous containers use std::less&lt;&gt;, not std::less&lt;T&gt;.</div=
><div><br></div><div>If your type has operator&lt;, then it should have the=
 full complement of &lt; &lt;=3D =3D=3D &gt;=3D &gt; !=3D (which in C++2a m=
eans &quot;it should have operator&lt;=3D&gt;&quot;).</div><div>Orthogonall=
y to that consideration, std::less&lt;T&gt;&#39;s whole purpose is to expos=
e the semantics of everybody&#39;s operator&lt; in a consistent and functor=
ish way.</div><div>Your proposal has nothing to do with std::less, and ther=
efore should not touch it.</div><div><br></div><div>If you really hate comp=
arison operators for some reason, then the STL-favored thing to do is add a=
 free function named <i>foo</i>_less with the semantics you want for your c=
omparator, and force people to type out</div><div>=C2=A0 =C2=A0 using uuids=
et_t =3D std::set&lt;std::uuid, std::foo_less&gt;;</div><div>Prior art: <a =
href=3D"https://en.cppreference.com/w/cpp/memory/owner_less" target=3D"_bla=
nk">https://en.cppreference.com/w/cpp/memory/owner_less</a><br></div><div>H=
owever, we can tell that this is probably a bad idea in your case by consid=
ering what is the appropriate name for &quot;foo_less&quot; in this case. I=
t&#39;s comparing uuids, and it&#39;s comparing them on the only thing it m=
akes sense to compare uuids on =E2=80=94 their values =E2=80=94 so the logi=
cal name for the free function is &quot;uuid_less&quot;.</div><div><div>=C2=
=A0 =C2=A0 using uuidset_t =3D std::set&lt;std::uuid, std::uuid_less&gt;;</=
div></div><div>But C++ has a better way to spell &quot;uuid_less(const uuid=
&amp;, const uuid&amp;)&quot;!=C2=A0 That spelling is very old-school-C.=C2=
=A0 The C++-ish spelling for &quot;uuid_less&quot; is...</div><div>=C2=A0 =
=C2=A0 bool operator&lt;(const uuid&amp;, const uuid&amp;);</div><div>This =
conveys the same information =E2=80=94 &quot;compares uuids, for less-than&=
quot; =E2=80=94 but it conveys it in a shorter and simpler way that also co=
mposes (semi)nicely with generic containers such as std::set and std::map.<=
/div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"></div><div class=3D"gmail_=
quote">Alternatively, recognize that unordered_map/set are associative cont=
ainers that don&#39;t require an ordering.</div></div></div></blockquote><d=
iv><br></div><div>I personally wouldn&#39;t mind if std::uuid, like std::by=
te, didn&#39;t have any &quot;less-than&quot; operation at all, and if you =
wanted to compare them (binary-search an array of them, whatever) you had t=
o cast them to string or something. But that&#39;s because I wouldn&#39;t u=
se std::uuid much. If I did use it, I&#39;d probably notice the lack and co=
mplain about it.</div><div><br></div><div>(And I say this as someone who ha=
s often railed against the dangers of tuple::operator&lt; and optional::ope=
rator&lt;. Consistency is, etc.)</div><div><br></div><div>=E2=80=93Arthur</=
div></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx%3DUAqczN0FVNu9DqxWrahjf8Wk-=
tELna_KCMCJOHPRg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CADvuK0Jx%3DUAqczN0FVNu9DqxWrahjf8Wk-tELna_KCMCJOHPRg%40mail.gmail.c=
om</a>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxTLX6eQa%2BZTR4ay60q_FryMYUu=
cGmw4UVxVW-PP4X8ZA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CA%2BgtASxTLX6eQa%2BZTR4ay60q_FryMYUucGmw4UVxVW-PP4X8ZA%40mail.gma=
il.com</a>.<br>
</blockquote></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hbL1k9qZynhba5sa49JnLSv1r4z7jVz=
WobECQjHEw8tLQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbL1k9qZynh=
ba5sa49JnLSv1r4z7jVzWobECQjHEw8tLQ%40mail.gmail.com</a>.<br />

--00000000000097054a05703e14dd--

.

--000000000000d2a67b05703e289e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

An ordering of UUIDs is very much important for implementing unique() and
flatsets.

I would argue against inclusion of any type that can meet Stepanov Regular
(Regular + TotallyOrdered) but does not.

G

On Thu, Jul 5, 2018 at 11:33 AM, Richard Hodges <hodges.r@gmail.com> wrote:

> The discussion on operator< is interesting.
>
> I had a look at the wikipedia page for UUID and note that there is a
> specific warning about using UUIDs as primary keys in ordered indexes.
>
> This begs the question: when would ordering be required for a UUID?
>
> Equality and std::hash I can completely understand, but a UUID itself
> encodes no information on relative order. It's salient property is merely
> universal uniqueness.
>
> I would argue that the only operators that should be defined are:
>
> binary operator=3D=3D - test for equality
> binary operator!=3D - test for inequality
> plus a specialisation of std::hash
>
> very much more arguably (i.e. I would expect more argument over these):
> operator bool - returns true iff the uuid is not null
> unary ! - returns true if the uuid is a null uuid
>
> In my view the following operators make no sense:
> operator <
> operator << (other than to stream to basic_ostream<>)
> operator >
> operstor >> (other than to deserialise from basic_istream<>)
> operator +, -, /, *,
>
> R
>
>
> On Thu, 5 Jul 2018 at 07:37, Marius Bancila <marius.bancila@gmail.com>
> wrote:
>
>> I don't think specializing std::less for uuid is a good idea. I prefer
>> having operator <, which, as said earlier, should actually be operator <=
=3D>.
>>
>> On Tue, Jul 3, 2018 at 7:48 PM Arthur O'Dwyer <arthur.j.odwyer@gmail.com=
>
>> wrote:
>>
>>> On Tue, Jul 3, 2018 at 9:21 AM, Tony V E <tvaneerd@gmail.com> wrote:
>>>
>>>> On Fri, Jun 29, 2018 at 3:43 AM, Nicolas Lesser <blitzrakete@gmail.com=
>
>>>> wrote:
>>>>
>>>>> Is there a reason why there are a member and non member functions for
>>>>>>> operator=3D=3D and operator<?
>>>>>>
>>>>>>
>>>>>> They are all non-member.
>>>>>>
>>>>>
>>>>> Whoops, didn't realize they were were friends.
>>>>>
>>>>>>
>>>>>> I think it makes sense to use operator<=3D> instead of operator=3D=
=3D and
>>>>>>> operator!=3D (as an additional benefit, you can then use uuid as a =
non-type
>>>>>>> template parameter).
>>>>>>
>>>>>>
>>>>>> My initial idea was to only be able to compare uuid for equality.
>>>>>> operator < is necessary to be able to use uuids with associative
>>>>>> containers. It does not really make sense to compare whether a uuid =
is less
>>>>>> than another for any other reasons. Should we want to have all these
>>>>>> comparison operators, then yes, it makes more sense to use the <=3D>=
 operator.
>>>>>>
>>>>>> constexpr auto operator <=3D>(uuid const & lhs, uuid const & rhs)
>>>>>> noexcept;
>>>>>>
>>>>>
>>>>> Just because we don't want the others operators doesn't mean we can't
>>>>> use the spaceship operator:
>>>>>
>>>>>     constexpr std::strong_equality operator<=3D>(uuid const&, uuid
>>>>> const&) noexcept =3D default;
>>>>>
>>>>> The operator< can always be provided as an extra overload.
>>>>>
>>>>
>>>> If we only want map/set interop, then define a std::less<uuid>, not
>>>> operator<.
>>>>
>>>
>>> Please don't do this.
>>> You should never explicitly specialize std::less<T> for any type, ever.
>>> The primary reason is that it breaks all the user's expectations. The
>>> secondary reason is that it won't always work! Heterogeneous containers=
 use
>>> std::less<>, not std::less<T>.
>>>
>>> If your type has operator<, then it should have the full complement of =
<
>>> <=3D =3D=3D >=3D > !=3D (which in C++2a means "it should have operator<=
=3D>").
>>> Orthogonally to that consideration, std::less<T>'s whole purpose is to
>>> expose the semantics of everybody's operator< in a consistent and
>>> functorish way.
>>> Your proposal has nothing to do with std::less, and therefore should no=
t
>>> touch it.
>>>
>>> If you really hate comparison operators for some reason, then the
>>> STL-favored thing to do is add a free function named *foo*_less with
>>> the semantics you want for your comparator, and force people to type ou=
t
>>>     using uuidset_t =3D std::set<std::uuid, std::foo_less>;
>>> Prior art: https://en.cppreference.com/w/cpp/memory/owner_less
>>> However, we can tell that this is probably a bad idea in your case by
>>> considering what is the appropriate name for "foo_less" in this case. I=
t's
>>> comparing uuids, and it's comparing them on the only thing it makes sen=
se
>>> to compare uuids on =E2=80=94 their values =E2=80=94 so the logical nam=
e for the free
>>> function is "uuid_less".
>>>     using uuidset_t =3D std::set<std::uuid, std::uuid_less>;
>>> But C++ has a better way to spell "uuid_less(const uuid&, const
>>> uuid&)"!  That spelling is very old-school-C.  The C++-ish spelling for
>>> "uuid_less" is...
>>>     bool operator<(const uuid&, const uuid&);
>>> This conveys the same information =E2=80=94 "compares uuids, for less-t=
han" =E2=80=94
>>> but it conveys it in a shorter and simpler way that also composes
>>> (semi)nicely with generic containers such as std::set and std::map.
>>>
>>>
>>> Alternatively, recognize that unordered_map/set are associative
>>>> containers that don't require an ordering.
>>>>
>>>
>>> I personally wouldn't mind if std::uuid, like std::byte, didn't have an=
y
>>> "less-than" operation at all, and if you wanted to compare them
>>> (binary-search an array of them, whatever) you had to cast them to stri=
ng
>>> or something. But that's because I wouldn't use std::uuid much. If I di=
d
>>> use it, I'd probably notice the lack and complain about it.
>>>
>>> (And I say this as someone who has often railed against the dangers of
>>> tuple::operator< and optional::operator<. Consistency is, etc.)
>>>
>>> =E2=80=93Arthur
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/
>>> isocpp.org/d/msgid/std-proposals/CADvuK0Jx%3DUAqczN0FVNu9DqxWrahjf8Wk-
>>> tELna_KCMCJOHPRg%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx=
%3DUAqczN0FVNu9DqxWrahjf8Wk-tELna_KCMCJOHPRg%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/
>> isocpp.org/d/msgid/std-proposals/CA%2BgtASxTLX6eQa%
>> 2BZTR4ay60q_FryMYUucGmw4UVxVW-PP4X8ZA%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASx=
TLX6eQa%2BZTR4ay60q_FryMYUucGmw4UVxVW-PP4X8ZA%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CALvx3hbL1k9qZynhba5sa49JnLSv1
> r4z7jVzWobECQjHEw8tLQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbL1k=
9qZynhba5sa49JnLSv1r4z7jVzWobECQjHEw8tLQ%40mail.gmail.com?utm_medium=3Demai=
l&utm_source=3Dfooter>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAANG%3DkUK%2BMfxCy_qvC6a84UnkSwxRQyo7Bhc3-DXJC6=
E8mHJNw%40mail.gmail.com.

--000000000000d2a67b05703e289e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">An ordering of UUIDs is very much important for implementi=
ng unique() and flatsets.<div><br></div><div>I would argue against inclusio=
n of any type that can meet Stepanov Regular (Regular + TotallyOrdered) but=
 does not.</div><div><br></div><div>G</div></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Thu, Jul 5, 2018 at 11:33 AM, Richard Ho=
dges <span dir=3D"ltr">&lt;<a href=3D"mailto:hodges.r@gmail.com" target=3D"=
_blank">hodges.r@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr">The discussion on operator&lt; is interesting.=C2=
=A0<div><br></div><div>I had a look at the wikipedia page for UUID and note=
 that there is a specific warning about using UUIDs as primary keys in orde=
red indexes.<div><br></div><div>This begs the question: when would ordering=
 be required for a UUID?=C2=A0</div><div><br></div><div><font face=3D"monos=
pace, monospace">Equality</font> and <font face=3D"monospace, monospace">st=
d::hash</font> I can completely understand, but a UUID itself encodes no in=
formation on relative order. It&#39;s salient property is merely universal =
uniqueness.</div><div><br></div><div>I would argue that the only operators =
that should be defined are:</div><div><br></div><div>binary <font face=3D"m=
onospace, monospace">operator=3D=3D</font> - test for equality</div><div>bi=
nary <font face=3D"monospace, monospace">operator!=3D</font> - test for ine=
quality</div><div>plus a specialisation of <font face=3D"monospace, monospa=
ce">std::hash</font></div><div><br></div><div>very much more arguably (i.e.=
 I would expect more argument over these):</div><div>operator bool - return=
s true iff the uuid is not null</div><div>unary ! - returns true if the uui=
d is a null uuid</div><div><br></div><div>In my view the following operator=
s make no sense:</div><div><div style=3D"text-decoration-style:initial;text=
-decoration-color:initial"><div style=3D"background-color:rgb(255,255,255);=
text-decoration-style:initial;text-decoration-color:initial">operator &lt;<=
/div><div style=3D"background-color:rgb(255,255,255);text-decoration-style:=
initial;text-decoration-color:initial">operator &lt;&lt; (other than to str=
eam to basic_ostream&lt;&gt;)</div>operator &gt;<br></div>operstor &gt;&gt;=
 (other than to deserialise from basic_istream&lt;&gt;)</div><div>operator=
=C2=A0+, -, /, *,=C2=A0<br class=3D"m_-4189907106551643113gmail-Apple-inter=
change-newline"><br></div><div>R<div><div class=3D"h5"><br><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Thu, 5 Jul 2018 at 07:37, Marius Banci=
la &lt;<a href=3D"mailto:marius.bancila@gmail.com" target=3D"_blank">marius=
..bancila@gmail.com</a>&gt; wrote:<br></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">I don&#39;t think specializing std::less for uuid is a good=
 idea. I prefer having operator &lt;, which, as said earlier, should actual=
ly be operator &lt;=3D&gt;.</div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr">On Tue, Jul 3, 2018 at 7:48 PM Arthur O&#39;Dwyer &lt;<a href=3D"mail=
to:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.com</=
a>&gt; wrote:<br></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">On T=
ue, Jul 3, 2018 at 9:21 AM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> w=
rote:<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On =
Fri, Jun 29, 2018 at 3:43 AM, Nicolas Lesser <span dir=3D"ltr">&lt;<a href=
=3D"mailto:blitzrakete@gmail.com" target=3D"_blank">blitzrakete@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-=
color:rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><span><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-style:solid;border-left-co=
lor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
Is there a reason why there are a member and non member functions for opera=
tor=3D=3D and operator&lt;?</blockquote><div><br></div><div>They are all no=
n-member.</div></div></blockquote></div></div><div dir=3D"auto"><br></div><=
/span><div dir=3D"auto">Whoops, didn&#39;t realize they were were friends.<=
/div><span><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex">I think it makes sense to =
use operator&lt;=3D&gt; instead of operator=3D=3D and operator!=3D (as an a=
dditional benefit, you can then use uuid as a non-type template parameter).=
</blockquote><div><br></div><div>My initial idea was to only be able to com=
pare uuid for equality. operator &lt; is necessary to be able to use uuids =
with associative containers. It does not really make sense to compare wheth=
er a uuid is less than another for any other reasons. Should we want to hav=
e all these comparison operators, then yes, it makes more sense to use the =
&lt;=3D&gt; operator.</div><div><br></div><div>constexpr auto operator &lt;=
=3D&gt;(uuid const &amp; lhs, uuid const &amp; rhs) noexcept;<br></div></di=
v></blockquote></div></div><div dir=3D"auto"><br></div></span><div dir=3D"a=
uto">Just because we don&#39;t want the others operators doesn&#39;t mean w=
e can&#39;t use the spaceship operator:</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">=C2=A0 =C2=A0 constexpr std::strong_equality operator&lt;=
=3D&gt;(uuid const&amp;, uuid const&amp;) noexcept =3D default;</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">The operator&lt; can always be prov=
ided as an extra overload.</div></div></blockquote><div><br></div>If we onl=
y want map/set interop, then define a std::less&lt;uuid&gt;, not operator&l=
t;.</div></div></div></blockquote><div><br></div><div>Please don&#39;t do t=
his.</div><div>You should never explicitly specialize std::less&lt;T&gt; fo=
r any type, ever.=C2=A0 The primary reason is that it breaks all the user&#=
39;s expectations. The secondary reason is that it won&#39;t always work! H=
eterogeneous containers use std::less&lt;&gt;, not std::less&lt;T&gt;.</div=
><div><br></div><div>If your type has operator&lt;, then it should have the=
 full complement of &lt; &lt;=3D =3D=3D &gt;=3D &gt; !=3D (which in C++2a m=
eans &quot;it should have operator&lt;=3D&gt;&quot;).</div><div>Orthogonall=
y to that consideration, std::less&lt;T&gt;&#39;s whole purpose is to expos=
e the semantics of everybody&#39;s operator&lt; in a consistent and functor=
ish way.</div><div>Your proposal has nothing to do with std::less, and ther=
efore should not touch it.</div><div><br></div><div>If you really hate comp=
arison operators for some reason, then the STL-favored thing to do is add a=
 free function named <i>foo</i>_less with the semantics you want for your c=
omparator, and force people to type out</div><div>=C2=A0 =C2=A0 using uuids=
et_t =3D std::set&lt;std::uuid, std::foo_less&gt;;</div><div>Prior art: <a =
href=3D"https://en.cppreference.com/w/cpp/memory/owner_less" target=3D"_bla=
nk">https://en.cppreference.com/w/<wbr>cpp/memory/owner_less</a><br></div><=
div>However, we can tell that this is probably a bad idea in your case by c=
onsidering what is the appropriate name for &quot;foo_less&quot; in this ca=
se. It&#39;s comparing uuids, and it&#39;s comparing them on the only thing=
 it makes sense to compare uuids on =E2=80=94 their values =E2=80=94 so the=
 logical name for the free function is &quot;uuid_less&quot;.</div><div><di=
v>=C2=A0 =C2=A0 using uuidset_t =3D std::set&lt;std::uuid, std::uuid_less&g=
t;;</div></div><div>But C++ has a better way to spell &quot;uuid_less(const=
 uuid&amp;, const uuid&amp;)&quot;!=C2=A0 That spelling is very old-school-=
C.=C2=A0 The C++-ish spelling for &quot;uuid_less&quot; is...</div><div>=C2=
=A0 =C2=A0 bool operator&lt;(const uuid&amp;, const uuid&amp;);</div><div>T=
his conveys the same information =E2=80=94 &quot;compares uuids, for less-t=
han&quot; =E2=80=94 but it conveys it in a shorter and simpler way that als=
o composes (semi)nicely with generic containers such as std::set and std::m=
ap.</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:sol=
id;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote"></div><div class=3D"gma=
il_quote">Alternatively, recognize that unordered_map/set are associative c=
ontainers that don&#39;t require an ordering.</div></div></div></blockquote=
><div><br></div><div>I personally wouldn&#39;t mind if std::uuid, like std:=
:byte, didn&#39;t have any &quot;less-than&quot; operation at all, and if y=
ou wanted to compare them (binary-search an array of them, whatever) you ha=
d to cast them to string or something. But that&#39;s because I wouldn&#39;=
t use std::uuid much. If I did use it, I&#39;d probably notice the lack and=
 complain about it.</div><div><br></div><div>(And I say this as someone who=
 has often railed against the dangers of tuple::operator&lt; and optional::=
operator&lt;. Consistency is, etc.)</div><div><br></div><div>=E2=80=93Arthu=
r</div></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx%3DUAqczN0FVNu9DqxWrahjf8Wk-=
tELna_KCMCJOHPRg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CADvuK0Jx%<wbr>3DUAqczN0FVNu9DqxWrahjf8Wk-<wbr>tELna_KCMCJ=
OHPRg%40mail.gmail.<wbr>com</a>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxTLX6eQa%2BZTR4ay60q_FryMYUu=
cGmw4UVxVW-PP4X8ZA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CA%2BgtASxTLX6eQa%<wbr>2BZTR4ay60q_FryMYUucGmw4UVxVW-<wb=
r>PP4X8ZA%40mail.gmail.com</a>.<br>
</blockquote></div></div></div></div></div></div><div><div class=3D"h5">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hbL1k9qZynhba5sa49JnLSv1r4z7jVz=
WobECQjHEw8tLQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CALvx3hbL1k9qZynhba5sa49JnLSv1<wbr>r4z7jVzWobECQjHEw8tL=
Q%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUK%2BMfxCy_qvC6a84UnkSwxRQyo=
7Bhc3-DXJC6E8mHJNw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUK%2=
BMfxCy_qvC6a84UnkSwxRQyo7Bhc3-DXJC6E8mHJNw%40mail.gmail.com</a>.<br />

--000000000000d2a67b05703e289e--

.

--0000000000004a5e6f05703fa15d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes, most of the online advertising industry uses UUIDs extensively
(serialisation and lookups)
They really need to be as usable as normal types.
I don't think an anecdote on Wikipedia is sufficient reason to not include
these operators.

On Thu, Jul 5, 2018 at 11:38 AM, Ga=C5=A1per A=C5=BEman <gasper.azman@gmail=
..com>
wrote:

> An ordering of UUIDs is very much important for implementing unique() and
> flatsets.
>
> I would argue against inclusion of any type that can meet Stepanov Regula=
r
> (Regular + TotallyOrdered) but does not.
>
> G
>
> On Thu, Jul 5, 2018 at 11:33 AM, Richard Hodges <hodges.r@gmail.com>
> wrote:
>
>> The discussion on operator< is interesting.
>>
>> I had a look at the wikipedia page for UUID and note that there is a
>> specific warning about using UUIDs as primary keys in ordered indexes.
>>
>> This begs the question: when would ordering be required for a UUID?
>>
>> Equality and std::hash I can completely understand, but a UUID itself
>> encodes no information on relative order. It's salient property is merel=
y
>> universal uniqueness.
>>
>> I would argue that the only operators that should be defined are:
>>
>> binary operator=3D=3D - test for equality
>> binary operator!=3D - test for inequality
>> plus a specialisation of std::hash
>>
>> very much more arguably (i.e. I would expect more argument over these):
>> operator bool - returns true iff the uuid is not null
>> unary ! - returns true if the uuid is a null uuid
>>
>> In my view the following operators make no sense:
>> operator <
>> operator << (other than to stream to basic_ostream<>)
>> operator >
>> operstor >> (other than to deserialise from basic_istream<>)
>> operator +, -, /, *,
>>
>> R
>>
>>
>> On Thu, 5 Jul 2018 at 07:37, Marius Bancila <marius.bancila@gmail.com>
>> wrote:
>>
>>> I don't think specializing std::less for uuid is a good idea. I prefer
>>> having operator <, which, as said earlier, should actually be operator =
<=3D>.
>>>
>>> On Tue, Jul 3, 2018 at 7:48 PM Arthur O'Dwyer <arthur.j.odwyer@gmail.co=
m>
>>> wrote:
>>>
>>>> On Tue, Jul 3, 2018 at 9:21 AM, Tony V E <tvaneerd@gmail.com> wrote:
>>>>
>>>>> On Fri, Jun 29, 2018 at 3:43 AM, Nicolas Lesser <blitzrakete@gmail.co=
m
>>>>> > wrote:
>>>>>
>>>>>> Is there a reason why there are a member and non member functions fo=
r
>>>>>>>> operator=3D=3D and operator<?
>>>>>>>
>>>>>>>
>>>>>>> They are all non-member.
>>>>>>>
>>>>>>
>>>>>> Whoops, didn't realize they were were friends.
>>>>>>
>>>>>>>
>>>>>>> I think it makes sense to use operator<=3D> instead of operator=3D=
=3D and
>>>>>>>> operator!=3D (as an additional benefit, you can then use uuid as a=
 non-type
>>>>>>>> template parameter).
>>>>>>>
>>>>>>>
>>>>>>> My initial idea was to only be able to compare uuid for equality.
>>>>>>> operator < is necessary to be able to use uuids with associative
>>>>>>> containers. It does not really make sense to compare whether a uuid=
 is less
>>>>>>> than another for any other reasons. Should we want to have all thes=
e
>>>>>>> comparison operators, then yes, it makes more sense to use the <=3D=
> operator.
>>>>>>>
>>>>>>> constexpr auto operator <=3D>(uuid const & lhs, uuid const & rhs)
>>>>>>> noexcept;
>>>>>>>
>>>>>>
>>>>>> Just because we don't want the others operators doesn't mean we can'=
t
>>>>>> use the spaceship operator:
>>>>>>
>>>>>>     constexpr std::strong_equality operator<=3D>(uuid const&, uuid
>>>>>> const&) noexcept =3D default;
>>>>>>
>>>>>> The operator< can always be provided as an extra overload.
>>>>>>
>>>>>
>>>>> If we only want map/set interop, then define a std::less<uuid>, not
>>>>> operator<.
>>>>>
>>>>
>>>> Please don't do this.
>>>> You should never explicitly specialize std::less<T> for any type,
>>>> ever.  The primary reason is that it breaks all the user's expectation=
s.
>>>> The secondary reason is that it won't always work! Heterogeneous conta=
iners
>>>> use std::less<>, not std::less<T>.
>>>>
>>>> If your type has operator<, then it should have the full complement of
>>>> < <=3D =3D=3D >=3D > !=3D (which in C++2a means "it should have operat=
or<=3D>").
>>>> Orthogonally to that consideration, std::less<T>'s whole purpose is to
>>>> expose the semantics of everybody's operator< in a consistent and
>>>> functorish way.
>>>> Your proposal has nothing to do with std::less, and therefore should
>>>> not touch it.
>>>>
>>>> If you really hate comparison operators for some reason, then the
>>>> STL-favored thing to do is add a free function named *foo*_less with
>>>> the semantics you want for your comparator, and force people to type o=
ut
>>>>     using uuidset_t =3D std::set<std::uuid, std::foo_less>;
>>>> Prior art: https://en.cppreference.com/w/cpp/memory/owner_less
>>>> However, we can tell that this is probably a bad idea in your case by
>>>> considering what is the appropriate name for "foo_less" in this case. =
It's
>>>> comparing uuids, and it's comparing them on the only thing it makes se=
nse
>>>> to compare uuids on =E2=80=94 their values =E2=80=94 so the logical na=
me for the free
>>>> function is "uuid_less".
>>>>     using uuidset_t =3D std::set<std::uuid, std::uuid_less>;
>>>> But C++ has a better way to spell "uuid_less(const uuid&, const
>>>> uuid&)"!  That spelling is very old-school-C.  The C++-ish spelling fo=
r
>>>> "uuid_less" is...
>>>>     bool operator<(const uuid&, const uuid&);
>>>> This conveys the same information =E2=80=94 "compares uuids, for less-=
than" =E2=80=94
>>>> but it conveys it in a shorter and simpler way that also composes
>>>> (semi)nicely with generic containers such as std::set and std::map.
>>>>
>>>>
>>>> Alternatively, recognize that unordered_map/set are associative
>>>>> containers that don't require an ordering.
>>>>>
>>>>
>>>> I personally wouldn't mind if std::uuid, like std::byte, didn't have
>>>> any "less-than" operation at all, and if you wanted to compare them
>>>> (binary-search an array of them, whatever) you had to cast them to str=
ing
>>>> or something. But that's because I wouldn't use std::uuid much. If I d=
id
>>>> use it, I'd probably notice the lack and complain about it.
>>>>
>>>> (And I say this as someone who has often railed against the dangers of
>>>> tuple::operator< and optional::operator<. Consistency is, etc.)
>>>>
>>>> =E2=80=93Arthur
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to std-proposals+unsubscribe@isocpp.org.
>>>> To post to this group, send email to std-proposals@isocpp.org.
>>>> To view this discussion on the web visit https://groups.google.com/a/i=
s
>>>> ocpp.org/d/msgid/std-proposals/CADvuK0Jx%3DUAqczN0FVNu9DqxWr
>>>> ahjf8Wk-tELna_KCMCJOHPRg%40mail.gmail.com
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0J=
x%3DUAqczN0FVNu9DqxWrahjf8Wk-tELna_KCMCJOHPRg%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>>>> .
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/CA%2BgtASxTLX6eQa%2BZTR4ay60q
>>> _FryMYUucGmw4UVxVW-PP4X8ZA%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtAS=
xTLX6eQa%2BZTR4ay60q_FryMYUucGmw4UVxVW-PP4X8ZA%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/CALvx3hbL1k9qZynhba5sa49JnLSv
>> 1r4z7jVzWobECQjHEw8tLQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbL1=
k9qZynhba5sa49JnLSv1r4z7jVzWobECQjHEw8tLQ%40mail.gmail.com?utm_medium=3Dema=
il&utm_source=3Dfooter>
>> .
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAANG%3DkUK%2BMfxCy_
> qvC6a84UnkSwxRQyo7Bhc3-DXJC6E8mHJNw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUK=
%2BMfxCy_qvC6a84UnkSwxRQyo7Bhc3-DXJC6E8mHJNw%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFQaeCDGO%2BX0AdFO7UjyN2K5OzoSmfNa_du9kyNdzA_gT=
eSXcg%40mail.gmail.com.

--0000000000004a5e6f05703fa15d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Yes, most of the online advertising industry uses UUI=
Ds extensively (serialisation and lookups)</div><div>They really need to be=
 as usable as normal types.</div><div>I don&#39;t think an anecdote on Wiki=
pedia is sufficient reason to not include these operators.</div></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Jul 5, 2018 at=
 11:38 AM, Ga=C5=A1per A=C5=BEman <span dir=3D"ltr">&lt;<a href=3D"mailto:g=
asper.azman@gmail.com" target=3D"_blank">gasper.azman@gmail.com</a>&gt;</sp=
an> 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">An ordering o=
f UUIDs is very much important for implementing unique() and flatsets.<div>=
<br></div><div>I would argue against inclusion of any type that can meet St=
epanov Regular (Regular + TotallyOrdered) but does not.</div><div><br></div=
><div>G</div></div><div><div class=3D"h5"><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">On Thu, Jul 5, 2018 at 11:33 AM, Richard Hodges <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank"=
>hodges.r@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">The discussion on operator&lt; is interesting.=C2=A0<div>=
<br></div><div>I had a look at the wikipedia page for UUID and note that th=
ere is a specific warning about using UUIDs as primary keys in ordered inde=
xes.<div><br></div><div>This begs the question: when would ordering be requ=
ired for a UUID?=C2=A0</div><div><br></div><div><font face=3D"monospace, mo=
nospace">Equality</font> and <font face=3D"monospace, monospace">std::hash<=
/font> I can completely understand, but a UUID itself encodes no informatio=
n on relative order. It&#39;s salient property is merely universal uniquene=
ss.</div><div><br></div><div>I would argue that the only operators that sho=
uld be defined are:</div><div><br></div><div>binary <font face=3D"monospace=
, monospace">operator=3D=3D</font> - test for equality</div><div>binary <fo=
nt face=3D"monospace, monospace">operator!=3D</font> - test for inequality<=
/div><div>plus a specialisation of <font face=3D"monospace, monospace">std:=
:hash</font></div><div><br></div><div>very much more arguably (i.e. I would=
 expect more argument over these):</div><div>operator bool - returns true i=
ff the uuid is not null</div><div>unary ! - returns true if the uuid is a n=
ull uuid</div><div><br></div><div>In my view the following operators make n=
o sense:</div><div><div style=3D"text-decoration-style:initial;text-decorat=
ion-color:initial"><div style=3D"background-color:rgb(255,255,255);text-dec=
oration-style:initial;text-decoration-color:initial">operator &lt;</div><di=
v style=3D"background-color:rgb(255,255,255);text-decoration-style:initial;=
text-decoration-color:initial">operator &lt;&lt; (other than to stream to b=
asic_ostream&lt;&gt;)</div>operator &gt;<br></div>operstor &gt;&gt; (other =
than to deserialise from basic_istream&lt;&gt;)</div><div>operator=C2=A0+, =
-, /, *,=C2=A0<br class=3D"m_208603698751498456m_-4189907106551643113gmail-=
Apple-interchange-newline"><br></div><div>R<div><div class=3D"m_20860369875=
1498456h5"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, 5 Ju=
l 2018 at 07:37, Marius Bancila &lt;<a href=3D"mailto:marius.bancila@gmail.=
com" target=3D"_blank">marius.bancila@gmail.com</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">I don&#39;t think specializing=
 std::less for uuid is a good idea. I prefer having operator &lt;, which, a=
s said earlier, should actually be operator &lt;=3D&gt;.</div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jul 3, 2018 at 7:48 PM Arthur O&=
#39;Dwyer &lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank=
">arthur.j.odwyer@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr">On Tue, Jul 3, 2018 at 9:21 AM, Tony V E <span dir=
=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvanee=
rd@gmail.com</a>&gt;</span> wrote:<div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote">On Fri, Jun 29, 2018 at 3:43 AM, Nicolas Lesser <=
span dir=3D"ltr">&lt;<a href=3D"mailto:blitzrakete@gmail.com" target=3D"_bl=
ank">blitzrakete@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"auto"><span><div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex">Is there a reason why there are a member and non =
member functions for operator=3D=3D and operator&lt;?</blockquote><div><br>=
</div><div>They are all non-member.</div></div></blockquote></div></div><di=
v dir=3D"auto"><br></div></span><div dir=3D"auto">Whoops, didn&#39;t realiz=
e they were were friends.</div><span><div dir=3D"auto"><div class=3D"gmail_=
quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr"><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
I think it makes sense to use operator&lt;=3D&gt; instead of operator=3D=3D=
 and operator!=3D (as an additional benefit, you can then use uuid as a non=
-type template parameter).</blockquote><div><br></div><div>My initial idea =
was to only be able to compare uuid for equality. operator &lt; is necessar=
y to be able to use uuids with associative containers. It does not really m=
ake sense to compare whether a uuid is less than another for any other reas=
ons. Should we want to have all these comparison operators, then yes, it ma=
kes more sense to use the &lt;=3D&gt; operator.</div><div><br></div><div>co=
nstexpr auto operator &lt;=3D&gt;(uuid const &amp; lhs, uuid const &amp; rh=
s) noexcept;<br></div></div></blockquote></div></div><div dir=3D"auto"><br>=
</div></span><div dir=3D"auto">Just because we don&#39;t want the others op=
erators doesn&#39;t mean we can&#39;t use the spaceship operator:</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">=C2=A0 =C2=A0 constexpr std::stro=
ng_equality operator&lt;=3D&gt;(uuid const&amp;, uuid const&amp;) noexcept =
=3D default;</div><div dir=3D"auto"><br></div><div dir=3D"auto">The operato=
r&lt; can always be provided as an extra overload.</div></div></blockquote>=
<div><br></div>If we only want map/set interop, then define a std::less&lt;=
uuid&gt;, not operator&lt;.</div></div></div></blockquote><div><br></div><d=
iv>Please don&#39;t do this.</div><div>You should never explicitly speciali=
ze std::less&lt;T&gt; for any type, ever.=C2=A0 The primary reason is that =
it breaks all the user&#39;s expectations. The secondary reason is that it =
won&#39;t always work! Heterogeneous containers use std::less&lt;&gt;, not =
std::less&lt;T&gt;.</div><div><br></div><div>If your type has operator&lt;,=
 then it should have the full complement of &lt; &lt;=3D =3D=3D &gt;=3D &gt=
; !=3D (which in C++2a means &quot;it should have operator&lt;=3D&gt;&quot;=
).</div><div>Orthogonally to that consideration, std::less&lt;T&gt;&#39;s w=
hole purpose is to expose the semantics of everybody&#39;s operator&lt; in =
a consistent and functorish way.</div><div>Your proposal has nothing to do =
with std::less, and therefore should not touch it.</div><div><br></div><div=
>If you really hate comparison operators for some reason, then the STL-favo=
red thing to do is add a free function named <i>foo</i>_less with the seman=
tics you want for your comparator, and force people to type out</div><div>=
=C2=A0 =C2=A0 using uuidset_t =3D std::set&lt;std::uuid, std::foo_less&gt;;=
</div><div>Prior art: <a href=3D"https://en.cppreference.com/w/cpp/memory/o=
wner_less" target=3D"_blank">https://en.cppreference.com/w/<wbr>cpp/memory/=
owner_less</a><br></div><div>However, we can tell that this is probably a b=
ad idea in your case by considering what is the appropriate name for &quot;=
foo_less&quot; in this case. It&#39;s comparing uuids, and it&#39;s compari=
ng them on the only thing it makes sense to compare uuids on =E2=80=94 thei=
r values =E2=80=94 so the logical name for the free function is &quot;uuid_=
less&quot;.</div><div><div>=C2=A0 =C2=A0 using uuidset_t =3D std::set&lt;st=
d::uuid, std::uuid_less&gt;;</div></div><div>But C++ has a better way to sp=
ell &quot;uuid_less(const uuid&amp;, const uuid&amp;)&quot;!=C2=A0 That spe=
lling is very old-school-C.=C2=A0 The C++-ish spelling for &quot;uuid_less&=
quot; is...</div><div>=C2=A0 =C2=A0 bool operator&lt;(const uuid&amp;, cons=
t uuid&amp;);</div><div>This conveys the same information =E2=80=94 &quot;c=
ompares uuids, for less-than&quot; =E2=80=94 but it conveys it in a shorter=
 and simpler way that also composes (semi)nicely with generic containers su=
ch as std::set and std::map.</div><div><br></div><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"></div><div class=3D"gmail_quote">Alternatively, recognize that unordered_=
map/set are associative containers that don&#39;t require an ordering.</div=
></div></div></blockquote><div><br></div><div>I personally wouldn&#39;t min=
d if std::uuid, like std::byte, didn&#39;t have any &quot;less-than&quot; o=
peration at all, and if you wanted to compare them (binary-search an array =
of them, whatever) you had to cast them to string or something. But that&#3=
9;s because I wouldn&#39;t use std::uuid much. If I did use it, I&#39;d pro=
bably notice the lack and complain about it.</div><div><br></div><div>(And =
I say this as someone who has often railed against the dangers of tuple::op=
erator&lt; and optional::operator&lt;. Consistency is, etc.)</div><div><br>=
</div><div>=E2=80=93Arthur</div></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx%3DUAqczN0FVNu9DqxWrahjf8Wk-=
tELna_KCMCJOHPRg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/st=
d-proposals<wbr>/CADvuK0Jx%3DUAqczN0FVNu9DqxWr<wbr>ahjf8Wk-tELna_KCMCJOHPRg=
%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxTLX6eQa%2BZTR4ay60q_FryMYUu=
cGmw4UVxVW-PP4X8ZA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/=
std-proposals<wbr>/CA%2BgtASxTLX6eQa%2BZTR4ay60q<wbr>_FryMYUucGmw4UVxVW-PP4=
X8ZA%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div></div></div></div></div></div><div><div class=3D"m_20860=
3698751498456h5">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isoc<wbr>pp.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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hbL1k9qZynhba5sa49JnLSv1r4z7jVz=
WobECQjHEw8tLQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-=
proposals<wbr>/CALvx3hbL1k9qZynhba5sa49JnLSv<wbr>1r4z7jVzWobECQjHEw8tLQ%40m=
ail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUK%2BMfxCy_qvC6a84UnkSwxRQyo=
7Bhc3-DXJC6E8mHJNw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CAANG%3DkUK%2BMfxCy_<wbr>qvC6a84UnkSwxRQyo7Bhc3-<wbr>DXJ=
C6E8mHJNw%40mail.gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFQaeCDGO%2BX0AdFO7UjyN2K5OzoSmfNa_d=
u9kyNdzA_gTeSXcg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCDGO%2BX0=
AdFO7UjyN2K5OzoSmfNa_du9kyNdzA_gTeSXcg%40mail.gmail.com</a>.<br />

--0000000000004a5e6f05703fa15d--

.

--0000000000002d6c42057041b2c6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 5 Jul 2018 at 12:39, Ga=C5=A1per A=C5=BEman <gasper.azman@gmail.com=
> wrote:

> An ordering of UUIDs is very much important for implementing unique() and
> flatsets.
>

I understand. There is nothing to prevent a library user from defining
their own meaning of "UUID order" through a custom Compare function, which
is free to interpret the UUID's data any way it wishes.


>
> I would argue against inclusion of any type that can meet Stepanov Regula=
r
> (Regular + TotallyOrdered) but does not.
>

What I am saying is that there is no standardised concept of "order" when
it comes to UUIDs. It's simply not a universally valid concept.

Therefore to build one into a library seems like an error to me.


>
> G
>
> On Thu, Jul 5, 2018 at 11:33 AM, Richard Hodges <hodges.r@gmail.com>
> wrote:
>
>> The discussion on operator< is interesting.
>>
>> I had a look at the wikipedia page for UUID and note that there is a
>> specific warning about using UUIDs as primary keys in ordered indexes.
>>
>> This begs the question: when would ordering be required for a UUID?
>>
>> Equality and std::hash I can completely understand, but a UUID itself
>> encodes no information on relative order. It's salient property is merel=
y
>> universal uniqueness.
>>
>> I would argue that the only operators that should be defined are:
>>
>> binary operator=3D=3D - test for equality
>> binary operator!=3D - test for inequality
>> plus a specialisation of std::hash
>>
>> very much more arguably (i.e. I would expect more argument over these):
>> operator bool - returns true iff the uuid is not null
>> unary ! - returns true if the uuid is a null uuid
>>
>> In my view the following operators make no sense:
>> operator <
>> operator << (other than to stream to basic_ostream<>)
>> operator >
>> operstor >> (other than to deserialise from basic_istream<>)
>> operator +, -, /, *,
>>
>> R
>>
>>
>> On Thu, 5 Jul 2018 at 07:37, Marius Bancila <marius.bancila@gmail.com>
>> wrote:
>>
>>> I don't think specializing std::less for uuid is a good idea. I prefer
>>> having operator <, which, as said earlier, should actually be operator =
<=3D>.
>>>
>>> On Tue, Jul 3, 2018 at 7:48 PM Arthur O'Dwyer <arthur.j.odwyer@gmail.co=
m>
>>> wrote:
>>>
>>>> On Tue, Jul 3, 2018 at 9:21 AM, Tony V E <tvaneerd@gmail.com> wrote:
>>>>
>>>>> On Fri, Jun 29, 2018 at 3:43 AM, Nicolas Lesser <blitzrakete@gmail.co=
m
>>>>> > wrote:
>>>>>
>>>>>> Is there a reason why there are a member and non member functions fo=
r
>>>>>>>> operator=3D=3D and operator<?
>>>>>>>
>>>>>>>
>>>>>>> They are all non-member.
>>>>>>>
>>>>>>
>>>>>> Whoops, didn't realize they were were friends.
>>>>>>
>>>>>>>
>>>>>>> I think it makes sense to use operator<=3D> instead of operator=3D=
=3D and
>>>>>>>> operator!=3D (as an additional benefit, you can then use uuid as a=
 non-type
>>>>>>>> template parameter).
>>>>>>>
>>>>>>>
>>>>>>> My initial idea was to only be able to compare uuid for equality.
>>>>>>> operator < is necessary to be able to use uuids with associative
>>>>>>> containers. It does not really make sense to compare whether a uuid=
 is less
>>>>>>> than another for any other reasons. Should we want to have all thes=
e
>>>>>>> comparison operators, then yes, it makes more sense to use the <=3D=
> operator.
>>>>>>>
>>>>>>> constexpr auto operator <=3D>(uuid const & lhs, uuid const & rhs)
>>>>>>> noexcept;
>>>>>>>
>>>>>>
>>>>>> Just because we don't want the others operators doesn't mean we can'=
t
>>>>>> use the spaceship operator:
>>>>>>
>>>>>>     constexpr std::strong_equality operator<=3D>(uuid const&, uuid
>>>>>> const&) noexcept =3D default;
>>>>>>
>>>>>> The operator< can always be provided as an extra overload.
>>>>>>
>>>>>
>>>>> If we only want map/set interop, then define a std::less<uuid>, not
>>>>> operator<.
>>>>>
>>>>
>>>> Please don't do this.
>>>> You should never explicitly specialize std::less<T> for any type,
>>>> ever.  The primary reason is that it breaks all the user's expectation=
s.
>>>> The secondary reason is that it won't always work! Heterogeneous conta=
iners
>>>> use std::less<>, not std::less<T>.
>>>>
>>>> If your type has operator<, then it should have the full complement of
>>>> < <=3D =3D=3D >=3D > !=3D (which in C++2a means "it should have operat=
or<=3D>").
>>>> Orthogonally to that consideration, std::less<T>'s whole purpose is to
>>>> expose the semantics of everybody's operator< in a consistent and
>>>> functorish way.
>>>> Your proposal has nothing to do with std::less, and therefore should
>>>> not touch it.
>>>>
>>>> If you really hate comparison operators for some reason, then the
>>>> STL-favored thing to do is add a free function named *foo*_less with
>>>> the semantics you want for your comparator, and force people to type o=
ut
>>>>     using uuidset_t =3D std::set<std::uuid, std::foo_less>;
>>>> Prior art: https://en.cppreference.com/w/cpp/memory/owner_less
>>>> However, we can tell that this is probably a bad idea in your case by
>>>> considering what is the appropriate name for "foo_less" in this case. =
It's
>>>> comparing uuids, and it's comparing them on the only thing it makes se=
nse
>>>> to compare uuids on =E2=80=94 their values =E2=80=94 so the logical na=
me for the free
>>>> function is "uuid_less".
>>>>     using uuidset_t =3D std::set<std::uuid, std::uuid_less>;
>>>> But C++ has a better way to spell "uuid_less(const uuid&, const
>>>> uuid&)"!  That spelling is very old-school-C.  The C++-ish spelling fo=
r
>>>> "uuid_less" is...
>>>>     bool operator<(const uuid&, const uuid&);
>>>> This conveys the same information =E2=80=94 "compares uuids, for less-=
than" =E2=80=94
>>>> but it conveys it in a shorter and simpler way that also composes
>>>> (semi)nicely with generic containers such as std::set and std::map.
>>>>
>>>>
>>>> Alternatively, recognize that unordered_map/set are associative
>>>>> containers that don't require an ordering.
>>>>>
>>>>
>>>> I personally wouldn't mind if std::uuid, like std::byte, didn't have
>>>> any "less-than" operation at all, and if you wanted to compare them
>>>> (binary-search an array of them, whatever) you had to cast them to str=
ing
>>>> or something. But that's because I wouldn't use std::uuid much. If I d=
id
>>>> use it, I'd probably notice the lack and complain about it.
>>>>
>>>> (And I say this as someone who has often railed against the dangers of
>>>> tuple::operator< and optional::operator<. Consistency is, etc.)
>>>>
>>>> =E2=80=93Arthur
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to std-proposals+unsubscribe@isocpp.org.
>>>> To post to this group, send email to std-proposals@isocpp.org.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx=
%3DUAqczN0FVNu9DqxWrahjf8Wk-tELna_KCMCJOHPRg%40mail.gmail.com
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0J=
x%3DUAqczN0FVNu9DqxWrahjf8Wk-tELna_KCMCJOHPRg%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>>>> .
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASx=
TLX6eQa%2BZTR4ay60q_FryMYUucGmw4UVxVW-PP4X8ZA%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtAS=
xTLX6eQa%2BZTR4ay60q_FryMYUucGmw4UVxVW-PP4X8ZA%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbL1k=
9qZynhba5sa49JnLSv1r4z7jVzWobECQjHEw8tLQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbL1=
k9qZynhba5sa49JnLSv1r4z7jVzWobECQjHEw8tLQ%40mail.gmail.com?utm_medium=3Dema=
il&utm_source=3Dfooter>
>> .
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUK%=
2BMfxCy_qvC6a84UnkSwxRQyo7Bhc3-DXJC6E8mHJNw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUK=
%2BMfxCy_qvC6a84UnkSwxRQyo7Bhc3-DXJC6E8mHJNw%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CALvx3hb%3DCPtRg51GRM8pCnTh%2BsJb8-xyMOBRTamW6Fp=
P2fOkBg%40mail.gmail.com.

--0000000000002d6c42057041b2c6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu=
, 5 Jul 2018 at 12:39, Ga=C5=A1per A=C5=BEman &lt;<a href=3D"mailto:gasper.=
azman@gmail.com">gasper.azman@gmail.com</a>&gt; wrote:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr">An ordering of UUIDs is very much impo=
rtant for implementing unique() and flatsets.</div></blockquote><div><br></=
div><div>I understand. There is nothing to prevent a library user from defi=
ning their own meaning of &quot;UUID order&quot; through a custom <font fac=
e=3D"monospace, monospace">Compare</font> function, which is free to interp=
ret the UUID&#39;s data any way it wishes.</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><br></div><div>I would argue aga=
inst inclusion of any type that can meet Stepanov Regular (Regular + Totall=
yOrdered) but does not.</div></div></blockquote><div><br></div><div>What I =
am saying is that there is no standardised concept of &quot;order&quot; whe=
n it comes to UUIDs. It&#39;s simply not a universally valid concept.=C2=A0=
</div><div><br></div><div>Therefore to build one into a library seems like =
an error to me.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><br></div><div>G</div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Thu, Jul 5, 2018 at 11:33 AM, Richard Hod=
ges <span dir=3D"ltr">&lt;<a href=3D"mailto:hodges.r@gmail.com" target=3D"_=
blank">hodges.r@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">The discussion on operator&lt; is interesting.=C2=
=A0<div><br></div><div>I had a look at the wikipedia page for UUID and note=
 that there is a specific warning about using UUIDs as primary keys in orde=
red indexes.<div><br></div><div>This begs the question: when would ordering=
 be required for a UUID?=C2=A0</div><div><br></div><div><font face=3D"monos=
pace, monospace">Equality</font> and <font face=3D"monospace, monospace">st=
d::hash</font> I can completely understand, but a UUID itself encodes no in=
formation on relative order. It&#39;s salient property is merely universal =
uniqueness.</div><div><br></div><div>I would argue that the only operators =
that should be defined are:</div><div><br></div><div>binary <font face=3D"m=
onospace, monospace">operator=3D=3D</font> - test for equality</div><div>bi=
nary <font face=3D"monospace, monospace">operator!=3D</font> - test for ine=
quality</div><div>plus a specialisation of <font face=3D"monospace, monospa=
ce">std::hash</font></div><div><br></div><div>very much more arguably (i.e.=
 I would expect more argument over these):</div><div>operator bool - return=
s true iff the uuid is not null</div><div>unary ! - returns true if the uui=
d is a null uuid</div><div><br></div><div>In my view the following operator=
s make no sense:</div><div><div style=3D"text-decoration-style:initial;text=
-decoration-color:initial"><div style=3D"background-color:rgb(255,255,255);=
text-decoration-style:initial;text-decoration-color:initial">operator &lt;<=
/div><div style=3D"background-color:rgb(255,255,255);text-decoration-style:=
initial;text-decoration-color:initial">operator &lt;&lt; (other than to str=
eam to basic_ostream&lt;&gt;)</div>operator &gt;<br></div>operstor &gt;&gt;=
 (other than to deserialise from basic_istream&lt;&gt;)</div><div>operator=
=C2=A0+, -, /, *,=C2=A0<br class=3D"m_338502166779053512m_-4189907106551643=
113gmail-Apple-interchange-newline"><br></div><div>R<div><div class=3D"m_33=
8502166779053512h5"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On =
Thu, 5 Jul 2018 at 07:37, Marius Bancila &lt;<a href=3D"mailto:marius.banci=
la@gmail.com" target=3D"_blank">marius.bancila@gmail.com</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I don&#39;t think spe=
cializing std::less for uuid is a good idea. I prefer having operator &lt;,=
 which, as said earlier, should actually be operator &lt;=3D&gt;.</div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jul 3, 2018 at 7:48 PM =
Arthur O&#39;Dwyer &lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=
=3D"_blank">arthur.j.odwyer@gmail.com</a>&gt; wrote:<br></div><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">On Tue, Jul 3, 2018 at 9:21 AM, Tony V E=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_bla=
nk">tvaneerd@gmail.com</a>&gt;</span> wrote:<div class=3D"gmail_extra"><div=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-c=
olor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote">On Fri, Jun 29, 2018 at 3:43 AM, Nicola=
s Lesser <span dir=3D"ltr">&lt;<a href=3D"mailto:blitzrakete@gmail.com" tar=
get=3D"_blank">blitzrakete@gmail.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1=
ex"><div dir=3D"auto"><span><div><div class=3D"gmail_quote"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color=
:rgb(204,204,204);padding-left:1ex">Is there a reason why there are a membe=
r and non member functions for operator=3D=3D and operator&lt;?</blockquote=
><div><br></div><div>They are all non-member.</div></div></blockquote></div=
></div><div dir=3D"auto"><br></div></span><div dir=3D"auto">Whoops, didn&#3=
9;t realize they were were friends.</div><span><div dir=3D"auto"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-le=
ft:1ex">I think it makes sense to use operator&lt;=3D&gt; instead of operat=
or=3D=3D and operator!=3D (as an additional benefit, you can then use uuid =
as a non-type template parameter).</blockquote><div><br></div><div>My initi=
al idea was to only be able to compare uuid for equality. operator &lt; is =
necessary to be able to use uuids with associative containers. It does not =
really make sense to compare whether a uuid is less than another for any ot=
her reasons. Should we want to have all these comparison operators, then ye=
s, it makes more sense to use the &lt;=3D&gt; operator.</div><div><br></div=
><div>constexpr auto operator &lt;=3D&gt;(uuid const &amp; lhs, uuid const =
&amp; rhs) noexcept;<br></div></div></blockquote></div></div><div dir=3D"au=
to"><br></div></span><div dir=3D"auto">Just because we don&#39;t want the o=
thers operators doesn&#39;t mean we can&#39;t use the spaceship operator:</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">=C2=A0 =C2=A0 constexpr s=
td::strong_equality operator&lt;=3D&gt;(uuid const&amp;, uuid const&amp;) n=
oexcept =3D default;</div><div dir=3D"auto"><br></div><div dir=3D"auto">The=
 operator&lt; can always be provided as an extra overload.</div></div></blo=
ckquote><div><br></div>If we only want map/set interop, then define a std::=
less&lt;uuid&gt;, not operator&lt;.</div></div></div></blockquote><div><br>=
</div><div>Please don&#39;t do this.</div><div>You should never explicitly =
specialize std::less&lt;T&gt; for any type, ever.=C2=A0 The primary reason =
is that it breaks all the user&#39;s expectations. The secondary reason is =
that it won&#39;t always work! Heterogeneous containers use std::less&lt;&g=
t;, not std::less&lt;T&gt;.</div><div><br></div><div>If your type has opera=
tor&lt;, then it should have the full complement of &lt; &lt;=3D =3D=3D &gt=
;=3D &gt; !=3D (which in C++2a means &quot;it should have operator&lt;=3D&g=
t;&quot;).</div><div>Orthogonally to that consideration, std::less&lt;T&gt;=
&#39;s whole purpose is to expose the semantics of everybody&#39;s operator=
&lt; in a consistent and functorish way.</div><div>Your proposal has nothin=
g to do with std::less, and therefore should not touch it.</div><div><br></=
div><div>If you really hate comparison operators for some reason, then the =
STL-favored thing to do is add a free function named <i>foo</i>_less with t=
he semantics you want for your comparator, and force people to type out</di=
v><div>=C2=A0 =C2=A0 using uuidset_t =3D std::set&lt;std::uuid, std::foo_le=
ss&gt;;</div><div>Prior art: <a href=3D"https://en.cppreference.com/w/cpp/m=
emory/owner_less" target=3D"_blank">https://en.cppreference.com/w/cpp/memor=
y/owner_less</a><br></div><div>However, we can tell that this is probably a=
 bad idea in your case by considering what is the appropriate name for &quo=
t;foo_less&quot; in this case. It&#39;s comparing uuids, and it&#39;s compa=
ring them on the only thing it makes sense to compare uuids on =E2=80=94 th=
eir values =E2=80=94 so the logical name for the free function is &quot;uui=
d_less&quot;.</div><div><div>=C2=A0 =C2=A0 using uuidset_t =3D std::set&lt;=
std::uuid, std::uuid_less&gt;;</div></div><div>But C++ has a better way to =
spell &quot;uuid_less(const uuid&amp;, const uuid&amp;)&quot;!=C2=A0 That s=
pelling is very old-school-C.=C2=A0 The C++-ish spelling for &quot;uuid_les=
s&quot; is...</div><div>=C2=A0 =C2=A0 bool operator&lt;(const uuid&amp;, co=
nst uuid&amp;);</div><div>This conveys the same information =E2=80=94 &quot=
;compares uuids, for less-than&quot; =E2=80=94 but it conveys it in a short=
er and simpler way that also composes (semi)nicely with generic containers =
such as std::set and std::map.</div><div><br></div><div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"></div><div class=3D"gmail_quote">Alternatively, recognize that unordere=
d_map/set are associative containers that don&#39;t require an ordering.</d=
iv></div></div></blockquote><div><br></div><div>I personally wouldn&#39;t m=
ind if std::uuid, like std::byte, didn&#39;t have any &quot;less-than&quot;=
 operation at all, and if you wanted to compare them (binary-search an arra=
y of them, whatever) you had to cast them to string or something. But that&=
#39;s because I wouldn&#39;t use std::uuid much. If I did use it, I&#39;d p=
robably notice the lack and complain about it.</div><div><br></div><div>(An=
d I say this as someone who has often railed against the dangers of tuple::=
operator&lt; and optional::operator&lt;. Consistency is, etc.)</div><div><b=
r></div><div>=E2=80=93Arthur</div></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx%3DUAqczN0FVNu9DqxWrahjf8Wk-=
tELna_KCMCJOHPRg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CADvuK0Jx%3DUAqczN0FVNu9DqxWrahjf8Wk-tELna_KCMCJOHPRg%40mail.gmail.c=
om</a>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxTLX6eQa%2BZTR4ay60q_FryMYUu=
cGmw4UVxVW-PP4X8ZA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CA%2BgtASxTLX6eQa%2BZTR4ay60q_FryMYUucGmw4UVxVW-PP4X8ZA%40mail.gma=
il.com</a>.<br>
</blockquote></div></div></div></div></div></div><div><div class=3D"m_33850=
2166779053512h5">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hbL1k9qZynhba5sa49JnLSv1r4z7jVz=
WobECQjHEw8tLQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CALvx3hbL1k9qZynhba5sa49JnLSv1r4z7jVzWobECQjHEw8tLQ%40mail.gmail.com</=
a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUK%2BMfxCy_qvC6a84UnkSwxRQyo=
7Bhc3-DXJC6E8mHJNw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAANG%3DkUK%2BMfxCy_qvC6a84UnkSwxRQyo7Bhc3-DXJC6E8mHJNw%40mail.gma=
il.com</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hb%3DCPtRg51GRM8pCnTh%2BsJb8-xy=
MOBRTamW6FpP2fOkBg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hb%3DCP=
tRg51GRM8pCnTh%2BsJb8-xyMOBRTamW6FpP2fOkBg%40mail.gmail.com</a>.<br />

--0000000000002d6c42057041b2c6--

.

On Thursday, 5 July 2018 07:52:16 PDT Richard Hodges wrote:
> Therefore to build one into a library seems like an error to me.

And yet placing such a type in containers that require ordering operations is
a useful use-case too. Sorting is an internal detail of that container, not a
specific goal (though of course people may come to use it).

How do we solve this?

Also, please note that UUID would have multiple sorting possibilities. For
example, which of these two sort first?

 00000001-0000-0000-0000-000000000000
 01000000-0000-0000-0000-000000000000

Many implementations treat UUIDs as a sequence of components, the first of
which is a 32-bit number.

Ditto for

 01000000-0000-0000-0000-000000000000
 00000000-0000-0000-0000-000000000001

Another valid implementation would be a plain 16-byte compare (SSE2
instruction PCMPGT), which due to x86's little-endianness placing the MSB in
the last byte would make the second one be sorted first.

Whatever solution we come up with, it should be made clear that the order is
not specified and thus cannot be relied upon to be cross-platform.

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



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

.

--00000000000085bf080570428cf6
Content-Type: text/plain; charset="UTF-8"

On Thu, 5 Jul 2018 at 17:09, Thiago Macieira <thiago@macieira.org> wrote:

> On Thursday, 5 July 2018 07:52:16 PDT Richard Hodges wrote:
> > Therefore to build one into a library seems like an error to me.
>
> And yet placing such a type in containers that require ordering operations
> is
> a useful use-case too. Sorting is an internal detail of that container,
> not a
> specific goal (though of course people may come to use it).
>

If the sort order cannot be specified, then the container is in any case
conceptually unsorted, since different systems/compilers/library
implementations will yield different iteration orders for the same source
code. In which case, why would one not use an unordered_ container, which
is already documented to have this behaviour?

As a code maintainer, if I see std::set<Foo>, then I will logically infer
that Foo objects have a defined concept of ordering. i.e. that (foo1 <
foo2) will yield the same result for any given foo1 and foo2, no matter
what hardware my code is running on.

if I see std::set<std::uuid>, what am I to infer? That there is some
implicit sense of order between UUIDs? There is not. The code will make no
sense.

Again, if the user wants to sort by bytes, bits, integer representation or
any other criteria, it would be trivial to write the Compare-conforming
function object.


>
> How do we solve this?
>

Forcing the user to conceptualise and define for himself what he means by
UUID order may hopefully prompt him to conclude that it is a bad idea.



>
> Also, please note that UUID would have multiple sorting possibilities. For
> example, which of these two sort first?
>
>         00000001-0000-0000-0000-000000000000
>         01000000-0000-0000-0000-000000000000
>
> Many implementations treat UUIDs as a sequence of components, the first of
> which is a 32-bit number.
>
> Ditto for
>
>         01000000-0000-0000-0000-000000000000
>         00000000-0000-0000-0000-000000000001
>
> Another valid implementation would be a plain 16-byte compare (SSE2
> instruction PCMPGT), which due to x86's little-endianness placing the MSB
> in
> the last byte would make the second one be sorted first.
>
> Whatever solution we come up with, it should be made clear that the order
> is
> not specified and thus cannot be relied upon to be cross-platform.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2276247.eLH75cpEnP%40tjmaciei-mobl1
> .
>

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

--00000000000085bf080570428cf6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu=
, 5 Jul 2018 at 17:09, Thiago Macieira &lt;<a href=3D"mailto:thiago@macieir=
a.org">thiago@macieira.org</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">On Thursday, 5 July 2018 07:52:16 PDT Richard Hodges wrote:<br>
&gt; Therefore to build one into a library seems like an error to me.<br>
<br>
And yet placing such a type in containers that require ordering operations =
is <br>
a useful use-case too. Sorting is an internal detail of that container, not=
 a <br>
specific goal (though of course people may come to use it).<br></blockquote=
><div><br></div><div>If the sort order cannot be specified, then the contai=
ner is in any case conceptually unsorted, since different systems/compilers=
/library implementations will yield different iteration orders for the same=
 source code. In which case, why would one not use an <font face=3D"monospa=
ce, monospace">unordered_</font> container, which is already documented to =
have this behaviour?</div><div><br></div><div>As a code maintainer, if I se=
e <font face=3D"monospace, monospace">std::set&lt;Foo&gt;</font>, then I wi=
ll logically infer that <font face=3D"monospace, monospace">Foo</font> obje=
cts have a defined concept of ordering. i.e. that (foo1 &lt; foo2) will yie=
ld the same result for any given <font face=3D"monospace, monospace">foo1</=
font> and <font face=3D"monospace, monospace">foo2</font>, no matter what h=
ardware my code is running on.</div><div><br></div><div>if I see <font face=
=3D"monospace, monospace">std::set&lt;std::uuid&gt;</font>, what am I to in=
fer? That there is some implicit sense of order between UUIDs? There is not=
.. The code will make no sense.</div><div><br></div><div>Again, if the user =
wants to sort by bytes, bits, integer representation or any other criteria,=
 it would be trivial to write the Compare-conforming function object.=C2=A0=
</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
How do we solve this?<br></blockquote><div><br></div><div><div style=3D"bac=
kground-color:rgb(255,255,255);text-decoration-style:initial;text-decoratio=
n-color:initial">Forcing the user to conceptualise and define for himself w=
hat he means by UUID order may hopefully prompt him to conclude that it is =
a bad idea.</div><br class=3D"gmail-Apple-interchange-newline">=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
Also, please note that UUID would have multiple sorting possibilities. For =
<br>
example, which of these two sort first?<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 00000001-0000-0000-0000-000000000000<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 01000000-0000-0000-0000-000000000000<br>
<br>
Many implementations treat UUIDs as a sequence of components, the first of =
<br>
which is a 32-bit number.<br>
<br>
Ditto for<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 01000000-0000-0000-0000-000000000000<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 00000000-0000-0000-0000-000000000001<br>
<br>
Another valid implementation would be a plain 16-byte compare (SSE2 <br>
instruction PCMPGT), which due to x86&#39;s little-endianness placing the M=
SB in <br>
the last byte would make the second one be sorted first.<br>
<br>
Whatever solution we come up with, it should be made clear that the order i=
s <br>
not specified and thus cannot be relied upon to be cross-platform.<br>
<br>
-- <br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2276247.eLH75cpEnP%40tjmaciei-mobl1" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org=
/d/msgid/std-proposals/2276247.eLH75cpEnP%40tjmaciei-mobl1</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hYTK5sGwm8NLcvbpbMFtx3N17dQQsaw=
xqtG429A5MVYfw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYTK5sGwm8N=
LcvbpbMFtx3N17dQQsawxqtG429A5MVYfw%40mail.gmail.com</a>.<br />

--00000000000085bf080570428cf6--

.

------=_Part_71050_113386553.1530807188567
Content-Type: multipart/alternative;
 boundary="----=_Part_71051_346171830.1530807188567"

------=_Part_71051_346171830.1530807188567
Content-Type: text/plain; charset="UTF-8"

On Thursday, July 5, 2018 at 11:09:59 AM UTC-4, Thiago Macieira wrote:
>
> On Thursday, 5 July 2018 07:52:16 PDT Richard Hodges wrote:
> > Therefore to build one into a library seems like an error to me.
>
> And yet placing such a type in containers that require ordering operations
> is
> a useful use-case too. Sorting is an internal detail of that container,
> not a
> specific goal (though of course people may come to use it).
>

I think that rather depends on the container in question. While you could
say that `map`/`flat_map`'s primary purpose is to allow you to quickly
access values through keys (with sorting being an implementation detail,
despite it being the basis of the container's range interface), the primary
purpose of `set`/`flat_set` is to *be sorted*. To be able to iterate
through a list of items in a specific order.

If someone doesn't really care what the order is, that there simply needs
to be *some order* just to use certain containers, that's fine. A
`std::less` overload would accomplish that adequately. Or if we don't like
`std::less`, we can have some other `uuid_order` functor that orders them
in an arbitrary-yet-total way. So if you need a map of them, you could use
`std::map<uuid, value, uuid_order>`.

Putting such an order into the primary interface of UUID leads to a
question: what is that order? What does it mean for a UUID to compare less
than another?

There is no standard answer for that. So it makes sense that the UUID type
reflect the fact that there is no standard ordering; to do otherwise makes
us liars.

Yes, this makes it slightly more uncomfortable to use UUIDs in ordered
containers. But so long as we provide a solution that is relatively easy to
use, then we will have done our duty.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f881eb6e-724c-431a-8a2c-82310bb851ad%40isocpp.org.

------=_Part_71051_346171830.1530807188567
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, July 5, 2018 at 11:09:59 AM UTC-4, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thursday, 5 Jul=
y 2018 07:52:16 PDT Richard Hodges wrote:
<br>&gt; Therefore to build one into a library seems like an error to me.
<br>
<br>And yet placing such a type in containers that require ordering operati=
ons is=20
<br>a useful use-case too. Sorting is an internal detail of that container,=
 not a=20
<br>specific goal (though of course people may come to use it).<br></blockq=
uote><div><br></div><div>I think that rather depends on the container in qu=
estion. While you could say that `map`/`flat_map`&#39;s primary purpose is =
to allow you to quickly access values through keys (with sorting being an i=
mplementation detail, despite it being the basis of the container&#39;s ran=
ge interface), the primary purpose of `set`/`flat_set` is to <i>be sorted</=
i>. To be able to iterate through a list of items in a specific order.</div=
><div><br></div><div>If someone doesn&#39;t really care what the order is, =
that there simply needs to be <i>some order</i> just to use certain contain=
ers, that&#39;s fine. A `std::less` overload would accomplish that adequate=
ly. Or if we don&#39;t like `std::less`, we can have some other `uuid_order=
` functor that orders them in an arbitrary-yet-total way. So if you need a =
map of them, you could use `std::map&lt;uuid, value, uuid_order&gt;`.<br></=
div><div><br></div><div>Putting such an order into the primary interface of=
 UUID leads to a question: what is that order? What does it mean for a UUID=
 to compare less than another?<br></div><div><br></div><div>There is no sta=
ndard answer for that. So it makes sense that the UUID type reflect the fac=
t that there is no standard ordering; to do otherwise makes us liars.</div>=
<div><br></div><div>Yes, this makes it slightly more uncomfortable to use U=
UIDs in ordered containers. But so long as we provide a solution that is re=
latively easy to use, then we will have done our duty.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f881eb6e-724c-431a-8a2c-82310bb851ad%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f881eb6e-724c-431a-8a2c-82310bb851ad=
%40isocpp.org</a>.<br />

------=_Part_71051_346171830.1530807188567--

------=_Part_71050_113386553.1530807188567--

.

--000000000000d1cede057043d0b9
Content-Type: text/plain; charset="UTF-8"

The pedant in me agrees that ordering of UUIDs is meaningless and that
implementing it would be misleading and maybe even lend itself to abuse.

The lazy part of me thinks that searching for a UUID will be in enough
demand to justify the inclusion of ordering. Although a UUID is a wasteful
key to use in terms of binary size (by definition of a UUID - it's big
enough to prevent any collisions on a vast scale), it is still something
that goes on a lot. It makes no sense for a user to have to implement this
ordering themselves, so along this line of thought a uuid_order is
justified.

Or is it?

Including a uuid_order operation is also misleading for the same reasons
that an in-built ordering is, and providing it would just mean an
unnecessary step for something that *we would be implicitly supporting *by
including uuid_order in the first place.

One could argue that lexicographical ordering is not semantically sensical
(a string built up of arbitrary symbols that don't have much meaning on
their own, but still have a defined ordering by consensus just so we can
find stuff easier), but it's still used so heavily in the real world that
its functionality is built in. We include it for booleans (equally
nonsensical). And I guarantee that the vast majority of overloads of
operator< are for convenience rather than any truly logical meaning.

So the lazy side of me is winning over the pedantic side. I definitely
agree that ordering of UUIDs is nonsensical, but what it lacks in sense it
more than makes up for in real world use.

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

--000000000000d1cede057043d0b9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">The pedant in me agrees that ordering of UUIDs is meaning=
less and that implementing it would be misleading and maybe even lend itsel=
f to abuse.<div dir=3D"auto"><br></div><div dir=3D"auto">The lazy part of m=
e thinks that searching for a UUID will be in enough demand to justify the =
inclusion of ordering. Although a UUID is a wasteful key to use in terms of=
 binary size (by definition of a UUID - it&#39;s big enough to prevent any =
collisions on a vast scale), it is still something that goes on a lot. It m=
akes no sense for a user to have to implement this ordering themselves, so =
along this line of thought a uuid_order is justified.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">Or is it?</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Including a uuid_order operation is also misleading for the=
 same reasons that an in-built ordering is, and providing it would just mea=
n an unnecessary step for something that <i>we would be implicitly supporti=
ng </i>by including uuid_order in the first place.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">One could argue that lexicographical ordering is=
 not semantically sensical (a string built up of arbitrary symbols that don=
&#39;t have much meaning on their own, but still have a defined ordering by=
 consensus just so we can find stuff easier), but it&#39;s still used so he=
avily in the real world that its functionality is built in. We include it f=
or booleans (equally nonsensical). And I guarantee that the vast majority o=
f overloads of operator&lt; are for convenience rather than any truly logic=
al meaning.</div><div dir=3D"auto"><br></div><div dir=3D"auto">So the lazy =
side of me is winning over the pedantic side. I definitely agree that order=
ing of UUIDs is nonsensical, but what it lacks in sense it more than makes =
up for in real world use.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPTnAHFag_KjbyJg5Sk3EvE7kO3Aa=
7Kub4kqPWu8nfRaA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPTnAHF=
ag_KjbyJg5Sk3EvE7kO3Aa7Kub4kqPWu8nfRaA%40mail.gmail.com</a>.<br />

--000000000000d1cede057043d0b9--

.

--000000000000d9480c05704452a7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 5, 2018 at 9:13 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Thursday, July 5, 2018 at 11:09:59 AM UTC-4, Thiago Macieira wrote:
>>
>> On Thursday, 5 July 2018 07:52:16 PDT Richard Hodges wrote:
>> > Therefore to build one into a library seems like an error to me.
>>
>> And yet placing such a type in containers that require ordering
>> operations is
>> a useful use-case too. Sorting is an internal detail of that container,
>> not a
>> specific goal (though of course people may come to use it).
>>
>
> I think that rather depends on the container in question. While you could
> say that `map`/`flat_map`'s primary purpose is to allow you to quickly
> access values through keys (with sorting being an implementation detail,
> despite it being the basis of the container's range interface), the prima=
ry
> purpose of `set`/`flat_set` is to *be sorted*. To be able to iterate
> through a list of items in a specific order.
>

"The primary purpose of a `set` is to be sorted" is right up there with "A
`byte` is not necessarily eight bits" in the list of claims that only C++
people make (while all the other languages laugh at them for it).

A *set* is simply a *set* =E2=80=94 a collection of unique elements.
This is how C++ is able to have two varieties of it: one that uses
operator< to ensure element uniqueness, and one that uses std::hash and
operator=3D=3D to ensure element uniqueness.
We probably all agree that std::set should originally have been named
something like "std::ordered_set", at which point we could say that what
distinguishes an "ordered_set" from an "unordered_set" is precisely that
the former is ordered and the latter is unordered.
But that's not the world we live in. We live in this ugly world, where C++
has a data type named "std::set", representing a "set", that just happens
to use operator< as an implementation detail. If your type does not provide
operator< =E2=80=94 or provides it with non-totally-ordering semantics (*co=
ugh*
float *cough*) =E2=80=94 then you are not allowed to create a "set" of thos=
e
objects. And that's a horrible restriction to put on normal programmers. So
we (library designers) work around it by adding operator< promiscuously for
any type where a total ordering is conceivable.

The "correct" thing to have done, originally, in the original STL, would
have been

    template<class T> struct less { ... };  // as usual; not a
customization point
    template<class T> struct total_order : less<T> {};  // customization
point, like std::hash

    template<class T, class Cmp =3D total_order<T>> class ordered_set { ...=
 };

This would have let us do the following desirable things:
- std::ordered_set<std::uuid> without providing uuid::operator<
- ability to store NaN in std::ordered_set<float> without undefined behavio=
r
- and of course a pedagogical distinction between "ordered_set" and
"unordered_set"
- and of course a pedagogical distinction between "operator<" and "the
property of being totally ordered"

Shower thought: It would be nice if someone started a libc++ fork for "STL
v2" with all these nice ABI breaks in it. (Also vector<bool>. Also
is_relocatable<T>. Also tombstone optionals. Also fully regular tuple<>,
and change tie() to return a tuple_ref<>.)  Maybe it could gain enough
traction that people start using it for real.

Post-shower thought: Ehh, I'll do it tomorrow. :P

=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0K8wbUtPeiBUT-gnS2RBks9FJJvXoTAxiuCtkyQ%3D=
FO2OA%40mail.gmail.com.

--000000000000d9480c05704452a7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Jul 5, 2018 at 9:13 AM, Nicol Bolas <span dir=3D"l=
tr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@=
gmail.com</a>&gt;</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"><div dir=3D"ltr"><span class=
=3D"">On Thursday, July 5, 2018 at 11:09:59 AM UTC-4, Thiago Macieira wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">On Thursday, 5 July 2018 07:52:16 =
PDT Richard Hodges wrote:
<br>&gt; Therefore to build one into a library seems like an error to me.
<br>
<br>And yet placing such a type in containers that require ordering operati=
ons is=20
<br>a useful use-case too. Sorting is an internal detail of that container,=
 not a=20
<br>specific goal (though of course people may come to use it).<br></blockq=
uote><div><br></div></span><div>I think that rather depends on the containe=
r in question. While you could say that `map`/`flat_map`&#39;s primary purp=
ose is to allow you to quickly access values through keys (with sorting bei=
ng an implementation detail, despite it being the basis of the container&#3=
9;s range interface), the primary purpose of `set`/`flat_set` is to <i>be s=
orted</i>. To be able to iterate through a list of items in a specific orde=
r.</div></div></blockquote><div><br></div><div>&quot;The primary purpose of=
 a `set` is to be sorted&quot; is right up there with &quot;A `byte` is not=
 necessarily eight bits&quot; in the list of claims that only C++ people ma=
ke (while all the other languages laugh at them for it).</div><div><br></di=
v><div>A <i>set</i> is simply a <i>set</i> =E2=80=94 a collection of unique=
 elements.</div><div>This is how C++ is able to have two varieties of it: o=
ne that uses operator&lt; to ensure element uniqueness, and one that uses s=
td::hash and operator=3D=3D to ensure element uniqueness.</div><div>We prob=
ably all agree that std::set should originally have been named something li=
ke &quot;std::ordered_set&quot;, at which point we could say that what dist=
inguishes an &quot;ordered_set&quot; from an &quot;unordered_set&quot; is p=
recisely that the former is ordered and the latter is unordered.</div><div>=
But that&#39;s not the world we live in. We live in this ugly world, where =
C++ has a data type named &quot;std::set&quot;, representing a &quot;set&qu=
ot;, that just happens to use operator&lt; as an implementation detail. If =
your type does not provide operator&lt; =E2=80=94 or provides it with non-t=
otally-ordering semantics (*cough* <font face=3D"monospace, monospace">floa=
t</font> *cough*) =E2=80=94 then you are not allowed to create a &quot;set&=
quot; of those objects. And that&#39;s a horrible restriction to put on nor=
mal programmers. So we (library designers) work around it by adding operato=
r&lt; promiscuously for any type where a total ordering is conceivable.</di=
v><div><br></div><div>The &quot;correct&quot; thing to have done, originall=
y, in the original STL, would have been</div><div><br></div><div>=C2=A0 =C2=
=A0 template&lt;class T&gt; struct less { ... }; =C2=A0// as usual; not a c=
ustomization point</div><div>=C2=A0 =C2=A0 template&lt;class T&gt; struct t=
otal_order : less&lt;T&gt; {}; =C2=A0// customization point, like std::hash=
</div><div><br></div><div>=C2=A0 =C2=A0 template&lt;class T, class Cmp =3D =
total_order&lt;T&gt;&gt; class ordered_set { ... };</div><div><br></div><di=
v>This would have let us do the following desirable things:</div><div>- std=
::ordered_set&lt;std::uuid&gt; without providing uuid::operator&lt;</div><d=
iv>- ability to store NaN in std::ordered_set&lt;float&gt; without undefine=
d behavior</div><div>- and of course a pedagogical distinction between &quo=
t;ordered_set&quot; and &quot;unordered_set&quot;</div><div>- and of course=
 a pedagogical distinction between &quot;operator&lt;&quot; and &quot;the p=
roperty of being totally ordered&quot;</div><div><br></div><div>Shower thou=
ght: It would be nice if someone started a libc++ fork for &quot;STL v2&quo=
t; with all these nice ABI breaks in it. (Also vector&lt;bool&gt;. Also is_=
relocatable&lt;T&gt;. Also tombstone optionals. Also fully regular tuple&lt=
;&gt;, and change tie() to return a tuple_ref&lt;&gt;.) =C2=A0Maybe it coul=
d gain enough traction that people start using it for real.</div><div><br><=
/div><div>Post-shower thought: Ehh, I&#39;ll do it tomorrow. :P</div><div><=
br></div><div>=E2=80=93Arthur</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0K8wbUtPeiBUT-gnS2RBks9FJJvXoTA=
xiuCtkyQ%3DFO2OA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0K8wbUtPe=
iBUT-gnS2RBks9FJJvXoTAxiuCtkyQ%3DFO2OA%40mail.gmail.com</a>.<br />

--000000000000d9480c05704452a7--

.

--0000000000007e0e330570447458
Content-Type: text/plain; charset="UTF-8"

For me UUID appears to be just random string. No CRC or something.
Look at small competition at:
https://stackoverflow.com/questions/440133/how-do-i-create-a-random-alpha-numeric-string-in-c


On Thu, Jul 5, 2018 at 7:24 PM, Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:

> The pedant in me agrees that ordering of UUIDs is meaningless and that
> implementing it would be misleading and maybe even lend itself to abuse.
>
> The lazy part of me thinks that searching for a UUID will be in enough
> demand to justify the inclusion of ordering. Although a UUID is a wasteful
> key to use in terms of binary size (by definition of a UUID - it's big
> enough to prevent any collisions on a vast scale), it is still something
> that goes on a lot. It makes no sense for a user to have to implement this
> ordering themselves, so along this line of thought a uuid_order is
> justified.
>
> Or is it?
>
> Including a uuid_order operation is also misleading for the same reasons
> that an in-built ordering is, and providing it would just mean an
> unnecessary step for something that *we would be implicitly supporting *by
> including uuid_order in the first place.
>
> One could argue that lexicographical ordering is not semantically sensical
> (a string built up of arbitrary symbols that don't have much meaning on
> their own, but still have a defined ordering by consensus just so we can
> find stuff easier), but it's still used so heavily in the real world that
> its functionality is built in. We include it for booleans (equally
> nonsensical). And I guarantee that the vast majority of overloads of
> operator< are for convenience rather than any truly logical meaning.
>
> So the lazy side of me is winning over the pedantic side. I definitely
> agree that ordering of UUIDs is nonsensical, but what it lacks in sense it
> more than makes up for in real world use.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAC%2B0CCPTnAHFag_
> KjbyJg5Sk3EvE7kO3Aa7Kub4kqPWu8nfRaA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPTnAHFag_KjbyJg5Sk3EvE7kO3Aa7Kub4kqPWu8nfRaA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

--0000000000007e0e330570447458
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>For me UUID appears to be just random string. No CRC =
or something.</div><div>Look at small competition at: <a href=3D"https://st=
ackoverflow.com/questions/440133/how-do-i-create-a-random-alpha-numeric-str=
ing-in-c">https://stackoverflow.com/questions/440133/how-do-i-create-a-rand=
om-alpha-numeric-string-in-c</a><div><span class=3D"gmail-pln"><br></span><=
/div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Jul 5, 2018 at 7:24 PM, Jake Arkinstall <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:jake.arkinstall@gmail.com" target=3D"_blank">jake.arkinstall@g=
mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"auto">The pedant in me agrees that ordering of UUIDs is meaningless and=
 that implementing it would be misleading and maybe even lend itself to abu=
se.<div dir=3D"auto"><br></div><div dir=3D"auto">The lazy part of me thinks=
 that searching for a UUID will be in enough demand to justify the inclusio=
n of ordering. Although a UUID is a wasteful key to use in terms of binary =
size (by definition of a UUID - it&#39;s big enough to prevent any collisio=
ns on a vast scale), it is still something that goes on a lot. It makes no =
sense for a user to have to implement this ordering themselves, so along th=
is line of thought a uuid_order is justified.</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">Or is it?</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Including a uuid_order operation is also misleading for the same =
reasons that an in-built ordering is, and providing it would just mean an u=
nnecessary step for something that <i>we would be implicitly supporting </i=
>by including uuid_order in the first place.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">One could argue that lexicographical ordering is not s=
emantically sensical (a string built up of arbitrary symbols that don&#39;t=
 have much meaning on their own, but still have a defined ordering by conse=
nsus just so we can find stuff easier), but it&#39;s still used so heavily =
in the real world that its functionality is built in. We include it for boo=
leans (equally nonsensical). And I guarantee that the vast majority of over=
loads of operator&lt; are for convenience rather than any truly logical mea=
ning.</div><div dir=3D"auto"><br></div><div dir=3D"auto">So the lazy side o=
f me is winning over the pedantic side. I definitely agree that ordering of=
 UUIDs is nonsensical, but what it lacks in sense it more than makes up for=
 in real world use.</div></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPTnAHFag_KjbyJg5Sk3EvE7kO3Aa=
7Kub4kqPWu8nfRaA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CAC%2B0CCPTnAHFag_<wbr>KjbyJg5Sk3EvE7kO3Aa7Kub4kqPWu8<wbr>=
nfRaA%40mail.gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEfefmy6N%2B869fzu2B1DgUM8z6VboSkeKo=
MQ4U8c9Tn4ot5BLQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmy6N%2B86=
9fzu2B1DgUM8z6VboSkeKoMQ4U8c9Tn4ot5BLQ%40mail.gmail.com</a>.<br />

--0000000000007e0e330570447458--

.

--000000000000fb3dba057045552e
Content-Type: text/plain; charset="UTF-8"

On Thu, 5 Jul 2018, 19:09 Dejan Milosavljevic, <dmilos@gmail.com> wrote:

> For me UUID appears to be just random string.
>

It is. It holds no meaning, but it is unique, which means there will be
some people using it in a searchable manner (it is an identifier, after
all).

For this reason and this reason alone, ordering makes sense. And if some
ordering is provided by stdlib, I see no reason why users should jump
through hoops to use it (e.g. through explicit use of a uuid_order).

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

--000000000000fb3dba057045552e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, =
5 Jul 2018, 19:09 Dejan Milosavljevic, &lt;<a href=3D"mailto:dmilos@gmail.c=
om" rel=3D"noreferrer noreferrer" target=3D"_blank">dmilos@gmail.com</a>&gt=
; wrote:<br></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>For =
me UUID appears to be just random string.</div></div></blockquote></div></d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">It is. It holds no meaning=
, but it is unique, which means there will be some people using it in a sea=
rchable manner (it is an identifier, after all).</div><div dir=3D"auto"><br=
></div><div dir=3D"auto">For this reason and this reason alone, ordering ma=
kes sense. And if some ordering is provided by stdlib, I see no reason why =
users should jump through hoops to use it (e.g. through explicit use of a u=
uid_order).<br></div><div dir=3D"auto"></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCO0Kdrp5k1HTU%2BoNHNgTrJkkNdf=
qS4uNH9Msa92RZ%2BxrQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCO0=
Kdrp5k1HTU%2BoNHNgTrJkkNdfqS4uNH9Msa92RZ%2BxrQ%40mail.gmail.com</a>.<br />

--000000000000fb3dba057045552e--

.

--000000000000fd5e170570460744
Content-Type: text/plain; charset="UTF-8"

On Thu, 5 Jul 2018 at 21:13, Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:

> On Thu, 5 Jul 2018, 19:09 Dejan Milosavljevic, <dmilos@gmail.com> wrote:
>
>> For me UUID appears to be just random string.
>>
>
> It is. It holds no meaning, but it is unique, which means there will be
> some people using it in a searchable manner (it is an identifier, after
> all).
>

Use a hash_map. It's O(1) lookup which easily outperforms the O(logN)
lookup of an ordered map. The only reason we'd use an ordered map would be
if order mattered. With a UUID it (by design) does not.


>
> For this reason and this reason alone, ordering makes sense. And if some
> ordering is provided by stdlib, I see no reason why users should jump
> through hoops to use it (e.g. through explicit use of a uuid_order).
>

The presence of a hash map in the std library obviates any need to use any
kind of ordered container with UUIDs. There is no possible logical reason
to a greater/less-than relationship between two UUIDs.

People storing data temporally will have an ordered index on monotonic
timestamps or sequence numbers (which are obviously ordered). People using
UUIDs for identity lookups will always want a hash-based index for the
purpose.



> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCO0Kdrp5k1HTU%2BoNHNgTrJkkNdfqS4uNH9Msa92RZ%2BxrQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCO0Kdrp5k1HTU%2BoNHNgTrJkkNdfqS4uNH9Msa92RZ%2BxrQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

--000000000000fd5e170570460744
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu=
, 5 Jul 2018 at 21:13, Jake Arkinstall &lt;<a href=3D"mailto:jake.arkinstal=
l@gmail.com">jake.arkinstall@gmail.com</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"auto"><div><div class=3D"gmail_quote"><div d=
ir=3D"ltr">On Thu, 5 Jul 2018, 19:09 Dejan Milosavljevic, &lt;<a href=3D"ma=
ilto:dmilos@gmail.com" rel=3D"noreferrer noreferrer" target=3D"_blank">dmil=
os@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div>For me UUID appears to be just random string.</div></div></b=
lockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">It is. =
It holds no meaning, but it is unique, which means there will be some peopl=
e using it in a searchable manner (it is an identifier, after all).</div></=
div></blockquote><div><br></div><div>Use a hash_map. It&#39;s O(1) lookup w=
hich easily outperforms the O(logN) lookup of an ordered map. The only reas=
on we&#39;d use an ordered map would be if order mattered. With a UUID it (=
by design) does not.</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"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">For this rea=
son and this reason alone, ordering makes sense. And if some ordering is pr=
ovided by stdlib, I see no reason why users should jump through hoops to us=
e it (e.g. through explicit use of a uuid_order).<br></div></div></blockquo=
te><div><br></div><div>The presence of a hash map in the std library obviat=
es any need to use any kind of ordered container with UUIDs. There is no po=
ssible logical reason to a greater/less-than relationship between two UUIDs=
..</div><div><br></div><div>People storing data temporally will have an orde=
red index on monotonic timestamps or sequence numbers (which are obviously =
ordered). People using UUIDs for identity lookups will always want a hash-b=
ased index for the purpose.</div><div><br></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"auto"><div dir=3D"auto"></div><div dir=3D"=
auto"></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCO0Kdrp5k1HTU%2BoNHNgTrJkkNdf=
qS4uNH9Msa92RZ%2BxrQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAC%2B0CCO0Kdrp5k1HTU%2BoNHNgTrJkkNdfqS4uNH9Msa92RZ%2BxrQ%40mail=
..gmail.com</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hbJ3urV9C380rgt4BDAorxussU2XpqB=
aK-Dmg%2BwXNkGHw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbJ3urV9C=
380rgt4BDAorxussU2XpqBaK-Dmg%2BwXNkGHw%40mail.gmail.com</a>.<br />

--000000000000fd5e170570460744--

.

------=_Part_73813_1269763093.1530824102516
Content-Type: multipart/alternative;
 boundary="----=_Part_73814_770165080.1530824102516"

------=_Part_73814_770165080.1530824102516
Content-Type: text/plain; charset="UTF-8"



On Thursday, July 5, 2018 at 7:24:13 PM UTC+2, Jake Arkinstall wrote:
>
> The pedant in me agrees that ordering of UUIDs is meaningless and that
> implementing it would be misleading and maybe even lend itself to abuse.
>
> The lazy part of me thinks that searching for a UUID will be in enough
> demand to justify the inclusion of ordering. Although a UUID is a wasteful
> key to use in terms of binary size (by definition of a UUID - it's big
> enough to prevent any collisions on a vast scale), it is still something
> that goes on a lot. It makes no sense for a user to have to implement this
> ordering themselves, so along this line of thought a uuid_order is
> justified.
>
> Or is it?
>
> Including a uuid_order operation is also misleading for the same reasons
> that an in-built ordering is, and providing it would just mean an
> unnecessary step for something that *we would be implicitly supporting *by
> including uuid_order in the first place.
>
>
But if it named `uuid_lexical_order` or `uuid_byte_order`? standard could
provide both or even more. User will chose best version that fit his goals
or he will roll its own.


> One could argue that lexicographical ordering is not semantically sensical
> (a string built up of arbitrary symbols that don't have much meaning on
> their own, but still have a defined ordering by consensus just so we can
> find stuff easier), but it's still used so heavily in the real world that
> its functionality is built in. We include it for booleans (equally
> nonsensical). And I guarantee that the vast majority of overloads of
> operator< are for convenience rather than any truly logical meaning.
>
> So the lazy side of me is winning over the pedantic side. I definitely
> agree that ordering of UUIDs is nonsensical, but what it lacks in sense it
> more than makes up for in real world use.
>

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

------=_Part_73814_770165080.1530824102516
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, July 5, 2018 at 7:24:13 PM UTC+2, Jak=
e Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"auto">The pedant in me agrees that ordering of UUIDs is meaningless and th=
at implementing it would be misleading and maybe even lend itself to abuse.=
<div dir=3D"auto"><br></div><div dir=3D"auto">The lazy part of me thinks th=
at searching for a UUID will be in enough demand to justify the inclusion o=
f ordering. Although a UUID is a wasteful key to use in terms of binary siz=
e (by definition of a UUID - it&#39;s big enough to prevent any collisions =
on a vast scale), it is still something that goes on a lot. It makes no sen=
se for a user to have to implement this ordering themselves, so along this =
line of thought a uuid_order is justified.</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">Or is it?</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">Including a uuid_order operation is also misleading for the same reaso=
ns that an in-built ordering is, and providing it would just mean an unnece=
ssary step for something that <i>we would be implicitly supporting </i>by i=
ncluding uuid_order in the first place.</div><div dir=3D"auto"><br></div></=
div></blockquote><div>=C2=A0</div><div>But if it named `uuid_lexical_order`=
 or `uuid_byte_order`? standard could provide both or even more. User will =
chose best version that fit his goals or he will roll its own.<br></div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto=
"><div dir=3D"auto"></div><div dir=3D"auto">One could argue that lexicograp=
hical ordering is not semantically sensical (a string built up of arbitrary=
 symbols that don&#39;t have much meaning on their own, but still have a de=
fined ordering by consensus just so we can find stuff easier), but it&#39;s=
 still used so heavily in the real world that its functionality is built in=
.. We include it for booleans (equally nonsensical). And I guarantee that th=
e vast majority of overloads of operator&lt; are for convenience rather tha=
n any truly logical meaning.</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">So the lazy side of me is winning over the pedantic side. I definitely=
 agree that ordering of UUIDs is nonsensical, but what it lacks in sense it=
 more than makes up for in real world use.</div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4e8d1fd8-3fae-4e0d-9b6c-b301850fc33d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4e8d1fd8-3fae-4e0d-9b6c-b301850fc33d=
%40isocpp.org</a>.<br />

------=_Part_73814_770165080.1530824102516--

------=_Part_73813_1269763093.1530824102516--

.

--00000000000096c8ee057046ea46
Content-Type: text/plain; charset="UTF-8"

On Thu, 5 Jul 2018 at 22:55, <inkwizytoryankes@gmail.com> wrote:

>
>
> On Thursday, July 5, 2018 at 7:24:13 PM UTC+2, Jake Arkinstall wrote:
>>
>> The pedant in me agrees that ordering of UUIDs is meaningless and that
>> implementing it would be misleading and maybe even lend itself to abuse.
>>
>> The lazy part of me thinks that searching for a UUID will be in enough
>> demand to justify the inclusion of ordering. Although a UUID is a wasteful
>> key to use in terms of binary size (by definition of a UUID - it's big
>> enough to prevent any collisions on a vast scale), it is still something
>> that goes on a lot. It makes no sense for a user to have to implement this
>> ordering themselves, so along this line of thought a uuid_order is
>> justified.
>>
>> Or is it?
>>
>> Including a uuid_order operation is also misleading for the same reasons
>> that an in-built ordering is, and providing it would just mean an
>> unnecessary step for something that *we would be implicitly supporting *by
>> including uuid_order in the first place.
>>
>>
> But if it named `uuid_lexical_order` or `uuid_byte_order`? standard could
> provide both or even more. User will chose best version that fit his goals
> or he will roll its own.
>

What would be the motivating use case for such a utility?

Without a compelling one, this would just represent more code to maintain
without reason.


>
>
>> One could argue that lexicographical ordering is not semantically
>> sensical (a string built up of arbitrary symbols that don't have much
>> meaning on their own, but still have a defined ordering by consensus just
>> so we can find stuff easier), but it's still used so heavily in the real
>> world that its functionality is built in. We include it for booleans
>> (equally nonsensical). And I guarantee that the vast majority of overloads
>> of operator< are for convenience rather than any truly logical meaning.
>>
>> So the lazy side of me is winning over the pedantic side. I definitely
>> agree that ordering of UUIDs is nonsensical, but what it lacks in sense it
>> more than makes up for in real world use.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4e8d1fd8-3fae-4e0d-9b6c-b301850fc33d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4e8d1fd8-3fae-4e0d-9b6c-b301850fc33d%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

--00000000000096c8ee057046ea46
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu=
, 5 Jul 2018 at 22:55, &lt;<a href=3D"mailto:inkwizytoryankes@gmail.com">in=
kwizytoryankes@gmail.com</a>&gt; wrote:<br></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"><br><br>On Thursday, July 5, 2018 at 7:24:13 PM UTC+2=
, Jake Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"auto">The pedant in me agrees that ordering of UUIDs is meaningless and th=
at implementing it would be misleading and maybe even lend itself to abuse.=
<div dir=3D"auto"><br></div><div dir=3D"auto">The lazy part of me thinks th=
at searching for a UUID will be in enough demand to justify the inclusion o=
f ordering. Although a UUID is a wasteful key to use in terms of binary siz=
e (by definition of a UUID - it&#39;s big enough to prevent any collisions =
on a vast scale), it is still something that goes on a lot. It makes no sen=
se for a user to have to implement this ordering themselves, so along this =
line of thought a uuid_order is justified.</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">Or is it?</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">Including a uuid_order operation is also misleading for the same reaso=
ns that an in-built ordering is, and providing it would just mean an unnece=
ssary step for something that <i>we would be implicitly supporting </i>by i=
ncluding uuid_order in the first place.</div><div dir=3D"auto"><br></div></=
div></blockquote><div>=C2=A0</div><div>But if it named `uuid_lexical_order`=
 or `uuid_byte_order`? standard could provide both or even more. User will =
chose best version that fit his goals or he will roll its own.<br></div></d=
iv></blockquote><div><br></div><div>What would be the motivating use case f=
or such a utility?</div><div><br></div><div>Without a compelling one, this =
would just represent more code to maintain without reason.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>=C2=
=A0</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"auto"><div dir=
=3D"auto"></div><div dir=3D"auto">One could argue that lexicographical orde=
ring is not semantically sensical (a string built up of arbitrary symbols t=
hat don&#39;t have much meaning on their own, but still have a defined orde=
ring by consensus just so we can find stuff easier), but it&#39;s still use=
d so heavily in the real world that its functionality is built in. We inclu=
de it for booleans (equally nonsensical). And I guarantee that the vast maj=
ority of overloads of operator&lt; are for convenience rather than any trul=
y logical meaning.</div><div dir=3D"auto"><br></div><div dir=3D"auto">So th=
e lazy side of me is winning over the pedantic side. I definitely agree tha=
t ordering of UUIDs is nonsensical, but what it lacks in sense it more than=
 makes up for in real world use.</div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4e8d1fd8-3fae-4e0d-9b6c-b301850fc33d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4e8d1fd8-3fae-=
4e0d-9b6c-b301850fc33d%40isocpp.org</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3ha8hXDQEqPUFWpoMurm3jCTv-B_4WS-=
AJLVhYfD48yS2A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3ha8hXDQEqPU=
FWpoMurm3jCTv-B_4WS-AJLVhYfD48yS2A%40mail.gmail.com</a>.<br />

--00000000000096c8ee057046ea46--

.

--000000000000cc6898057046ec77
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 3, 2018 at 12:48 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

> On Tue, Jul 3, 2018 at 9:21 AM, Tony V E <tvaneerd@gmail.com> wrote:
>
>> On Fri, Jun 29, 2018 at 3:43 AM, Nicolas Lesser <blitzrakete@gmail.com>
>> wrote:
>>
>>> Is there a reason why there are a member and non member functions for
>>>>> operator=3D=3D and operator<?
>>>>
>>>>
>>>> They are all non-member.
>>>>
>>>
>>> Whoops, didn't realize they were were friends.
>>>
>>>>
>>>> I think it makes sense to use operator<=3D> instead of operator=3D=3D =
and
>>>>> operator!=3D (as an additional benefit, you can then use uuid as a no=
n-type
>>>>> template parameter).
>>>>
>>>>
>>>> My initial idea was to only be able to compare uuid for equality.
>>>> operator < is necessary to be able to use uuids with associative
>>>> containers. It does not really make sense to compare whether a uuid is=
 less
>>>> than another for any other reasons. Should we want to have all these
>>>> comparison operators, then yes, it makes more sense to use the <=3D> o=
perator.
>>>>
>>>> constexpr auto operator <=3D>(uuid const & lhs, uuid const & rhs)
>>>> noexcept;
>>>>
>>>
>>> Just because we don't want the others operators doesn't mean we can't
>>> use the spaceship operator:
>>>
>>>     constexpr std::strong_equality operator<=3D>(uuid const&, uuid cons=
t&)
>>> noexcept =3D default;
>>>
>>> The operator< can always be provided as an extra overload.
>>>
>>
>> If we only want map/set interop, then define a std::less<uuid>, not
>> operator<.
>>
>
> Please don't do this.
> You should never explicitly specialize std::less<T> for any type, ever.
> The primary reason is that it breaks all the user's expectations. The
> secondary reason is that it won't always work! Heterogeneous containers u=
se
> std::less<>, not std::less<T>.
>
>
I mostly agree with you.  I'm all for "take back std::less".  But we
already do this for std::complex, for example.

But I'd love a better answer - like fix map and set to call std::order when
std::less doesn't work.  Or something like that.



> If your type has operator<, then it should have the full complement of <
> <=3D =3D=3D >=3D > !=3D (which in C++2a means "it should have operator<=
=3D>").
> Orthogonally to that consideration, std::less<T>'s whole purpose is to
> expose the semantics of everybody's operator< in a consistent and
> functorish way.
> Your proposal has nothing to do with std::less, and therefore should not
> touch it.
>
> If you really hate comparison operators for some reason, then the
> STL-favored thing to do is add a free function named *foo*_less with the
> semantics you want for your comparator, and force people to type out
>     using uuidset_t =3D std::set<std::uuid, std::foo_less>;
> Prior art: https://en.cppreference.com/w/cpp/memory/owner_less
> However, we can tell that this is probably a bad idea in your case by
> considering what is the appropriate name for "foo_less" in this case. It'=
s
> comparing uuids, and it's comparing them on the only thing it makes sense
> to compare uuids on =E2=80=94 their values =E2=80=94 so the logical name =
for the free
> function is "uuid_less".
>     using uuidset_t =3D std::set<std::uuid, std::uuid_less>;
> But C++ has a better way to spell "uuid_less(const uuid&, const uuid&)"!
> That spelling is very old-school-C.  The C++-ish spelling for "uuid_less"
> is...
>     bool operator<(const uuid&, const uuid&);
> This conveys the same information =E2=80=94 "compares uuids, for less-tha=
n" =E2=80=94 but
> it conveys it in a shorter and simpler way that also composes (semi)nicel=
y
> with generic containers such as std::set and std::map.
>
>
> Alternatively, recognize that unordered_map/set are associative container=
s
>> that don't require an ordering.
>>
>
> I personally wouldn't mind if std::uuid, like std::byte, didn't have any
> "less-than" operation at all, and if you wanted to compare them
> (binary-search an array of them, whatever) you had to cast them to string
> or something. But that's because I wouldn't use std::uuid much. If I did
> use it, I'd probably notice the lack and complain about it.
>
> (And I say this as someone who has often railed against the dangers of
> tuple::operator< and optional::operator<. Consistency is, etc.)
>
> =E2=80=93Arthur
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CADvuK0Jx%3DUAqczN0FVNu9DqxWrahjf8Wk-
> tELna_KCMCJOHPRg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx%3=
DUAqczN0FVNu9DqxWrahjf8Wk-tELna_KCMCJOHPRg%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>



--=20
Be seeing you,
Tony

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOHCbitAfv_w%3D9fTXZ3csiS5pBQEknFKuLye31otFUH4t=
tJfMg%40mail.gmail.com.

--000000000000cc6898057046ec77
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 Tue, Jul 3, 2018 at 12:48 PM, Arthur O&#39;Dwyer <span dir=3D"ltr">&=
lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.=
odwyer@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><span class=3D"">On Tue, Jul 3, 2018 at 9:21 AM, Tony V E <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank"=
>tvaneerd@gmail.com</a>&gt;</span> wrote:</span><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-styl=
e:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Fri, Jun 29, 20=
18 at 3:43 AM, Nicolas Lesser <span dir=3D"ltr">&lt;<a href=3D"mailto:blitz=
rakete@gmail.com" target=3D"_blank">blitzrakete@gmail.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"auto"><span><div><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:so=
lid;border-left-color:rgb(204,204,204);padding-left:1ex">Is there a reason =
why there are a member and non member functions for operator=3D=3D and oper=
ator&lt;?</blockquote><div><br></div><div>They are all non-member.</div></d=
iv></blockquote></div></div><div dir=3D"auto"><br></div></span><div dir=3D"=
auto">Whoops, didn&#39;t realize they were were friends.</div><span><div di=
r=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:soli=
d;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(20=
4,204,204);padding-left:1ex">I think it makes sense to use operator&lt;=3D&=
gt; instead of operator=3D=3D and operator!=3D (as an additional benefit, y=
ou can then use uuid as a non-type template parameter).</blockquote><div><b=
r></div><div>My initial idea was to only be able to compare uuid for equali=
ty. operator &lt; is necessary to be able to use uuids with associative con=
tainers. It does not really make sense to compare whether a uuid is less th=
an another for any other reasons. Should we want to have all these comparis=
on operators, then yes, it makes more sense to use the &lt;=3D&gt; operator=
..</div><div><br></div><div>constexpr auto operator &lt;=3D&gt;(uuid const &=
amp; lhs, uuid const &amp; rhs) noexcept;<br></div></div></blockquote></div=
></div><div dir=3D"auto"><br></div></span><div dir=3D"auto">Just because we=
 don&#39;t want the others operators doesn&#39;t mean we can&#39;t use the =
spaceship operator:</div><div dir=3D"auto"><br></div><div dir=3D"auto">=C2=
=A0 =C2=A0 constexpr std::strong_equality operator&lt;=3D&gt;(uuid const&am=
p;, uuid const&amp;) noexcept =3D default;</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">The operator&lt; can always be provided as an extra over=
load.</div></div></blockquote><div><br></div>If we only want map/set intero=
p, then define a std::less&lt;uuid&gt;, not operator&lt;.</div></div></div>=
</blockquote><div><br></div></span><div>Please don&#39;t do this.</div><div=
>You should never explicitly specialize std::less&lt;T&gt; for any type, ev=
er.=C2=A0 The primary reason is that it breaks all the user&#39;s expectati=
ons. The secondary reason is that it won&#39;t always work! Heterogeneous c=
ontainers use std::less&lt;&gt;, not std::less&lt;T&gt;.</div><div><br></di=
v></div></div></div></blockquote><div><br></div><div>I mostly agree with yo=
u.=C2=A0 I&#39;m all for &quot;take back std::less&quot;.=C2=A0 But we alre=
ady do this for std::complex, for example.</div><div><br></div><div>But I&#=
39;d love a better answer - like fix map and set to call std::order when st=
d::less doesn&#39;t work.=C2=A0 Or something like that.</div><div><br></div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div>If your type h=
as operator&lt;, then it should have the full complement of &lt; &lt;=3D =
=3D=3D &gt;=3D &gt; !=3D (which in C++2a means &quot;it should have operato=
r&lt;=3D&gt;&quot;).</div><div>Orthogonally to that consideration, std::les=
s&lt;T&gt;&#39;s whole purpose is to expose the semantics of everybody&#39;=
s operator&lt; in a consistent and functorish way.</div><div>Your proposal =
has nothing to do with std::less, and therefore should not touch it.</div><=
div><br></div><div>If you really hate comparison operators for some reason,=
 then the STL-favored thing to do is add a free function named <i>foo</i>_l=
ess with the semantics you want for your comparator, and force people to ty=
pe out</div><div>=C2=A0 =C2=A0 using uuidset_t =3D std::set&lt;std::uuid, s=
td::foo_less&gt;;</div><div>Prior art: <a href=3D"https://en.cppreference.c=
om/w/cpp/memory/owner_less" target=3D"_blank">https://en.cppreference.com/w=
/<wbr>cpp/memory/owner_less</a><br></div><div>However, we can tell that thi=
s is probably a bad idea in your case by considering what is the appropriat=
e name for &quot;foo_less&quot; in this case. It&#39;s comparing uuids, and=
 it&#39;s comparing them on the only thing it makes sense to compare uuids =
on =E2=80=94 their values =E2=80=94 so the logical name for the free functi=
on is &quot;uuid_less&quot;.</div><div><div>=C2=A0 =C2=A0 using uuidset_t =
=3D std::set&lt;std::uuid, std::uuid_less&gt;;</div></div><div>But C++ has =
a better way to spell &quot;uuid_less(const uuid&amp;, const uuid&amp;)&quo=
t;!=C2=A0 That spelling is very old-school-C.=C2=A0 The C++-ish spelling fo=
r &quot;uuid_less&quot; is...</div><div>=C2=A0 =C2=A0 bool operator&lt;(con=
st uuid&amp;, const uuid&amp;);</div><div>This conveys the same information=
 =E2=80=94 &quot;compares uuids, for less-than&quot; =E2=80=94 but it conve=
ys it in a shorter and simpler way that also composes (semi)nicely with gen=
eric containers such as std::set and std::map.</div><span class=3D""><div><=
br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-=
color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"></div><div class=3D"gmail_quote">Alter=
natively, recognize that unordered_map/set are associative containers that =
don&#39;t require an ordering.</div></div></div></blockquote><div><br></div=
></span><div>I personally wouldn&#39;t mind if std::uuid, like std::byte, d=
idn&#39;t have any &quot;less-than&quot; operation at all, and if you wante=
d to compare them (binary-search an array of them, whatever) you had to cas=
t them to string or something. But that&#39;s because I wouldn&#39;t use st=
d::uuid much. If I did use it, I&#39;d probably notice the lack and complai=
n about it.</div><div><br></div><div>(And I say this as someone who has oft=
en railed against the dangers of tuple::operator&lt; and optional::operator=
&lt;. Consistency is, etc.)</div><div><br></div><div>=E2=80=93Arthur</div><=
/div></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0Jx%3DUAqczN0FVNu9DqxWrahjf8Wk-=
tELna_KCMCJOHPRg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CADvuK0Jx%<wbr>3DUAqczN0FVNu9DqxWrahjf8Wk-<wbr>tELna_KCMCJ=
OHPRg%40mail.gmail.<wbr>com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbitAfv_w%3D9fTXZ3csiS5pBQEknFKuL=
ye31otFUH4ttJfMg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitAfv_w%3=
D9fTXZ3csiS5pBQEknFKuLye31otFUH4ttJfMg%40mail.gmail.com</a>.<br />

--000000000000cc6898057046ec77--

.

------=_Part_59729_458861947.1530830792284
Content-Type: multipart/alternative;
 boundary="----=_Part_59730_1457721032.1530830792285"

------=_Part_59730_1457721032.1530830792285
Content-Type: text/plain; charset="UTF-8"



On Thursday, July 5, 2018 at 11:06:11 PM UTC+2, Richard Hodges wrote:
>
>
>
> On Thu, 5 Jul 2018 at 22:55, <inkwizyt...@gmail.com <javascript:>> wrote:
>
>>
>>
>> On Thursday, July 5, 2018 at 7:24:13 PM UTC+2, Jake Arkinstall wrote:
>>>
>>> The pedant in me agrees that ordering of UUIDs is meaningless and that
>>> implementing it would be misleading and maybe even lend itself to abuse.
>>>
>>> The lazy part of me thinks that searching for a UUID will be in enough
>>> demand to justify the inclusion of ordering. Although a UUID is a wasteful
>>> key to use in terms of binary size (by definition of a UUID - it's big
>>> enough to prevent any collisions on a vast scale), it is still something
>>> that goes on a lot. It makes no sense for a user to have to implement this
>>> ordering themselves, so along this line of thought a uuid_order is
>>> justified.
>>>
>>> Or is it?
>>>
>>> Including a uuid_order operation is also misleading for the same reasons
>>> that an in-built ordering is, and providing it would just mean an
>>> unnecessary step for something that *we would be implicitly supporting *by
>>> including uuid_order in the first place.
>>>
>>>
>> But if it named `uuid_lexical_order` or `uuid_byte_order`? standard could
>> provide both or even more. User will chose best version that fit his goals
>> or he will roll its own.
>>
>
> What would be the motivating use case for such a utility?
>
> Without a compelling one, this would just represent more code to maintain
> without reason.
>
>

I only referring to name and possibility of "misleading", if name
explicitly mark ordering mechanism, we will not imply that uuid have any
natural order. Each can have different tradeoffs and user can choose what
he need or like.


>>
>>> One could argue that lexicographical ordering is not semantically
>>> sensical (a string built up of arbitrary symbols that don't have much
>>> meaning on their own, but still have a defined ordering by consensus just
>>> so we can find stuff easier), but it's still used so heavily in the real
>>> world that its functionality is built in. We include it for booleans
>>> (equally nonsensical). And I guarantee that the vast majority of overloads
>>> of operator< are for convenience rather than any truly logical meaning.
>>>
>>> So the lazy side of me is winning over the pedantic side. I definitely
>>> agree that ordering of UUIDs is nonsensical, but what it lacks in sense it
>>> more than makes up for in real world use.
>>>
>> --
>> 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:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4e8d1fd8-3fae-4e0d-9b6c-b301850fc33d%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4e8d1fd8-3fae-4e0d-9b6c-b301850fc33d%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>

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

------=_Part_59730_1457721032.1530830792285
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, July 5, 2018 at 11:06:11 PM UTC+2, Ri=
chard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, 5 Jul 201=
8 at 22:55, &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"Es-EApvuCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;java=
script:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;ret=
urn true;">inkwizyt...@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><br><br>On Thursday, July 5, 2018 at 7:24:13=
 PM UTC+2, Jake Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"auto">The pedant in me agrees that ordering of UUIDs is meaningle=
ss and that implementing it would be misleading and maybe even lend itself =
to abuse.<div dir=3D"auto"><br></div><div dir=3D"auto">The lazy part of me =
thinks that searching for a UUID will be in enough demand to justify the in=
clusion of ordering. Although a UUID is a wasteful key to use in terms of b=
inary size (by definition of a UUID - it&#39;s big enough to prevent any co=
llisions on a vast scale), it is still something that goes on a lot. It mak=
es no sense for a user to have to implement this ordering themselves, so al=
ong this line of thought a uuid_order is justified.</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">Or is it?</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">Including a uuid_order operation is also misleading for the s=
ame reasons that an in-built ordering is, and providing it would just mean =
an unnecessary step for something that <i>we would be implicitly supporting=
 </i>by including uuid_order in the first place.</div><div dir=3D"auto"><br=
></div></div></blockquote><div>=C2=A0</div><div>But if it named `uuid_lexic=
al_order` or `uuid_byte_order`? standard could provide both or even more. U=
ser will chose best version that fit his goals or he will roll its own.<br>=
</div></div></blockquote><div><br></div><div>What would be the motivating u=
se case for such a utility?</div><div><br></div><div>Without a compelling o=
ne, this would just represent more code to maintain without reason.</div><d=
iv>=C2=A0</div></div></div></blockquote><div><br></div><div>I only referrin=
g to name and possibility of &quot;misleading&quot;, if name explicitly mar=
k ordering mechanism, we will not imply that uuid have any natural order. E=
ach can have different tradeoffs and user can choose what he need or like.<=
br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"auto"><div dir=3D"auto"></div><div dir=3D"auto">One could a=
rgue that lexicographical ordering is not semantically sensical (a string b=
uilt up of arbitrary symbols that don&#39;t have much meaning on their own,=
 but still have a defined ordering by consensus just so we can find stuff e=
asier), but it&#39;s still used so heavily in the real world that its funct=
ionality is built in. We include it for booleans (equally nonsensical). And=
 I guarantee that the vast majority of overloads of operator&lt; are for co=
nvenience rather than any truly logical meaning.</div><div dir=3D"auto"><br=
></div><div dir=3D"auto">So the lazy side of me is winning over the pedanti=
c side. I definitely agree that ordering of UUIDs is nonsensical, but what =
it lacks in sense it more than makes up for in real world use.</div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
Es-EApvuCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"Es-EApvuCQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4e8d1fd8-3fae-4e0d-9b6c-b301850fc33d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/4e8d1fd8-3fae-4e0d-9b6c-b301850fc33d%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/4e8d1fd8-3fae-4e0d-9b6c-b301850fc33d%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4e8d1fd8-3fae-4e0d-<wbr>9b6c-=
b301850fc33d%40isocpp.org</a><wbr>.<br>
</blockquote></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1d9460e8-6ca6-4adb-a84d-fe92f28c9088%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1d9460e8-6ca6-4adb-a84d-fe92f28c9088=
%40isocpp.org</a>.<br />

------=_Part_59730_1457721032.1530830792285--

------=_Part_59729_458861947.1530830792284--

.

--0000000000007a47000570499aad
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 5, 2018 at 2:06 PM, Tony V E <tvaneerd@gmail.com> wrote:

> On Tue, Jul 3, 2018 at 12:48 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.co=
m
> > wrote:
>
>> On Tue, Jul 3, 2018 at 9:21 AM, Tony V E <tvaneerd@gmail.com> wrote:
>>
>>>
>>> If we only want map/set interop, then define a std::less<uuid>, not
>>> operator<.
>>>
>>
>> Please don't do this.
>> You should never explicitly specialize std::less<T> for any type, ever.
>> The primary reason is that it breaks all the user's expectations. The
>> secondary reason is that it won't always work! Heterogeneous containers =
use
>> std::less<>, not std::less<T>.
>>
>
> I mostly agree with you.  I'm all for "take back std::less".  But we
> already do this for std::complex, for example.
>

No, we don't =E2=80=94 nor should we.
https://en.cppreference.com/w/cpp/utility/functional/less
https://en.cppreference.com/w/cpp/header/complex
https://wandbox.org/permlink/Mz7hGl0P5k6nBWs4



> But I'd love a better answer - like fix map and set to call std::order
> when std::less doesn't work.  Or something like that.
>

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0181r1.html
is related, but is not being pursued at the moment.

=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0LAffwogzuSJzsY9SAscNtK%2BoZTvdEUpSzhvdVU0=
utY%2Bg%40mail.gmail.com.

--0000000000007a47000570499aad
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Jul 5, 2018 at 2:06 PM, Tony V E <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail=
..com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr">On Tue, Jul 3, 2018 at 12:48 PM,=
 Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D"mailto:arthur.j.odwyer=
@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.com</a>&gt;</span> wrot=
e:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"=
gmail-m_8480363031830693511gmail-"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span=
>On Tue, Jul 3, 2018 at 9:21 AM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"=
mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</sp=
an> wrote:</span><div class=3D"gmail_extra"><div class=3D"gmail_quote"><spa=
n><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div><br></div>If we only want map/set interop, then defin=
e a std::less&lt;uuid&gt;, not operator&lt;.</div></div></div></blockquote>=
<div><br></div></span><div>Please don&#39;t do this.</div><div>You should n=
ever explicitly specialize std::less&lt;T&gt; for any type, ever.=C2=A0 The=
 primary reason is that it breaks all the user&#39;s expectations. The seco=
ndary reason is that it won&#39;t always work! Heterogeneous containers use=
 std::less&lt;&gt;, not std::less&lt;T&gt;.</div></div></div></div></blockq=
uote><div><br></div></span><div>I mostly agree with you.=C2=A0 I&#39;m all =
for &quot;take back std::less&quot;.=C2=A0 But we already do this for std::=
complex, for example.</div></div></div></div></blockquote><div><br></div><d=
iv>No, we don&#39;t =E2=80=94 nor should we.</div><div><a href=3D"https://e=
n.cppreference.com/w/cpp/utility/functional/less" target=3D"_blank">https:/=
/en.cppreference.com/w/<wbr>cpp/utility/functional/less</a><br></div><div><=
a href=3D"https://en.cppreference.com/w/cpp/header/complex" target=3D"_blan=
k">https://en.cppreference.com/w/<wbr>cpp/header/complex</a><br></div><div>=
<a href=3D"https://wandbox.org/permlink/Mz7hGl0P5k6nBWs4" target=3D"_blank"=
>https://wandbox.org/permlink/<wbr>Mz7hGl0P5k6nBWs4</a><br></div><div><br><=
/div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-lef=
t-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><div></div><div>But I&#39;d love a b=
etter answer - like fix map and set to call std::order when std::less doesn=
&#39;t work.=C2=A0 Or something like that.</div></div></div></div></blockqu=
ote><div><br></div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/d=
ocs/papers/2016/p0181r1.html">http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2016/p0181r1.html</a><br></div><div>is related, but is not being purs=
ued at the moment.</div><div><br></div><div>=E2=80=93Arthur</div></div><br>=
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0LAffwogzuSJzsY9SAscNtK%2BoZTvd=
EUpSzhvdVU0utY%2Bg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0LAffwo=
gzuSJzsY9SAscNtK%2BoZTvdEUpSzhvdVU0utY%2Bg%40mail.gmail.com</a>.<br />

--0000000000007a47000570499aad--

.

------=_Part_75710_1260109005.1530841854912
Content-Type: multipart/alternative;
 boundary="----=_Part_75711_1568620357.1530841854912"

------=_Part_75711_1568620357.1530841854912
Content-Type: text/plain; charset="UTF-8"



On Thursday, July 5, 2018 at 5:06:11 PM UTC-4, Richard Hodges wrote:
>
>
>
> On Thu, 5 Jul 2018 at 22:55, <inkwizyt...@gmail.com <javascript:>> wrote:
>
>>
>>
>> On Thursday, July 5, 2018 at 7:24:13 PM UTC+2, Jake Arkinstall wrote:
>>>
>>> The pedant in me agrees that ordering of UUIDs is meaningless and that
>>> implementing it would be misleading and maybe even lend itself to abuse.
>>>
>>> The lazy part of me thinks that searching for a UUID will be in enough
>>> demand to justify the inclusion of ordering. Although a UUID is a wasteful
>>> key to use in terms of binary size (by definition of a UUID - it's big
>>> enough to prevent any collisions on a vast scale), it is still something
>>> that goes on a lot. It makes no sense for a user to have to implement this
>>> ordering themselves, so along this line of thought a uuid_order is
>>> justified.
>>>
>>> Or is it?
>>>
>>> Including a uuid_order operation is also misleading for the same reasons
>>> that an in-built ordering is, and providing it would just mean an
>>> unnecessary step for something that *we would be implicitly supporting *by
>>> including uuid_order in the first place.
>>>
>>>
>> But if it named `uuid_lexical_order` or `uuid_byte_order`? standard could
>> provide both or even more. User will chose best version that fit his goals
>> or he will roll its own.
>>
>
> What would be the motivating use case for such a utility?
>
> Without a compelling one, this would just represent more code to maintain
> without reason.
>

The reason to provide at least one of these is to make it easy to use
ordered containers without having to directly impose an ordering on the
type itself. Whether that's "compelling" is up to you.

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

------=_Part_75711_1568620357.1530841854912
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, July 5, 2018 at 5:06:11 PM UTC-4, Ric=
hard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, 5 Jul 2018=
 at 22:55, &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"Es-EApvuCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javas=
cript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;">inkwizyt...@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><br><br>On Thursday, July 5, 2018 at 7:24:13=
 PM UTC+2, Jake Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"auto">The pedant in me agrees that ordering of UUIDs is meaningle=
ss and that implementing it would be misleading and maybe even lend itself =
to abuse.<div dir=3D"auto"><br></div><div dir=3D"auto">The lazy part of me =
thinks that searching for a UUID will be in enough demand to justify the in=
clusion of ordering. Although a UUID is a wasteful key to use in terms of b=
inary size (by definition of a UUID - it&#39;s big enough to prevent any co=
llisions on a vast scale), it is still something that goes on a lot. It mak=
es no sense for a user to have to implement this ordering themselves, so al=
ong this line of thought a uuid_order is justified.</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">Or is it?</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">Including a uuid_order operation is also misleading for the s=
ame reasons that an in-built ordering is, and providing it would just mean =
an unnecessary step for something that <i>we would be implicitly supporting=
 </i>by including uuid_order in the first place.</div><div dir=3D"auto"><br=
></div></div></blockquote><div>=C2=A0</div><div>But if it named `uuid_lexic=
al_order` or `uuid_byte_order`? standard could provide both or even more. U=
ser will chose best version that fit his goals or he will roll its own.<br>=
</div></div></blockquote><div><br></div><div>What would be the motivating u=
se case for such a utility?</div><div><br></div><div>Without a compelling o=
ne, this would just represent more code to maintain without reason.</div></=
div></div></blockquote><div><br></div><div>The reason to provide at least o=
ne of these is to make it easy to use ordered containers without having to =
directly impose an ordering on the type itself. Whether that&#39;s &quot;co=
mpelling&quot; is up to you.</div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b394e385-1e67-4d1d-b1d4-cf983bb3886f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b394e385-1e67-4d1d-b1d4-cf983bb3886f=
%40isocpp.org</a>.<br />

------=_Part_75711_1568620357.1530841854912--

------=_Part_75710_1260109005.1530841854912--

.

------=_Part_75799_309344164.1530843485336
Content-Type: multipart/alternative;
 boundary="----=_Part_75800_827063453.1530843485336"

------=_Part_75800_827063453.1530843485336
Content-Type: text/plain; charset="UTF-8"

On Thursday, July 5, 2018 at 1:24:13 PM UTC-4, Jake Arkinstall wrote:
>
> The pedant in me agrees that ordering of UUIDs is meaningless and that
> implementing it would be misleading and maybe even lend itself to abuse.
>
> The lazy part of me thinks that searching for a UUID will be in enough
> demand to justify the inclusion of ordering. Although a UUID is a wasteful
> key to use in terms of binary size (by definition of a UUID - it's big
> enough to prevent any collisions on a vast scale), it is still something
> that goes on a lot. It makes no sense for a user to have to implement this
> ordering themselves, so along this line of thought a uuid_order is
> justified.
>
> Or is it?
>
> Including a uuid_order operation is also misleading for the same reasons
> that an in-built ordering is, and providing it would just mean an
> unnecessary step for something that *we would be implicitly supporting *by
> including uuid_order in the first place.
>

Why is it unnecessary? I genuinely do not understand what it is that's so
offensive to people's sensibilities to write `std::map<uuid, value,
uuid_order>`? Why is removing those 12 characters this important?

At present, our options are:

1. Define the type as fundamentally having an order, via `operator<=>`.
This is forces us to decide what ordering that will be, or worse, to make
it implementation-defined. The latter means it's really easy for a user to
accidentally rely on it, implicitly making their code non-portable.

2. Define no ordering whatsoever. This forces everyone who needs to use
them in ordered containers to write an ordering themselves.

3. Define no ordering for the type, but define at least one ordering
functor externally.

I don't see the point in preferring #1.

`uuid_order` is only as misleading as we want it to be. We can even provide
multiple different types of ordering (bytewise, integer-wise, etc), so that
the user can rely on it.

>
> One could argue that lexicographical ordering is not semantically sensical
> (a string built up of arbitrary symbols that don't have much meaning on
> their own, but still have a defined ordering by consensus just so we can
> find stuff easier), but it's still used so heavily in the real world that
> its functionality is built in. We include it for booleans (equally
> nonsensical). And I guarantee that the vast majority of overloads of
> operator< are for convenience rather than any truly logical meaning.
>

Well, as an example, the number of standard library types which have a
comparison operator that *isn't* merely forwarding the comparison to some
other type (`optional`, containers, etc) are actually fairly few. But even
among them, there are only a few dubious cases. Indeed, the only case of a
dubious `operator<` overload I can come up with is `error_code`.

Maybe other libraries are different; I haven't looked all that closely at
them.

Most of the time, if a type doesn't have a natural order, then you wouldn't
really want to use them as the key to an ordered container.

So the lazy side of me is winning over the pedantic side. I definitely
> agree that ordering of UUIDs is nonsensical, but what it lacks in sense it
> more than makes up for in real world use.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ce09ff5d-30ad-49ad-96c1-368c1d3c9aef%40isocpp.org.

------=_Part_75800_827063453.1530843485336
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, July 5, 2018 at 1:24:13 PM UTC-4, Jake Arkins=
tall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto">T=
he pedant in me agrees that ordering of UUIDs is meaningless and that imple=
menting it would be misleading and maybe even lend itself to abuse.<div dir=
=3D"auto"><br></div><div dir=3D"auto">The lazy part of me thinks that searc=
hing for a UUID will be in enough demand to justify the inclusion of orderi=
ng. Although a UUID is a wasteful key to use in terms of binary size (by de=
finition of a UUID - it&#39;s big enough to prevent any collisions on a vas=
t scale), it is still something that goes on a lot. It makes no sense for a=
 user to have to implement this ordering themselves, so along this line of =
thought a uuid_order is justified.</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">Or is it?</div><div dir=3D"auto"><br></div><div dir=3D"auto">Inc=
luding a uuid_order operation is also misleading for the same reasons that =
an in-built ordering is, and providing it would just mean an unnecessary st=
ep for something that <i>we would be implicitly supporting </i>by including=
 uuid_order in the first place.</div></div></blockquote><div><br></div><div=
>Why is it unnecessary? I genuinely do not understand what it is that&#39;s=
 so offensive to people&#39;s sensibilities to write `std::map&lt;uuid, val=
ue, uuid_order&gt;`? Why is removing those 12 characters this important?</d=
iv><div><br></div><div>At present, our options are:</div><div><br></div><di=
v>1. Define the type as fundamentally having an order, via `operator&lt;=3D=
&gt;`. This is forces us to decide what ordering that will be, or worse, to=
 make it implementation-defined. The latter means it&#39;s really easy for =
a user to accidentally rely on it, implicitly making their code non-portabl=
e.<br></div><div><br></div><div>2. Define no ordering whatsoever. This forc=
es everyone who needs to use them in ordered containers to write an orderin=
g themselves.</div><div><br></div><div>3. Define no ordering for the type, =
but define at least one ordering functor externally.</div><div><br></div><d=
iv>I don&#39;t see the point in preferring #1.</div><div><br></div><div>`uu=
id_order` is only as misleading as we want it to be. We can even provide mu=
ltiple different types of ordering (bytewise, integer-wise, etc), so that t=
he user can rely on it.<br></div>=C2=A0<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"auto"><div dir=3D"auto"></div><div dir=3D"auto">One co=
uld argue that lexicographical ordering is not semantically sensical (a str=
ing built up of arbitrary symbols that don&#39;t have much meaning on their=
 own, but still have a defined ordering by consensus just so we can find st=
uff easier), but it&#39;s still used so heavily in the real world that its =
functionality is built in. We include it for booleans (equally nonsensical)=
.. And I guarantee that the vast majority of overloads of operator&lt; are f=
or convenience rather than any truly logical meaning.</div></div></blockquo=
te><div><br></div><div>Well, as an example, the number of standard library =
types which have a comparison operator that <i>isn&#39;t</i> merely forward=
ing the comparison to some other type (`optional`, containers, etc) are act=
ually fairly few. But even among them, there are only a few dubious cases. =
Indeed, the only case of a dubious `operator&lt;` overload I can come up wi=
th is `error_code`.</div><div><br></div><div>Maybe other libraries are diff=
erent; I haven&#39;t looked all that closely at them.</div><div><br></div><=
div>Most of the time, if a type doesn&#39;t have a natural order, then you =
wouldn&#39;t really want to use them as the key to an ordered container.<br=
></div><div><br></div><div></div><div></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"auto"><div dir=3D"auto"></div><div dir=3D"auto">S=
o the lazy side of me is winning over the pedantic side. I definitely agree=
 that ordering of UUIDs is nonsensical, but what it lacks in sense it more =
than makes up for in real world use.</div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ce09ff5d-30ad-49ad-96c1-368c1d3c9aef%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ce09ff5d-30ad-49ad-96c1-368c1d3c9aef=
%40isocpp.org</a>.<br />

------=_Part_75800_827063453.1530843485336--

------=_Part_75799_309344164.1530843485336--

.

--00000000000066cca40570691fdd
Content-Type: text/plain; charset="UTF-8"

On Fri, 6 Jul 2018, 03:18 Nicol Bolas, <jmckesson@gmail.com> wrote:

> On Thursday, July 5, 2018 at 1:24:13 PM UTC-4, Jake Arkinstall wrote:
>>
>> The pedant in me agrees that ordering of UUIDs is meaningless and that
>> implementing it would be misleading and maybe even lend itself to abuse.
>>
>> The lazy part of me thinks that searching for a UUID will be in enough
>> demand to justify the inclusion of ordering. Although a UUID is a wasteful
>> key to use in terms of binary size (by definition of a UUID - it's big
>> enough to prevent any collisions on a vast scale), it is still something
>> that goes on a lot. It makes no sense for a user to have to implement this
>> ordering themselves, so along this line of thought a uuid_order is
>> justified.
>>
>> Or is it?
>>
>> Including a uuid_order operation is also misleading for the same reasons
>> that an in-built ordering is, and providing it would just mean an
>> unnecessary step for something that *we would be implicitly supporting *by
>> including uuid_order in the first place.
>>
>
> Why is it unnecessary? I genuinely do not understand what it is that's so
> offensive to people's sensibilities to write `std::map<uuid, value,
> uuid_order>`? Why is removing those 12 characters this important?
>
> At present, our options are:
>
> 1. Define the type as fundamentally having an order, via `operator<=>`.
> This is forces us to decide what ordering that will be, or worse, to make
> it implementation-defined. The latter means it's really easy for a user to
> accidentally rely on it, implicitly making their code non-portable.
>
> 2. Define no ordering whatsoever. This forces everyone who needs to use
> them in ordered containers to write an ordering themselves.
>
> 3. Define no ordering for the type, but define at least one ordering
> functor externally.
>
> I don't see the point in preferring #1.
>
> `uuid_order` is only as misleading as we want it to be. We can even
> provide multiple different types of ordering (bytewise, integer-wise, etc),
> so that the user can rely on it.
>

Specifying the mechanism of ordering has it backwards. There are two
comparisons the user may wish to use:

* a lexicographical ordering, for compatibility with external systems
* a fast ordering, for efficiency

That means that we should have two comparators: uuid_lexicographical_order
and uuid_fast_order. This would make the library discoverable and user
intent clear.


> One could argue that lexicographical ordering is not semantically sensical
>> (a string built up of arbitrary symbols that don't have much meaning on
>> their own, but still have a defined ordering by consensus just so we can
>> find stuff easier), but it's still used so heavily in the real world that
>> its functionality is built in. We include it for booleans (equally
>> nonsensical). And I guarantee that the vast majority of overloads of
>> operator< are for convenience rather than any truly logical meaning.
>>
>
> Well, as an example, the number of standard library types which have a
> comparison operator that *isn't* merely forwarding the comparison to some
> other type (`optional`, containers, etc) are actually fairly few. But even
> among them, there are only a few dubious cases. Indeed, the only case of a
> dubious `operator<` overload I can come up with is `error_code`.
>
> Maybe other libraries are different; I haven't looked all that closely at
> them.
>
> Most of the time, if a type doesn't have a natural order, then you
> wouldn't really want to use them as the key to an ordered container.
>
> So the lazy side of me is winning over the pedantic side. I definitely
>> agree that ordering of UUIDs is nonsensical, but what it lacks in sense it
>> more than makes up for in real world use.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/NjVdCCf0tlk/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ce09ff5d-30ad-49ad-96c1-368c1d3c9aef%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ce09ff5d-30ad-49ad-96c1-368c1d3c9aef%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

--00000000000066cca40570691fdd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Fri, 6 Jul 2018, 03:18 Nicol Bolas, &lt;<a href=3D"mailto:jmckesson@gmai=
l.com">jmckesson@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">On Thursday, July 5, 2018 at 1:24:13 PM UTC-4, Jake=
 Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"=
>The pedant in me agrees that ordering of UUIDs is meaningless and that imp=
lementing it would be misleading and maybe even lend itself to abuse.<div d=
ir=3D"auto"><br></div><div dir=3D"auto">The lazy part of me thinks that sea=
rching for a UUID will be in enough demand to justify the inclusion of orde=
ring. Although a UUID is a wasteful key to use in terms of binary size (by =
definition of a UUID - it&#39;s big enough to prevent any collisions on a v=
ast scale), it is still something that goes on a lot. It makes no sense for=
 a user to have to implement this ordering themselves, so along this line o=
f thought a uuid_order is justified.</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Or is it?</div><div dir=3D"auto"><br></div><div dir=3D"auto">I=
ncluding a uuid_order operation is also misleading for the same reasons tha=
t an in-built ordering is, and providing it would just mean an unnecessary =
step for something that <i>we would be implicitly supporting </i>by includi=
ng uuid_order in the first place.</div></div></blockquote><div><br></div><d=
iv>Why is it unnecessary? I genuinely do not understand what it is that&#39=
;s so offensive to people&#39;s sensibilities to write `std::map&lt;uuid, v=
alue, uuid_order&gt;`? Why is removing those 12 characters this important?<=
/div><div><br></div><div>At present, our options are:</div><div><br></div><=
div>1. Define the type as fundamentally having an order, via `operator&lt;=
=3D&gt;`. This is forces us to decide what ordering that will be, or worse,=
 to make it implementation-defined. The latter means it&#39;s really easy f=
or a user to accidentally rely on it, implicitly making their code non-port=
able.<br></div><div><br></div><div>2. Define no ordering whatsoever. This f=
orces everyone who needs to use them in ordered containers to write an orde=
ring themselves.</div><div><br></div><div>3. Define no ordering for the typ=
e, but define at least one ordering functor externally.</div><div><br></div=
><div>I don&#39;t see the point in preferring #1.</div><div><br></div><div>=
`uuid_order` is only as misleading as we want it to be. We can even provide=
 multiple different types of ordering (bytewise, integer-wise, etc), so tha=
t the user can rely on it.<br></div></div></blockquote></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Specifying the mechanism of ordering =
has it backwards. There are two comparisons the user may wish to use:</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">* a lexicographical ordering,=
 for compatibility with external systems</div><div dir=3D"auto">* a fast or=
dering, for efficiency</div><div dir=3D"auto"><br></div><div dir=3D"auto">T=
hat means that we should have two comparators: uuid_lexicographical_order a=
nd uuid_fast_order. This would make the library discoverable and user inten=
t clear.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div clas=
s=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"></di=
v><div dir=3D"auto">One could argue that lexicographical ordering is not se=
mantically sensical (a string built up of arbitrary symbols that don&#39;t =
have much meaning on their own, but still have a defined ordering by consen=
sus just so we can find stuff easier), but it&#39;s still used so heavily i=
n the real world that its functionality is built in. We include it for bool=
eans (equally nonsensical). And I guarantee that the vast majority of overl=
oads of operator&lt; are for convenience rather than any truly logical mean=
ing.</div></div></blockquote><div><br></div><div>Well, as an example, the n=
umber of standard library types which have a comparison operator that <i>is=
n&#39;t</i> merely forwarding the comparison to some other type (`optional`=
, containers, etc) are actually fairly few. But even among them, there are =
only a few dubious cases. Indeed, the only case of a dubious `operator&lt;`=
 overload I can come up with is `error_code`.</div><div><br></div><div>Mayb=
e other libraries are different; I haven&#39;t looked all that closely at t=
hem.</div><div><br></div><div>Most of the time, if a type doesn&#39;t have =
a natural order, then you wouldn&#39;t really want to use them as the key t=
o an ordered container.<br></div><div><br></div><div></div><div></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"></di=
v><div dir=3D"auto">So the lazy side of me is winning over the pedantic sid=
e. I definitely agree that ordering of UUIDs is nonsensical, but what it la=
cks in sense it more than makes up for in real world use.</div></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/NjVdCCf0tlk/unsubscribe" target=3D"_blan=
k" rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/NjVdCCf0tlk/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" target=3D"_blank" rel=3D"n=
oreferrer">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" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ce09ff5d-30ad-49ad-96c1-368c1d3c9aef%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/ce09ff5d-30ad-49ad-96c1-368c1d3c9aef%40isocpp.org</a>.<br>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY5bxK6LH8ZzqOyS43_NKWF1LKDtkKR=
Dod7ongzgghqKg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY5bxK6LH8Z=
zqOyS43_NKWF1LKDtkKRDod7ongzgghqKg%40mail.gmail.com</a>.<br />

--00000000000066cca40570691fdd--

.

--000000000000da97ec0571bb8bbc
Content-Type: text/plain; charset="UTF-8"

I did not realize the discussion continued of a second thread (after 100
replies, I guess that must be some limit), so somehow I missed the things
that have been discussed here.

When I wrote the proposal I mentioned that comparing uuids does not make
logical sense. However, due to their nature as identifiers, they will be
used in places where ordering is required. Because of that, I believe the
standard should provide a mechanism for ordering uuids. Sure, users can
write that for themselves if need be but why should we force so many people
do that every time? I really dislike having to do so. For instance, how
many times did people write a function to convert a string to upper/lower
case? Was it so hard to make one available in the standard? Yes, sure,
that's one more thing to maintain in the ever growing standard but things
like this can make a difference.

Having said that and getting back to the summarized opinions:

At present, our options are:
> 1. Define the type as fundamentally having an order, via `operator<=>`.
> This is forces us to decide what ordering that will be, or worse, to make
> it implementation-defined. The latter means it's really easy for a user to
> accidentally rely on it, implicitly making their code non-portable.
> 2. Define no ordering whatsoever. This forces everyone who needs to use
> them in ordered containers to write an ordering themselves.
> 3. Define no ordering for the type, but define at least one ordering
> functor externally.
> I don't see the point in preferring #1.
> `uuid_order` is only as misleading as we want it to be. We can even
> provide multiple different types of ordering (bytewise, integer-wise, etc),
> so that the user can rely on it.
>
> and


> That means that we should have two comparators: uuid_lexicographical_order
> and uuid_fast_order. This would make the library discoverable and user
> intent clear.


I strongly favor this later proposal for having two ordering functors,
uuid_lexicographical_order and uuid_fast_order. I see no problem in writing
std::map<uuid, value, uuid_fast_order> but I do see a problem in having to
define my ordering functor every time I need this.

On Sat, Jul 7, 2018 at 4:54 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

>
>
> On Fri, 6 Jul 2018, 03:18 Nicol Bolas, <jmckesson@gmail.com> wrote:
>
>> On Thursday, July 5, 2018 at 1:24:13 PM UTC-4, Jake Arkinstall wrote:
>>>
>>> The pedant in me agrees that ordering of UUIDs is meaningless and that
>>> implementing it would be misleading and maybe even lend itself to abuse.
>>>
>>> The lazy part of me thinks that searching for a UUID will be in enough
>>> demand to justify the inclusion of ordering. Although a UUID is a wasteful
>>> key to use in terms of binary size (by definition of a UUID - it's big
>>> enough to prevent any collisions on a vast scale), it is still something
>>> that goes on a lot. It makes no sense for a user to have to implement this
>>> ordering themselves, so along this line of thought a uuid_order is
>>> justified.
>>>
>>> Or is it?
>>>
>>> Including a uuid_order operation is also misleading for the same reasons
>>> that an in-built ordering is, and providing it would just mean an
>>> unnecessary step for something that *we would be implicitly supporting *by
>>> including uuid_order in the first place.
>>>
>>
>> Why is it unnecessary? I genuinely do not understand what it is that's so
>> offensive to people's sensibilities to write `std::map<uuid, value,
>> uuid_order>`? Why is removing those 12 characters this important?
>>
>> At present, our options are:
>>
>> 1. Define the type as fundamentally having an order, via `operator<=>`.
>> This is forces us to decide what ordering that will be, or worse, to make
>> it implementation-defined. The latter means it's really easy for a user to
>> accidentally rely on it, implicitly making their code non-portable.
>>
>> 2. Define no ordering whatsoever. This forces everyone who needs to use
>> them in ordered containers to write an ordering themselves.
>>
>> 3. Define no ordering for the type, but define at least one ordering
>> functor externally.
>>
>> I don't see the point in preferring #1.
>>
>> `uuid_order` is only as misleading as we want it to be. We can even
>> provide multiple different types of ordering (bytewise, integer-wise, etc),
>> so that the user can rely on it.
>>
>
> Specifying the mechanism of ordering has it backwards. There are two
> comparisons the user may wish to use:
>
> * a lexicographical ordering, for compatibility with external systems
> * a fast ordering, for efficiency
>
> That means that we should have two comparators: uuid_lexicographical_order
> and uuid_fast_order. This would make the library discoverable and user
> intent clear.
>
>
>> One could argue that lexicographical ordering is not semantically
>>> sensical (a string built up of arbitrary symbols that don't have much
>>> meaning on their own, but still have a defined ordering by consensus just
>>> so we can find stuff easier), but it's still used so heavily in the real
>>> world that its functionality is built in. We include it for booleans
>>> (equally nonsensical). And I guarantee that the vast majority of overloads
>>> of operator< are for convenience rather than any truly logical meaning.
>>>
>>
>> Well, as an example, the number of standard library types which have a
>> comparison operator that *isn't* merely forwarding the comparison to
>> some other type (`optional`, containers, etc) are actually fairly few. But
>> even among them, there are only a few dubious cases. Indeed, the only case
>> of a dubious `operator<` overload I can come up with is `error_code`.
>>
>> Maybe other libraries are different; I haven't looked all that closely at
>> them.
>>
>> Most of the time, if a type doesn't have a natural order, then you
>> wouldn't really want to use them as the key to an ordered container.
>>
>> So the lazy side of me is winning over the pedantic side. I definitely
>>> agree that ordering of UUIDs is nonsensical, but what it lacks in sense it
>>> more than makes up for in real world use.
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit https://groups.google.com/a/
>> isocpp.org/d/topic/std-proposals/NjVdCCf0tlk/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/
>> isocpp.org/d/msgid/std-proposals/ce09ff5d-30ad-49ad-
>> 96c1-368c1d3c9aef%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ce09ff5d-30ad-49ad-96c1-368c1d3c9aef%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAJnLdOY5bxK6LH8ZzqOyS43_
> NKWF1LKDtkKRDod7ongzgghqKg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY5bxK6LH8ZzqOyS43_NKWF1LKDtkKRDod7ongzgghqKg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

--000000000000da97ec0571bb8bbc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I did not realize the discussion continued of a second thr=
ead (after 100 replies, I guess that must be some limit), so somehow I miss=
ed the things that have been discussed here.<div><br></div><div>When I wrot=
e the proposal I mentioned that comparing uuids=C2=A0does not make logical =
sense. However, due to their nature as identifiers, they will be used in pl=
aces where ordering is required. Because of that, I believe the standard sh=
ould provide a mechanism for ordering uuids. Sure, users can write that for=
 themselves if need be but why should we force so many people do that every=
 time? I really dislike having to do so. For instance, how many times did p=
eople write a function to convert a string to upper/lower case? Was it so h=
ard to make one available in the standard? Yes, sure, that&#39;s one more t=
hing to maintain in the ever growing standard but things like this can make=
 a difference.</div><div><br></div><div>Having said that and getting back t=
o the summarized opinions:</div><div><br></div><div><blockquote style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex" class=3D"gmail_quote">At present, our options are:<br>1. Define the ty=
pe as fundamentally having an order, via `operator&lt;=3D&gt;`. This is for=
ces us to decide what ordering that will be, or worse, to make it implement=
ation-defined. The latter means it&#39;s really easy for a user to accident=
ally rely on it, implicitly making their code non-portable.<br>2. Define no=
 ordering whatsoever. This forces everyone who needs to use them in ordered=
 containers to write an ordering themselves.<br>3. Define no ordering for t=
he type, but define at least one ordering functor externally.<br>I don&#39;=
t see the point in preferring #1.<br>`uuid_order` is only as misleading as =
we want it to be. We can even provide multiple different types of ordering =
(bytewise, integer-wise, etc), so that the user can rely on it.<br><br></bl=
ockquote><div>and=C2=A0</div><div>=C2=A0</div><blockquote style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" c=
lass=3D"gmail_quote"><span style=3D"color:rgb(34,34,34);font-family:arial,s=
ans-serif;font-size:16px;font-style:normal;font-variant-ligatures:normal;fo=
nt-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:sta=
rt;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;=
background-color:rgb(255,255,255);text-decoration-style:initial;text-decora=
tion-color:initial;float:none;display:inline">That means that we should hav=
e two comparators: uuid_lexicographical_order and uuid_fast_order. This wou=
ld make the library discoverable and user intent clear.</span></blockquote>=
</div><div><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;=
font-size:16px;font-style:normal;font-variant-ligatures:normal;font-variant=
-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-in=
dent:0px;text-transform:none;white-space:normal;word-spacing:0px;background=
-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color=
:initial;float:none;display:inline"><br></span></div><div><span style=3D"co=
lor:rgb(34,34,34);font-family:arial,sans-serif;font-style:normal;font-varia=
nt-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing=
:normal;text-align:start;text-indent:0px;text-transform:none;white-space:no=
rmal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-sty=
le:initial;text-decoration-color:initial;float:none;display:inline">I stron=
gly favor this later proposal for having two ordering functors, uuid_lexico=
graphical_order and uuid_fast_order. I see no problem in writing std::map&l=
t;uuid, value, uuid_fast_order&gt; but I do see a problem in having to defi=
ne my ordering functor every time I need this.</span></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Jul 7, 2018 at 4:54=
 PM, &#39;Edward Catmur&#39; via ISO C++ Standard - Future Proposals <span =
dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blan=
k">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"auto"><span class=3D""><div><br><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr">On Fri, 6 Jul 2018, 03:18 Nicol Bolas, &lt;<a hre=
f=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&=
gt; wrote:<br></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">On Thur=
sday, July 5, 2018 at 1:24:13 PM UTC-4, Jake Arkinstall wrote:<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"auto">The pedant in me agrees that o=
rdering of UUIDs is meaningless and that implementing it would be misleadin=
g and maybe even lend itself to abuse.<div dir=3D"auto"><br></div><div dir=
=3D"auto">The lazy part of me thinks that searching for a UUID will be in e=
nough demand to justify the inclusion of ordering. Although a UUID is a was=
teful key to use in terms of binary size (by definition of a UUID - it&#39;=
s big enough to prevent any collisions on a vast scale), it is still someth=
ing that goes on a lot. It makes no sense for a user to have to implement t=
his ordering themselves, so along this line of thought a uuid_order is just=
ified.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Or is it?</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">Including a uuid_order operatio=
n is also misleading for the same reasons that an in-built ordering is, and=
 providing it would just mean an unnecessary step for something that <i>we =
would be implicitly supporting </i>by including uuid_order in the first pla=
ce.</div></div></blockquote><div><br></div><div>Why is it unnecessary? I ge=
nuinely do not understand what it is that&#39;s so offensive to people&#39;=
s sensibilities to write `std::map&lt;uuid, value, uuid_order&gt;`? Why is =
removing those 12 characters this important?</div><div><br></div><div>At pr=
esent, our options are:</div><div><br></div><div>1. Define the type as fund=
amentally having an order, via `operator&lt;=3D&gt;`. This is forces us to =
decide what ordering that will be, or worse, to make it implementation-defi=
ned. The latter means it&#39;s really easy for a user to accidentally rely =
on it, implicitly making their code non-portable.<br></div><div><br></div><=
div>2. Define no ordering whatsoever. This forces everyone who needs to use=
 them in ordered containers to write an ordering themselves.</div><div><br>=
</div><div>3. Define no ordering for the type, but define at least one orde=
ring functor externally.</div><div><br></div><div>I don&#39;t see the point=
 in preferring #1.</div><div><br></div><div>`uuid_order` is only as mislead=
ing as we want it to be. We can even provide multiple different types of or=
dering (bytewise, integer-wise, etc), so that the user can rely on it.<br><=
/div></div></blockquote></div></div><div dir=3D"auto"><br></div></span><div=
 dir=3D"auto">Specifying the mechanism of ordering has it backwards. There =
are two comparisons the user may wish to use:</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">* a lexicographical ordering, for compatibility with =
external systems</div><div dir=3D"auto">* a fast ordering, for efficiency</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">That means that we should=
 have two comparators: uuid_lexicographical_order and uuid_fast_order. This=
 would make the library discoverable and user intent clear.=C2=A0</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><span class=3D""><div dir=3D"ltr"><br><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"></div><div =
dir=3D"auto">One could argue that lexicographical ordering is not semantica=
lly sensical (a string built up of arbitrary symbols that don&#39;t have mu=
ch meaning on their own, but still have a defined ordering by consensus jus=
t so we can find stuff easier), but it&#39;s still used so heavily in the r=
eal world that its functionality is built in. We include it for booleans (e=
qually nonsensical). And I guarantee that the vast majority of overloads of=
 operator&lt; are for convenience rather than any truly logical meaning.</d=
iv></div></blockquote><div><br></div><div>Well, as an example, the number o=
f standard library types which have a comparison operator that <i>isn&#39;t=
</i> merely forwarding the comparison to some other type (`optional`, conta=
iners, etc) are actually fairly few. But even among them, there are only a =
few dubious cases. Indeed, the only case of a dubious `operator&lt;` overlo=
ad I can come up with is `error_code`.</div><div><br></div><div>Maybe other=
 libraries are different; I haven&#39;t looked all that closely at them.</d=
iv><div><br></div><div>Most of the time, if a type doesn&#39;t have a natur=
al order, then you wouldn&#39;t really want to use them as the key to an or=
dered container.<br></div><div><br></div><div></div><div></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"auto"><div dir=3D"auto"></div><div =
dir=3D"auto">So the lazy side of me is winning over the pedantic side. I de=
finitely agree that ordering of UUIDs is nonsensical, but what it lacks in =
sense it more than makes up for in real world use.</div></div>
</blockquote></div>

<p></p>

-- <br></span>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/NjVdCCf0tlk/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/topic/s=
td-<wbr>proposals/NjVdCCf0tlk/<wbr>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" rel=3D"noreferrer" target=
=3D"_blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<span class=3D"">=
<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" rel=3D"noreferrer" target=3D"_blank">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ce09ff5d-30ad-49ad-96c1-368c1d3c9aef%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer"=
 target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/ce09ff5d-30ad-49ad-<wbr>96c1-368c1d3c9aef%40isocpp.org</a><w=
br>.<br>
</span></blockquote></div></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY5bxK6LH8ZzqOyS43_NKWF1LKDtkKR=
Dod7ongzgghqKg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CAJnLdOY5bxK6LH8ZzqOyS43_<wbr>NKWF1LKDtkKRDod7ongzgghqK=
g%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxGVW4wjdGDFE93a5_mRmcYTPWMSM=
o6DpbvzRYyLYAu3Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxGVW4w=
jdGDFE93a5_mRmcYTPWMSMo6DpbvzRYyLYAu3Q%40mail.gmail.com</a>.<br />

--000000000000da97ec0571bb8bbc--

.

On 07/24/18 12:39, Marius Bancila wrote:
> I did not realize the discussion continued of a second thread (after 100=
=20
> replies, I guess that must be some limit), so somehow I missed the=20
> things that have been discussed here.
>=20
> When I wrote the proposal I mentioned that comparing uuids=C2=A0does not =
make=20
> logical sense. However, due to their nature as identifiers, they will be=
=20
> used in places where ordering is required. Because of that, I believe=20
> the standard should provide a mechanism for ordering uuids. Sure, users=
=20
> can write that for themselves if need be but why should we force so many=
=20
> people do that every time? I really dislike having to do so. For=20
> instance, how many times did people write a function to convert a string=
=20
> to upper/lower case? Was it so hard to make one available in the=20
> standard? Yes, sure, that's one more thing to maintain in the ever=20
> growing standard but things like this can make a difference.
>=20
> Having said that and getting back to the summarized opinions:
>=20
>     At present, our options are:
>     1. Define the type as fundamentally having an order, via
>     `operator<=3D>`. This is forces us to decide what ordering that will
>     be, or worse, to make it implementation-defined. The latter means
>     it's really easy for a user to accidentally rely on it, implicitly
>     making their code non-portable.
>     2. Define no ordering whatsoever. This forces everyone who needs to
>     use them in ordered containers to write an ordering themselves.
>     3. Define no ordering for the type, but define at least one ordering
>     functor externally.
>     I don't see the point in preferring #1.
>     `uuid_order` is only as misleading as we want it to be. We can even
>     provide multiple different types of ordering (bytewise,
>     integer-wise, etc), so that the user can rely on it.
>=20
> and
>=20
>     That means that we should have two comparators:
>     uuid_lexicographical_order and uuid_fast_order. This would make the
>     library discoverable and user intent clear.
>=20
>=20
> I strongly favor this later proposal for having two ordering functors,=20
> uuid_lexicographical_order and uuid_fast_order. I see no problem in=20
> writing std::map<uuid, value, uuid_fast_order> but I do see a problem in=
=20
> having to define my ordering functor every time I need this.

I don't like to have to explicitly write the ordering predicate every=20
time I need to sort or use uuid in an associative container. I'm sure,=20
many people will want std::map<uuid, foo> to "just work". It does "just=20
work" in other languages, why not C++?

What is the problem in defining ordering operators as maintaining an=20
unspecified strict order of uuids? In my practice, this is exactly what=20
I want most of the time if not always, i.e. I want *some* order=20
(preferably, fast) and I don't care which. If I want some particular=20
order then at that point I will consider writing my own ordering=20
predicate and being explicit about it. Additional points to std if the=20
standard library provides it out of the box, but that is not necessary=20
and probably not worth putting into the proposal.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f60b2e32-e322-1fc0-4182-5775fb89bf86%40gmail.com=
..

.

------=_Part_9569_1660118658.1532445278171
Content-Type: multipart/alternative;
 boundary="----=_Part_9570_619965640.1532445278172"

------=_Part_9570_619965640.1532445278172
Content-Type: text/plain; charset="UTF-8"

On Tuesday, July 24, 2018 at 6:05:48 AM UTC-4, Andrey Semashev wrote:
>
> On 07/24/18 12:39, Marius Bancila wrote:
> > I did not realize the discussion continued of a second thread (after 100
> > replies, I guess that must be some limit), so somehow I missed the
> > things that have been discussed here.
> >
> > When I wrote the proposal I mentioned that comparing uuids does not make
> > logical sense. However, due to their nature as identifiers, they will be
> > used in places where ordering is required. Because of that, I believe
> > the standard should provide a mechanism for ordering uuids. Sure, users
> > can write that for themselves if need be but why should we force so many
> > people do that every time? I really dislike having to do so. For
> > instance, how many times did people write a function to convert a string
> > to upper/lower case? Was it so hard to make one available in the
> > standard? Yes, sure, that's one more thing to maintain in the ever
> > growing standard but things like this can make a difference.
> >
> > Having said that and getting back to the summarized opinions:
> >
> >     At present, our options are:
> >     1. Define the type as fundamentally having an order, via
> >     `operator<=>`. This is forces us to decide what ordering that will
> >     be, or worse, to make it implementation-defined. The latter means
> >     it's really easy for a user to accidentally rely on it, implicitly
> >     making their code non-portable.
> >     2. Define no ordering whatsoever. This forces everyone who needs to
> >     use them in ordered containers to write an ordering themselves.
> >     3. Define no ordering for the type, but define at least one ordering
> >     functor externally.
> >     I don't see the point in preferring #1.
> >     `uuid_order` is only as misleading as we want it to be. We can even
> >     provide multiple different types of ordering (bytewise,
> >     integer-wise, etc), so that the user can rely on it.
> >
> > and
> >
> >     That means that we should have two comparators:
> >     uuid_lexicographical_order and uuid_fast_order. This would make the
> >     library discoverable and user intent clear.
> >
> >
> > I strongly favor this later proposal for having two ordering functors,
> > uuid_lexicographical_order and uuid_fast_order. I see no problem in
> > writing std::map<uuid, value, uuid_fast_order> but I do see a problem in
> > having to define my ordering functor every time I need this.
>
> I don't like to have to explicitly write the ordering predicate every
> time I need to sort or use uuid in an associative container. I'm sure,
> many people will want std::map<uuid, foo> to "just work". It does "just
> work" in other languages, why not C++?
>

Then just write a simple alias:

template<typename Value, typename Allocator = std::allocator<T>>
using uuid_map = std::map<uuid, Value, lexicographical_order, Allocator>;

Requiring explicit specification is not an onerous burden.

What is the problem in defining ordering operators as maintaining an
> unspecified strict order of uuids?


Because the ordering is *unspecified*. That basically invites users to rely
on the ordering of their particular implementation, thus making it easy to
write code that fails on other implementations. Remember: many users won't
know that the order is unspecified; they just know what their
compiler/standard library provides for their platform of interest. Users
don't read documentation; they will assume that the order they get is well
defined.

If the options are "require explicit specification" or "default is
unspecified", I'll take "require explicit specification" any day of the
week. At least then, there's no chance of user screwups.

In my practice, this is exactly what
> I want most of the time if not always, i.e. I want *some* order
> (preferably, fast) and I don't care which. If I want some particular
> order then at that point I will consider writing my own ordering
> predicate and being explicit about it. Additional points to std if the
> standard library provides it out of the box, but that is not necessary
> and probably not worth putting into the proposal.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ee6eedfc-1f14-454c-b155-38766d1d706b%40isocpp.org.

------=_Part_9570_619965640.1532445278172
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, July 24, 2018 at 6:05:48 AM UTC-4, Andrey Sema=
shev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 07/24/18 12:39, =
Marius Bancila wrote:
<br>&gt; I did not realize the discussion continued of a second thread (aft=
er 100=20
<br>&gt; replies, I guess that must be some limit), so somehow I missed the=
=20
<br>&gt; things that have been discussed here.
<br>&gt;=20
<br>&gt; When I wrote the proposal I mentioned that comparing uuids=C2=A0do=
es not make=20
<br>&gt; logical sense. However, due to their nature as identifiers, they w=
ill be=20
<br>&gt; used in places where ordering is required. Because of that, I beli=
eve=20
<br>&gt; the standard should provide a mechanism for ordering uuids. Sure, =
users=20
<br>&gt; can write that for themselves if need be but why should we force s=
o many=20
<br>&gt; people do that every time? I really dislike having to do so. For=
=20
<br>&gt; instance, how many times did people write a function to convert a =
string=20
<br>&gt; to upper/lower case? Was it so hard to make one available in the=
=20
<br>&gt; standard? Yes, sure, that&#39;s one more thing to maintain in the =
ever=20
<br>&gt; growing standard but things like this can make a difference.
<br>&gt;=20
<br>&gt; Having said that and getting back to the summarized opinions:
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 At present, our options are:
<br>&gt; =C2=A0 =C2=A0 1. Define the type as fundamentally having an order,=
 via
<br>&gt; =C2=A0 =C2=A0 `operator&lt;=3D&gt;`. This is forces us to decide w=
hat ordering that will
<br>&gt; =C2=A0 =C2=A0 be, or worse, to make it implementation-defined. The=
 latter means
<br>&gt; =C2=A0 =C2=A0 it&#39;s really easy for a user to accidentally rely=
 on it, implicitly
<br>&gt; =C2=A0 =C2=A0 making their code non-portable.
<br>&gt; =C2=A0 =C2=A0 2. Define no ordering whatsoever. This forces everyo=
ne who needs to
<br>&gt; =C2=A0 =C2=A0 use them in ordered containers to write an ordering =
themselves.
<br>&gt; =C2=A0 =C2=A0 3. Define no ordering for the type, but define at le=
ast one ordering
<br>&gt; =C2=A0 =C2=A0 functor externally.
<br>&gt; =C2=A0 =C2=A0 I don&#39;t see the point in preferring #1.
<br>&gt; =C2=A0 =C2=A0 `uuid_order` is only as misleading as we want it to =
be. We can even
<br>&gt; =C2=A0 =C2=A0 provide multiple different types of ordering (bytewi=
se,
<br>&gt; =C2=A0 =C2=A0 integer-wise, etc), so that the user can rely on it.
<br>&gt;=20
<br>&gt; and
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 That means that we should have two comparators:
<br>&gt; =C2=A0 =C2=A0 uuid_lexicographical_order and uuid_fast_order. This=
 would make the
<br>&gt; =C2=A0 =C2=A0 library discoverable and user intent clear.
<br>&gt;=20
<br>&gt;=20
<br>&gt; I strongly favor this later proposal for having two ordering funct=
ors,=20
<br>&gt; uuid_lexicographical_order and uuid_fast_order. I see no problem i=
n=20
<br>&gt; writing std::map&lt;uuid, value, uuid_fast_order&gt; but I do see =
a problem in=20
<br>&gt; having to define my ordering functor every time I need this.
<br>
<br>I don&#39;t like to have to explicitly write the ordering predicate eve=
ry=20
<br>time I need to sort or use uuid in an associative container. I&#39;m su=
re,=20
<br>many people will want std::map&lt;uuid, foo&gt; to &quot;just work&quot=
;. It does &quot;just=20
<br>work&quot; in other languages, why not C++?<br></blockquote><div><br></=
div><div>Then just write a simple alias:</div><div><br></div><div style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"p=
rettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Value</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">Allocator</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">allocator</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&gt;&gt;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">using</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> uuid_map </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">ma=
p</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">uuid</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Value</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> lexicographical_order</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Allocator</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&gt;;</span></div></code></div><div><br></div><div>Requiri=
ng explicit specification is not an onerous burden.</div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">
What is the problem in defining ordering operators as maintaining an=20
<br>unspecified strict order of uuids?</blockquote><div><br></div><div>Beca=
use the ordering is <i>unspecified</i>. That basically invites users to rel=
y on the ordering of their particular implementation, thus making it easy t=
o write code that fails on other implementations. Remember: many users won&=
#39;t know that the order is unspecified; they just know what their compile=
r/standard library provides for their platform of interest. Users don&#39;t=
 read documentation; they will assume that the order they get is well defin=
ed.<br></div><div><br></div><div>If the options are &quot;require explicit =
specification&quot; or &quot;default is unspecified&quot;, I&#39;ll take &q=
uot;require explicit specification&quot; any day of the week. At least then=
, there&#39;s no chance of user screwups.<br></div><div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">In my practice, this is exactly what=20
<br>I want most of the time if not always, i.e. I want *some* order=20
<br>(preferably, fast) and I don&#39;t care which. If I want some particula=
r=20
<br>order then at that point I will consider writing my own ordering=20
<br>predicate and being explicit about it. Additional points to std if the=
=20
<br>standard library provides it out of the box, but that is not necessary=
=20
<br>and probably not worth putting into the proposal.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ee6eedfc-1f14-454c-b155-38766d1d706b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ee6eedfc-1f14-454c-b155-38766d1d706b=
%40isocpp.org</a>.<br />

------=_Part_9570_619965640.1532445278172--

------=_Part_9569_1660118658.1532445278171--

.

On 07/24/18 18:14, Nicol Bolas wrote:
> On Tuesday, July 24, 2018 at 6:05:48 AM UTC-4, Andrey Semashev wrote:
>=20
>     On 07/24/18 12:39, Marius Bancila wrote:
>      > I did not realize the discussion continued of a second thread
>     (after 100
>      > replies, I guess that must be some limit), so somehow I missed the
>      > things that have been discussed here.
>      >
>      > When I wrote the proposal I mentioned that comparing uuids=C2=A0do=
es
>     not make
>      > logical sense. However, due to their nature as identifiers, they
>     will be
>      > used in places where ordering is required. Because of that, I
>     believe
>      > the standard should provide a mechanism for ordering uuids. Sure,
>     users
>      > can write that for themselves if need be but why should we force
>     so many
>      > people do that every time? I really dislike having to do so. For
>      > instance, how many times did people write a function to convert a
>     string
>      > to upper/lower case? Was it so hard to make one available in the
>      > standard? Yes, sure, that's one more thing to maintain in the ever
>      > growing standard but things like this can make a difference.
>      >
>      > Having said that and getting back to the summarized opinions:
>      >
>      > =C2=A0 =C2=A0 At present, our options are:
>      > =C2=A0 =C2=A0 1. Define the type as fundamentally having an order,=
 via
>      > =C2=A0 =C2=A0 `operator<=3D>`. This is forces us to decide what or=
dering that
>     will
>      > =C2=A0 =C2=A0 be, or worse, to make it implementation-defined. The=
 latter
>     means
>      > =C2=A0 =C2=A0 it's really easy for a user to accidentally rely on =
it,
>     implicitly
>      > =C2=A0 =C2=A0 making their code non-portable.
>      > =C2=A0 =C2=A0 2. Define no ordering whatsoever. This forces everyo=
ne who
>     needs to
>      > =C2=A0 =C2=A0 use them in ordered containers to write an ordering =
themselves.
>      > =C2=A0 =C2=A0 3. Define no ordering for the type, but define at le=
ast one
>     ordering
>      > =C2=A0 =C2=A0 functor externally.
>      > =C2=A0 =C2=A0 I don't see the point in preferring #1.
>      > =C2=A0 =C2=A0 `uuid_order` is only as misleading as we want it to =
be. We
>     can even
>      > =C2=A0 =C2=A0 provide multiple different types of ordering (bytewi=
se,
>      > =C2=A0 =C2=A0 integer-wise, etc), so that the user can rely on it.
>      >
>      > and
>      >
>      > =C2=A0 =C2=A0 That means that we should have two comparators:
>      > =C2=A0 =C2=A0 uuid_lexicographical_order and uuid_fast_order. This=
 would
>     make the
>      > =C2=A0 =C2=A0 library discoverable and user intent clear.
>      >
>      >
>      > I strongly favor this later proposal for having two ordering
>     functors,
>      > uuid_lexicographical_order and uuid_fast_order. I see no problem i=
n
>      > writing std::map<uuid, value, uuid_fast_order> but I do see a
>     problem in
>      > having to define my ordering functor every time I need this.
>=20
>     I don't like to have to explicitly write the ordering predicate every
>     time I need to sort or use uuid in an associative container. I'm sure=
,
>     many people will want std::map<uuid, foo> to "just work". It does "ju=
st
>     work" in other languages, why not C++?
>=20
>=20
> Then just write a simple alias:
>=20
> |
> template<typenameValue,typenameAllocator=3Dstd::allocator<T>>
> usinguuid_map =3Dstd::map<uuid,Value,lexicographical_order,Allocator>;
> |
>=20
> Requiring explicit specification is not an onerous burden.

I think it is. I don't see the rationale why I should be required to=20
write workarounds like this.

>     What is the problem in defining ordering operators as maintaining an
>     unspecified strict order of uuids?
>=20
> Because the ordering is /unspecified/. That basically invites users to=20
> rely on the ordering of their particular implementation, thus making it=
=20
> easy to write code that fails on other implementations.

I disagree. We don't rely on ordering of std::type_info, why would we do=20
so for uuid?

> Remember: many=20
> users won't know that the order is unspecified; they just know what=20
> their compiler/standard library provides for their platform of interest.=
=20
> Users don't read documentation; they will assume that the order they get=
=20
> is well defined.

There will always be novices and mistakes due to lack of knowledge. I=20
don't consider that a reason enough for penalizing everyone and forcing=20
to explicitly write ordering predicate.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/db42a68b-473b-0102-5e68-f38148636829%40gmail.com=
..

.

--000000000000ca6c680571c08298
Content-Type: text/plain; charset="UTF-8"

I really think the answer for all this is a way to have:

Criteria:
- no < operator (or <=> etc)
- (thus) no std::less
- map "just works"

My thoughts so far are either:

A. map checks whether std::less "works" for the given type (this requires
some convoluted template stuff, but it can hide inside map and std::less),
and if std::less doesn't work, something else (ie std::order) is
substituted.  std::order would probably default to compiler generated
memberwise lexicographical order

or

B. The type (ie uuid) would define a internal typedef uuid::order than map
would look for.  This is more of an "opt-in" hack.  (And thus uuid::order
would need a less-likely name, ie uuid::order_for_map).  std::map would use
K::order by default, or only when std::less doesn't compile. Something like
that.

or

C. something else.

But the criteria at the top are, I think, what we want.


On Tue, Jul 24, 2018 at 11:26 AM, Andrey Semashev <andrey.semashev@gmail.com
> wrote:

> On 07/24/18 18:14, Nicol Bolas wrote:
>
>> On Tuesday, July 24, 2018 at 6:05:48 AM UTC-4, Andrey Semashev wrote:
>>
>>     On 07/24/18 12:39, Marius Bancila wrote:
>>      > I did not realize the discussion continued of a second thread
>>     (after 100
>>      > replies, I guess that must be some limit), so somehow I missed the
>>      > things that have been discussed here.
>>      >
>>      > When I wrote the proposal I mentioned that comparing uuids does
>>     not make
>>      > logical sense. However, due to their nature as identifiers, they
>>     will be
>>      > used in places where ordering is required. Because of that, I
>>     believe
>>      > the standard should provide a mechanism for ordering uuids. Sure,
>>     users
>>      > can write that for themselves if need be but why should we force
>>     so many
>>      > people do that every time? I really dislike having to do so. For
>>      > instance, how many times did people write a function to convert a
>>     string
>>      > to upper/lower case? Was it so hard to make one available in the
>>      > standard? Yes, sure, that's one more thing to maintain in the ever
>>      > growing standard but things like this can make a difference.
>>      >
>>      > Having said that and getting back to the summarized opinions:
>>      >
>>      >     At present, our options are:
>>      >     1. Define the type as fundamentally having an order, via
>>      >     `operator<=>`. This is forces us to decide what ordering that
>>     will
>>      >     be, or worse, to make it implementation-defined. The latter
>>     means
>>      >     it's really easy for a user to accidentally rely on it,
>>     implicitly
>>      >     making their code non-portable.
>>      >     2. Define no ordering whatsoever. This forces everyone who
>>     needs to
>>      >     use them in ordered containers to write an ordering themselves.
>>      >     3. Define no ordering for the type, but define at least one
>>     ordering
>>      >     functor externally.
>>      >     I don't see the point in preferring #1.
>>      >     `uuid_order` is only as misleading as we want it to be. We
>>     can even
>>      >     provide multiple different types of ordering (bytewise,
>>      >     integer-wise, etc), so that the user can rely on it.
>>      >
>>      > and
>>      >
>>      >     That means that we should have two comparators:
>>      >     uuid_lexicographical_order and uuid_fast_order. This would
>>     make the
>>      >     library discoverable and user intent clear.
>>      >
>>      >
>>      > I strongly favor this later proposal for having two ordering
>>     functors,
>>      > uuid_lexicographical_order and uuid_fast_order. I see no problem in
>>      > writing std::map<uuid, value, uuid_fast_order> but I do see a
>>     problem in
>>      > having to define my ordering functor every time I need this.
>>
>>     I don't like to have to explicitly write the ordering predicate every
>>     time I need to sort or use uuid in an associative container. I'm sure,
>>     many people will want std::map<uuid, foo> to "just work". It does
>> "just
>>     work" in other languages, why not C++?
>>
>>
>> Then just write a simple alias:
>>
>> |
>> template<typenameValue,typenameAllocator=std::allocator<T>>
>> usinguuid_map =std::map<uuid,Value,lexicographical_order,Allocator>;
>> |
>>
>> Requiring explicit specification is not an onerous burden.
>>
>
> I think it is. I don't see the rationale why I should be required to write
> workarounds like this.
>
>     What is the problem in defining ordering operators as maintaining an
>>     unspecified strict order of uuids?
>>
>> Because the ordering is /unspecified/. That basically invites users to
>> rely on the ordering of their particular implementation, thus making it
>> easy to write code that fails on other implementations.
>>
>
> I disagree. We don't rely on ordering of std::type_info, why would we do
> so for uuid?
>
> Remember: many users won't know that the order is unspecified; they just
>> know what their compiler/standard library provides for their platform of
>> interest. Users don't read documentation; they will assume that the order
>> they get is well defined.
>>
>
> There will always be novices and mistakes due to lack of knowledge. I
> don't consider that a reason enough for penalizing everyone and forcing to
> explicitly write ordering predicate.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/db42a68b-473b-0102-5e68-
> f38148636829%40gmail.com.
>



--
Be seeing you,
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbis67xyCg73bbaHdbY4-v%3D1pq6MgUbiNt_jCXbC62x%3DTYg%40mail.gmail.com.

--000000000000ca6c680571c08298
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I really think the answer for all this is a way to ha=
ve:</div><div><br></div><div>Criteria:<br></div><div>- no &lt; operator (or=
 &lt;=3D&gt; etc)</div><div>- (thus) no std::less</div><div>- map &quot;jus=
t works&quot;</div><div><br></div><div>My thoughts so far are either:</div>=
<div><br></div><div>A. map checks whether std::less &quot;works&quot; for t=
he given type (this requires some convoluted template stuff, but it can hid=
e inside map and std::less),</div><div>and if std::less doesn&#39;t work, s=
omething else (ie std::order) is substituted.=C2=A0 std::order would probab=
ly default to compiler generated memberwise lexicographical order<br></div>=
<div><br></div><div>or</div><div><br></div><div>B. The type (ie uuid) would=
 define a internal typedef uuid::order than map would look for.=C2=A0 This =
is more of an &quot;opt-in&quot; hack.=C2=A0 (And thus uuid::order would ne=
ed a less-likely name, ie uuid::order_for_map).=C2=A0 std::map would use K:=
:order by default, or only when std::less doesn&#39;t compile. Something li=
ke that.<br></div><div><br></div><div>or</div><div><br></div><div>C. someth=
ing else.</div><div><br></div><div>But the criteria at the top are, I think=
, what we want.<br></div><div><br></div><div><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote">On Tue, Jul 24, 2018 at 11:26 AM, Andrey Semash=
ev <span dir=3D"ltr">&lt;<a href=3D"mailto:andrey.semashev@gmail.com" targe=
t=3D"_blank">andrey.semashev@gmail.com</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 07/24/18 18:=
14, Nicol Bolas wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Tuesday, July 24, 2018 at 6:05:48 AM UTC-4, Andrey Semashev wrote:<br>
<br>
=C2=A0 =C2=A0 On 07/24/18 12:39, Marius Bancila wrote:<br>
=C2=A0 =C2=A0 =C2=A0&gt; I did not realize the discussion continued of a se=
cond thread<br>
=C2=A0 =C2=A0 (after 100<br>
=C2=A0 =C2=A0 =C2=A0&gt; replies, I guess that must be some limit), so some=
how I missed the<br>
=C2=A0 =C2=A0 =C2=A0&gt; things that have been discussed here.<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 =C2=A0&gt; When I wrote the proposal I mentioned that compari=
ng uuids=C2=A0does<br>
=C2=A0 =C2=A0 not make<br>
=C2=A0 =C2=A0 =C2=A0&gt; logical sense. However, due to their nature as ide=
ntifiers, they<br>
=C2=A0 =C2=A0 will be<br>
=C2=A0 =C2=A0 =C2=A0&gt; used in places where ordering is required. Because=
 of that, I<br>
=C2=A0 =C2=A0 believe<br>
=C2=A0 =C2=A0 =C2=A0&gt; the standard should provide a mechanism for orderi=
ng uuids. Sure,<br>
=C2=A0 =C2=A0 users<br>
=C2=A0 =C2=A0 =C2=A0&gt; can write that for themselves if need be but why s=
hould we force<br>
=C2=A0 =C2=A0 so many<br>
=C2=A0 =C2=A0 =C2=A0&gt; people do that every time? I really dislike having=
 to do so. For<br>
=C2=A0 =C2=A0 =C2=A0&gt; instance, how many times did people write a functi=
on to convert a<br>
=C2=A0 =C2=A0 string<br>
=C2=A0 =C2=A0 =C2=A0&gt; to upper/lower case? Was it so hard to make one av=
ailable in the<br>
=C2=A0 =C2=A0 =C2=A0&gt; standard? Yes, sure, that&#39;s one more thing to =
maintain in the ever<br>
=C2=A0 =C2=A0 =C2=A0&gt; growing standard but things like this can make a d=
ifference.<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 =C2=A0&gt; Having said that and getting back to the summarize=
d opinions:<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 At present, our options are:<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 1. Define the type as fundamentally =
having an order, via<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 `operator&lt;=3D&gt;`. This is force=
s us to decide what ordering that<br>
=C2=A0 =C2=A0 will<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 be, or worse, to make it implementat=
ion-defined. The latter<br>
=C2=A0 =C2=A0 means<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 it&#39;s really easy for a user to a=
ccidentally rely on it,<br>
=C2=A0 =C2=A0 implicitly<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 making their code non-portable.<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 2. Define no ordering whatsoever. Th=
is forces everyone who<br>
=C2=A0 =C2=A0 needs to<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 use them in ordered containers to wr=
ite an ordering themselves.<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 3. Define no ordering for the type, =
but define at least one<br>
=C2=A0 =C2=A0 ordering<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 functor externally.<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 I don&#39;t see the point in preferr=
ing #1.<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 `uuid_order` is only as misleading a=
s we want it to be. We<br>
=C2=A0 =C2=A0 can even<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 provide multiple different types of =
ordering (bytewise,<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 integer-wise, etc), so that the user=
 can rely on it.<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 =C2=A0&gt; and<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 That means that we should have two c=
omparators:<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 uuid_lexicographical_order and uuid_=
fast_order. This would<br>
=C2=A0 =C2=A0 make the<br>
=C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 library discoverable and user intent=
 clear.<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 =C2=A0&gt;<br>
=C2=A0 =C2=A0 =C2=A0&gt; I strongly favor this later proposal for having tw=
o ordering<br>
=C2=A0 =C2=A0 functors,<br>
=C2=A0 =C2=A0 =C2=A0&gt; uuid_lexicographical_order and uuid_fast_order. I =
see no problem in<br>
=C2=A0 =C2=A0 =C2=A0&gt; writing std::map&lt;uuid, value, uuid_fast_order&g=
t; but I do see a<br>
=C2=A0 =C2=A0 problem in<br>
=C2=A0 =C2=A0 =C2=A0&gt; having to define my ordering functor every time I =
need this.<br>
<br>
=C2=A0 =C2=A0 I don&#39;t like to have to explicitly write the ordering pre=
dicate every<br>
=C2=A0 =C2=A0 time I need to sort or use uuid in an associative container. =
I&#39;m sure,<br>
=C2=A0 =C2=A0 many people will want std::map&lt;uuid, foo&gt; to &quot;just=
 work&quot;. It does &quot;just<br>
=C2=A0 =C2=A0 work&quot; in other languages, why not C++?<br>
<br>
<br>
Then just write a simple alias:<br>
<br>
|<br>
template&lt;typenameValue,typenam<wbr>eAllocator=3Dstd::allocator&lt;T&gt;&=
gt;<br>
usinguuid_map =3Dstd::map&lt;uuid,Value,lexicogra<wbr>phical_order,Allocato=
r&gt;;<br>
|<br>
<br>
Requiring explicit specification is not an onerous burden.<br>
</blockquote>
<br></div></div>
I think it is. I don&#39;t see the rationale why I should be required to wr=
ite workarounds like this.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><span class=3D"">
=C2=A0 =C2=A0 What is the problem in defining ordering operators as maintai=
ning an<br>
=C2=A0 =C2=A0 unspecified strict order of uuids?<br>
<br></span>
Because the ordering is /unspecified/. That basically invites users to rely=
 on the ordering of their particular implementation, thus making it easy to=
 write code that fails on other implementations.<br>
</blockquote>
<br>
I disagree. We don&#39;t rely on ordering of std::type_info, why would we d=
o so for uuid?<span class=3D""><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Remember: many users won&#39;t know that the order is unspecified; they jus=
t know what their compiler/standard library provides for their platform of =
interest. Users don&#39;t read documentation; they will assume that the ord=
er they get is well defined.<br>
</blockquote>
<br></span>
There will always be novices and mistakes due to lack of knowledge. I don&#=
39;t consider that a reason enough for penalizing everyone and forcing to e=
xplicitly write ordering predicate.<span class=3D""><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/db42a68b-473b-0102-5e68-f38148636829%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/db42a68b-473b-0102-5e68-<wbr>=
f38148636829%40gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbis67xyCg73bbaHdbY4-v%3D1pq6MgUb=
iNt_jCXbC62x%3DTYg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbis67xyC=
g73bbaHdbY4-v%3D1pq6MgUbiNt_jCXbC62x%3DTYg%40mail.gmail.com</a>.<br />

--000000000000ca6c680571c08298--

.

On 2018-07-24 05:39, Marius Bancila wrote:
> For instance, how
> many times did people write a function to convert a string to upper/lower
> case?

Completely off topic, but... how many times did they do it wrong? ;-)

> Was it so hard to make one available in the standard?

Yes. Because text is *hard*, and you get all sorts of nasty cases like
"=C3=9F" =E2=86=92 "SS". (And... I could continue, but this has nothing to =
do with
UUID's :-).)

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e7f8c302-3484-67ae-7cf5-22af2501325f%40gmail.com=
..

.

------=_Part_9250_1895714553.1532447474841
Content-Type: multipart/alternative;
 boundary="----=_Part_9251_1362719994.1532447474841"

------=_Part_9251_1362719994.1532447474841
Content-Type: text/plain; charset="UTF-8"



On Tuesday, July 24, 2018 at 11:35:27 AM UTC-4, Tony V E wrote:
>
> I really think the answer for all this is a way to have:
>
> Criteria:
> - no < operator (or <=> etc)
> - (thus) no std::less
> - map "just works"
>

I assume you mean "just works without an explicit comparison functor".

Personally, I *don't* want that. If a type is not comparable, that means
you *should* have to explicitly provide a comparison functor. This is in
fact why ordered containers take functors. It seems decidedly incoherent to
say that `T` is not comparable but `T` has some innate ordering that
ordered containers will use.

If an ordering is good enough to be used by default for ordered containers,
then it's good enough to be used by `operator<`. And if it isn't good
enough for the latter, then it's not good enough for the former.

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

------=_Part_9251_1362719994.1532447474841
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, July 24, 2018 at 11:35:27 AM UTC-4, To=
ny V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>I really think the answer for all this is a way to have:</div><div><br=
></div><div>Criteria:<br></div><div>- no &lt; operator (or &lt;=3D&gt; etc)=
</div><div>- (thus) no std::less</div><div>- map &quot;just works&quot;</di=
v></div></blockquote><div><br></div><div>I assume you mean &quot;just works=
 without an explicit comparison functor&quot;.<br></div><div><br></div><div=
>Personally, I <i>don&#39;t</i> want that. If a type is not comparable, tha=
t means you <i>should</i> have to explicitly provide a comparison functor. =
This is in fact why ordered containers take functors. It seems decidedly in=
coherent to say that `T` is not comparable but `T` has some innate ordering=
 that ordered containers will use.</div><div><br></div><div>If an ordering =
is good enough to be used by default for ordered containers, then it&#39;s =
good enough to be used by `operator&lt;`. And if it isn&#39;t good enough f=
or the latter, then it&#39;s not good enough for the former.</div><br></div=
>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fae4e5f1-60bc-4018-872a-8e6d5708f3c2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fae4e5f1-60bc-4018-872a-8e6d5708f3c2=
%40isocpp.org</a>.<br />

------=_Part_9251_1362719994.1532447474841--

------=_Part_9250_1895714553.1532447474841--

.

------=_Part_9442_1434031420.1532448360708
Content-Type: multipart/alternative;
 boundary="----=_Part_9443_1246618077.1532448360709"

------=_Part_9443_1246618077.1532448360709
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Le mardi 24 juillet 2018 17:51:14 UTC+2, Nicol Bolas a =C3=A9crit :
>
>
>
> On Tuesday, July 24, 2018 at 11:35:27 AM UTC-4, Tony V E wrote:
>>
>> I really think the answer for all this is a way to have:
>>
>> Criteria:
>> - no < operator (or <=3D> etc)
>> - (thus) no std::less
>> - map "just works"
>>
>
> I assume you mean "just works without an explicit comparison functor".
>
> Personally, I *don't* want that. If a type is not comparable, that means=
=20
> you *should* have to explicitly provide a comparison functor. This is in=
=20
> fact why ordered containers take functors. It seems decidedly incoherent =
to=20
> say that `T` is not comparable but `T` has some innate ordering that=20
> ordered containers will use.
>
> If an ordering is good enough to be used by default for ordered=20
> containers, then it's good enough to be used by `operator<`. And if it=20
> isn't good enough for the latter, then it's not good enough for the forme=
r.
>
>
I completely disagree with you here. It is really easy to create some=20
mathematics objects where you can have trivial total order, but where such=
=20
an order has no mathematical meaning.
I give you a few on them: complex numbers, vectors or matrices.

Having an arbitrary order that has no real meaning is interesting because=
=20
then, you can use binary search on them.
Why couldn't you use binary search on std::complex<float>, while you could=
=20
on std::pair<float, float>?

The situation is even simpler with uuids as there is no IEEE 754 arithmetic=
=20
complexity (floats are not totally ordered, and testing equality on them is=
=20
usually buggy).
So I understand why std::map<float, Value> is not authorized, but I don't=
=20
understand why std::map<std::uuid, Value> shouldn't be authorized.

To summarize, I would say we have two types of order: the semantic order,=
=20
the one accessible with the operators =3D=3D, !=3D, <, <=3D, >, >=3D, and a=
=20
(hopefully total) arbitrary order that can be used in std::map/std::set,=20
testing uniqueness...

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e20f106e-7075-4308-a716-41f88e9c0990%40isocpp.or=
g.

------=_Part_9443_1246618077.1532448360709
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Le mardi 24 juillet 2018 17:51:14 UTC+2, Nicol Bol=
as a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><br>On Tuesday, July 24, 2018 at 11:35:27 AM UTC-4, Tony V E w=
rote:<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>I really=
 think the answer for all this is a way to have:</div><div><br></div><div>C=
riteria:<br></div><div>- no &lt; operator (or &lt;=3D&gt; etc)</div><div>- =
(thus) no std::less</div><div>- map &quot;just works&quot;</div></div></blo=
ckquote><div><br></div><div>I assume you mean &quot;just works without an e=
xplicit comparison functor&quot;.<br></div><div><br></div><div>Personally, =
I <i>don&#39;t</i> want that. If a type is not comparable, that means you <=
i>should</i> have to explicitly provide a comparison functor. This is in fa=
ct why ordered containers take functors. It seems decidedly incoherent to s=
ay that `T` is not comparable but `T` has some innate ordering that ordered=
 containers will use.</div><div><br></div><div>If an ordering is good enoug=
h to be used by default for ordered containers, then it&#39;s good enough t=
o be used by `operator&lt;`. And if it isn&#39;t good enough for the latter=
, then it&#39;s not good enough for the former.</div><br></div></blockquote=
><div><br></div><div>I completely disagree with you here. It is really easy=
 to create some mathematics objects where you can have trivial total order,=
 but where such an order has no mathematical meaning.</div><div>I give you =
a few on them: complex numbers, vectors or matrices.</div><div><br></div><d=
iv>Having an arbitrary order that has no real meaning is interesting becaus=
e then, you can use binary search on them.</div><div>Why couldn&#39;t you u=
se binary search on std::complex&lt;float&gt;, while you could on std::pair=
&lt;float, float&gt;?</div><div><br></div><div>The situation is even simple=
r with uuids as there is no IEEE 754 arithmetic complexity (floats are not =
totally ordered, and testing equality on them is usually buggy).</div><div>=
So I understand why std::map&lt;float, Value&gt; is not authorized, but I d=
on&#39;t understand why std::map&lt;std::uuid, Value&gt; shouldn&#39;t be a=
uthorized.</div><div><br></div><div>To summarize, I would say we have two t=
ypes of order: the semantic order, the one accessible with the operators =
=3D=3D, !=3D, &lt;, &lt;=3D, &gt;, &gt;=3D, and a (hopefully total) arbitra=
ry order that can be used in std::map/std::set, testing uniqueness...<br></=
div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e20f106e-7075-4308-a716-41f88e9c0990%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e20f106e-7075-4308-a716-41f88e9c0990=
%40isocpp.org</a>.<br />

------=_Part_9443_1246618077.1532448360709--

------=_Part_9442_1434031420.1532448360708--

.

On 07/24/18 18:35, Tony V E wrote:
> I really think the answer for all this is a way to have:
>=20
> Criteria:
> - no < operator (or <=3D> etc)
> - (thus) no std::less
> - map "just works"
>=20
> My thoughts so far are either:
>=20
> A. map checks whether std::less "works" for the given type (this=20
> requires some convoluted template stuff, but it can hide inside map and=
=20
> std::less),
> and if std::less doesn't work, something else (ie std::order) is=20
> substituted.=C2=A0 std::order would probably default to compiler generate=
d=20
> memberwise lexicographical order
>=20
> or
>=20
> B. The type (ie uuid) would define a internal typedef uuid::order than=20
> map would look for.=C2=A0 This is more of an "opt-in" hack.=C2=A0 (And th=
us=20
> uuid::order would need a less-likely name, ie uuid::order_for_map). =20
> std::map would use K::order by default, or only when std::less doesn't=20
> compile. Something like that.
>=20
> or
>=20
> C. something else.
>=20
> But the criteria at the top are, I think, what we want.

Personally, it looks like over-engineering to me. This approach=20
introduces a new customization point, which does not seem necessary. Or=20
a bit of magic in the interaction between map and uuid, which is worse.=20
IMHO, just defining the ordering operator for uuids and reusing the=20
existing infrastructure is the right way to go as it provides the most=20
benefit and causes the least surprise to users.

However, I always preferred naming my ordering predicates as=20
something_order or something like that instead of something_less because=20
ordering rarely has anything to do with one element being somehow less=20
or greater than the other. So I would be in favor of a general=20
nomenclature change from "comparing elements for less/greater" to=20
"imposing an order between elements", with comparison being just a=20
default case.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/cc10566a-9c47-489e-1a7b-be364b07045e%40gmail.com=
..

.

--000000000000b987100571c10880
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 24, 2018 at 5:06 PM, <florian.csdt@gmail.com> wrote:

>
>
> Le mardi 24 juillet 2018 17:51:14 UTC+2, Nicol Bolas a =C3=A9crit :
>>
>>
>>
>> On Tuesday, July 24, 2018 at 11:35:27 AM UTC-4, Tony V E wrote:
>>>
>>> I really think the answer for all this is a way to have:
>>>
>>> Criteria:
>>> - no < operator (or <=3D> etc)
>>> - (thus) no std::less
>>> - map "just works"
>>>
>>
>> I assume you mean "just works without an explicit comparison functor".
>>
>> Personally, I *don't* want that. If a type is not comparable, that means
>> you *should* have to explicitly provide a comparison functor. This is in
>> fact why ordered containers take functors. It seems decidedly incoherent=
 to
>> say that `T` is not comparable but `T` has some innate ordering that
>> ordered containers will use.
>>
>> If an ordering is good enough to be used by default for ordered
>> containers, then it's good enough to be used by `operator<`. And if it
>> isn't good enough for the latter, then it's not good enough for the form=
er.
>>
>>
> I completely disagree with you here. It is really easy to create some
> mathematics objects where you can have trivial total order, but where suc=
h
> an order has no mathematical meaning.
> I give you a few on them: complex numbers, vectors or matrices.
>
> Having an arbitrary order that has no real meaning is interesting because
> then, you can use binary search on them.
> Why couldn't you use binary search on std::complex<float>, while you coul=
d
> on std::pair<float, float>?
>
> The situation is even simpler with uuids as there is no IEEE 754
> arithmetic complexity (floats are not totally ordered, and testing equali=
ty
> on them is usually buggy).
> So I understand why std::map<float, Value> is not authorized, but I don't
> understand why std::map<std::uuid, Value> shouldn't be authorized.
>
> To summarize, I would say we have two types of order: the semantic order,
> the one accessible with the operators =3D=3D, !=3D, <, <=3D, >, >=3D, and=
 a
> (hopefully total) arbitrary order that can be used in std::map/std::set,
> testing uniqueness...
>


Totally agree, if Java can find a way to compare UUIDs then C++ *must* too,
otherwise this proposal may as well be rejected.
https://docs.oracle.com/javase/9/docs/api/java/util/UUID.html#compareTo-jav=
a.util.UUID-

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFQaeCAqmrWkzzcrd5PvOuacV921ZvjX-ATckMdL_5SN_cL=
C2g%40mail.gmail.com.

--000000000000b987100571c10880
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 Tue, Jul 24, 2018 at 5:06 PM,  <span dir=3D"ltr">&lt;<a href=3D"mail=
to:florian.csdt@gmail.com" target=3D"_blank">florian.csdt@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-=
width:1px;border-left-style:solid"><div dir=3D"ltr"><span><br><br>Le mardi =
24 juillet 2018 17:51:14 UTC+2, Nicol Bolas a =C3=A9crit=C2=A0:<blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;bo=
rder-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:so=
lid"><div dir=3D"ltr"><br><br>On Tuesday, July 24, 2018 at 11:35:27 AM UTC-=
4, Tony V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-=
width:1px;border-left-style:solid"><div dir=3D"ltr"><div>I really think the=
 answer for all this is a way to have:</div><div><br></div><div>Criteria:<b=
r></div><div>- no &lt; operator (or &lt;=3D&gt; etc)</div><div>- (thus) no =
std::less</div><div>- map &quot;just works&quot;</div></div></blockquote><d=
iv><br></div><div>I assume you mean &quot;just works without an explicit co=
mparison functor&quot;.<br></div><div><br></div><div>Personally, I <i>don&#=
39;t</i> want that. If a type is not comparable, that means you <i>should</=
i> have to explicitly provide a comparison functor. This is in fact why ord=
ered containers take functors. It seems decidedly incoherent to say that `T=
` is not comparable but `T` has some innate ordering that ordered container=
s will use.</div><div><br></div><div>If an ordering is good enough to be us=
ed by default for ordered containers, then it&#39;s good enough to be used =
by `operator&lt;`. And if it isn&#39;t good enough for the latter, then it&=
#39;s not good enough for the former.</div><br></div></blockquote><div><br>=
</div></span><div>I completely disagree with you here. It is really easy to=
 create some mathematics objects where you can have trivial total order, bu=
t where such an order has no mathematical meaning.</div><div>I give you a f=
ew on them: complex numbers, vectors or matrices.</div><div><br></div><div>=
Having an arbitrary order that has no real meaning is interesting because t=
hen, you can use binary search on them.</div><div>Why couldn&#39;t you use =
binary search on std::complex&lt;float&gt;, while you could on std::pair&lt=
;float, float&gt;?</div><div><br></div><div>The situation is even simpler w=
ith uuids as there is no IEEE 754 arithmetic complexity (floats are not tot=
ally ordered, and testing equality on them is usually buggy).</div><div>So =
I understand why std::map&lt;float, Value&gt; is not authorized, but I don&=
#39;t understand why std::map&lt;std::uuid, Value&gt; shouldn&#39;t be auth=
orized.</div><div><br></div><div>To summarize, I would say we have two type=
s of order: the semantic order, the one accessible with the operators =3D=
=3D, !=3D, &lt;, &lt;=3D, &gt;, &gt;=3D, and a (hopefully total) arbitrary =
order that can be used in std::map/std::set, testing uniqueness...<br></div=
></div></blockquote><div><br></div><div><br></div><div>Totally agree, if Ja=
va can find a way to compare UUIDs then C++ *must* too, otherwise this prop=
osal may as well be rejected.<br><a href=3D"https://docs.oracle.com/javase/=
9/docs/api/java/util/UUID.html#compareTo-java.util.UUID-">https://docs.orac=
le.com/javase/9/docs/api/java/util/UUID.html#compareTo-java.util.UUID-</a><=
/div><div><br></div><div>=C2=A0</div></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAqmrWkzzcrd5PvOuacV921ZvjX-ATc=
kMdL_5SN_cLC2g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAqmrWkzzcr=
d5PvOuacV921ZvjX-ATckMdL_5SN_cLC2g%40mail.gmail.com</a>.<br />

--000000000000b987100571c10880--

.

------=_Part_9079_2108961164.1532450116441
Content-Type: multipart/alternative;
 boundary="----=_Part_9080_1593269151.1532450116442"

------=_Part_9080_1593269151.1532450116442
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tuesday, July 24, 2018 at 12:06:00 PM UTC-4, floria...@gmail.com wrote:
>
> Le mardi 24 juillet 2018 17:51:14 UTC+2, Nicol Bolas a =C3=A9crit :
>>
>> On Tuesday, July 24, 2018 at 11:35:27 AM UTC-4, Tony V E wrote:
>>>
>>> I really think the answer for all this is a way to have:
>>>
>>> Criteria:
>>> - no < operator (or <=3D> etc)
>>> - (thus) no std::less
>>> - map "just works"
>>>
>>
>> I assume you mean "just works without an explicit comparison functor".
>>
>> Personally, I *don't* want that. If a type is not comparable, that means=
=20
>> you *should* have to explicitly provide a comparison functor. This is in=
=20
>> fact why ordered containers take functors. It seems decidedly incoherent=
 to=20
>> say that `T` is not comparable but `T` has some innate ordering that=20
>> ordered containers will use.
>>
>> If an ordering is good enough to be used by default for ordered=20
>> containers, then it's good enough to be used by `operator<`. And if it=
=20
>> isn't good enough for the latter, then it's not good enough for the form=
er.
>>
>>
> I completely disagree with you here. It is really easy to create some=20
> mathematics objects where you can have trivial total order, but where suc=
h=20
> an order has no mathematical meaning.=20
>
I give you a few on them: complex numbers, vectors or matrices.
>
> Having an arbitrary order that has no real meaning is interesting because=
=20
> then, you can use binary search on them.
> Why couldn't you use binary search on std::complex<float>, while you coul=
d=20
> on std::pair<float, float>?
>

And if we had a type that represented a binary searchable collection=20
*without* also being explicitly ordered, that might be fine. However,=20
ordered containers are ordered *containers*. Such containers store a range=
=20
of values with the given order. You can iterate over that range in the=20
given order, thus directly tying the behavior of your code to that order.

So long as user code can rely on the "given order" for such collections,=20
making that "given order" be unspecified is just asking for trouble. Having=
=20
a type where using certain interfaces yields unspecified results is not=20
good. *Especially* by default.

For floats where comparison is valid, `map<float, Value>` will always=20
provide consistent results across all of its interfaces. What you want is=
=20
for `map<uuid, Value>` to provide consistent results across it's=20
query-by-Key interface, but for its container interface, the results can be=
=20
inconsistent.

That is not a good thing.

The situation is even simpler with uuids as there is no IEEE 754 arithmetic=
=20
> complexity (floats are not totally ordered, and testing equality on them =
is=20
> usually buggy).
> So I understand why std::map<float, Value> is not authorized, but I don't=
=20
> understand why std::map<std::uuid, Value> shouldn't be authorized.
>
> To summarize, I would say we have two types of order: the semantic order,=
=20
> the one accessible with the operators =3D=3D, !=3D, <, <=3D, >, >=3D, and=
 a=20
> (hopefully total) arbitrary order that can be used in std::map/std::set,=
=20
> testing uniqueness...
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/450a5c6b-b058-43f5-8970-ba35cde663fe%40isocpp.or=
g.

------=_Part_9080_1593269151.1532450116442
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, July 24, 2018 at 12:06:00 PM UTC-4, floria...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">Le mardi 24 juillet 2018 17:51:14 UTC+2, Nicol Bolas a =C3=A9crit=C2=A0:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, July 2=
4, 2018 at 11:35:27 AM UTC-4, Tony V E wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div>I really think the answer for all this is a=
 way to have:</div><div><br></div><div>Criteria:<br></div><div>- no &lt; op=
erator (or &lt;=3D&gt; etc)</div><div>- (thus) no std::less</div><div>- map=
 &quot;just works&quot;</div></div></blockquote><div><br></div><div>I assum=
e you mean &quot;just works without an explicit comparison functor&quot;.<b=
r></div><div><br></div><div>Personally, I <i>don&#39;t</i> want that. If a =
type is not comparable, that means you <i>should</i> have to explicitly pro=
vide a comparison functor. This is in fact why ordered containers take func=
tors. It seems decidedly incoherent to say that `T` is not comparable but `=
T` has some innate ordering that ordered containers will use.</div><div><br=
></div><div>If an ordering is good enough to be used by default for ordered=
 containers, then it&#39;s good enough to be used by `operator&lt;`. And if=
 it isn&#39;t good enough for the latter, then it&#39;s not good enough for=
 the former.</div><br></div></blockquote><div><br></div><div>I completely d=
isagree with you here. It is really easy to create some mathematics objects=
 where you can have trivial total order, but where such an order has no mat=
hematical meaning. <br></div></div></blockquote><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div>I give you a few on them: complex n=
umbers, vectors or matrices.</div><div><br></div><div>Having an arbitrary o=
rder that has no real meaning is interesting because then, you can use bina=
ry search on them.</div><div>Why couldn&#39;t you use binary search on std:=
:complex&lt;float&gt;, while you could on std::pair&lt;float, float&gt;?</d=
iv></div></blockquote><div><br></div><div>And if we had a type that represe=
nted a binary searchable collection <i>without</i> also being explicitly or=
dered, that might be fine. However, ordered containers are ordered <i>conta=
iners</i>. Such containers store a range of values with the given order. Yo=
u can iterate over that range in the given order, thus directly tying the b=
ehavior of your code to that order.</div><div><br></div><div>So long as use=
r code can rely on the &quot;given order&quot; for such collections, making=
 that &quot;given order&quot; be unspecified is just asking for trouble. Ha=
ving a type where using certain interfaces yields unspecified results is no=
t good. <i>Especially</i> by default.</div><div><br></div><div>For floats w=
here comparison is valid, `map&lt;float, Value&gt;` will always provide con=
sistent results across all of its interfaces. What you want is for `map&lt;=
uuid, Value&gt;` to provide consistent results across it&#39;s query-by-Key=
 interface, but for its container interface, the results can be inconsisten=
t.</div><div><br></div><div>That is not a good thing.<br></div><div><br></d=
iv><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=
><div>The situation is even simpler with uuids as there is no IEEE 754 arit=
hmetic complexity (floats are not totally ordered, and testing equality on =
them is usually buggy).</div><div>So I understand why std::map&lt;float, Va=
lue&gt; is not authorized, but I don&#39;t understand why std::map&lt;std::=
uuid, Value&gt; shouldn&#39;t be authorized.</div><div><br></div><div>To su=
mmarize, I would say we have two types of order: the semantic order, the on=
e accessible with the operators =3D=3D, !=3D, &lt;, &lt;=3D, &gt;, &gt;=3D,=
 and a (hopefully total) arbitrary order that can be used in std::map/std::=
set, testing uniqueness...<br></div></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/450a5c6b-b058-43f5-8970-ba35cde663fe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/450a5c6b-b058-43f5-8970-ba35cde663fe=
%40isocpp.org</a>.<br />

------=_Part_9080_1593269151.1532450116442--

------=_Part_9079_2108961164.1532450116441--

.

--0000000000002558930571c15feb
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 24, 2018 at 11:51 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
> On Tuesday, July 24, 2018 at 11:35:27 AM UTC-4, Tony V E wrote:
>>
>> I really think the answer for all this is a way to have:
>>
>> Criteria:
>> - no < operator (or <=> etc)
>> - (thus) no std::less
>> - map "just works"
>>
>
> I assume you mean "just works without an explicit comparison functor".
>

yep.


> Personally, I *don't* want that. If a type is not comparable, that means
> you *should* have to explicitly provide a comparison functor. This is in
> fact why ordered containers take functors. It seems decidedly incoherent to
> say that `T` is not comparable but `T` has some innate ordering that
> ordered containers will use.
>
> If an ordering is good enough to be used by default for ordered
> containers, then it's good enough to be used by `operator<`. And if it
> isn't good enough for the latter, then it's not good enough for the former.
>
>

The fundamental problem is that std::map is misnamed.  It should have been
called ordered_map.  But most people don't use it for ordering; they just
use it for mapping.  That's why people expect it to "just work".

And the problem seems to not go away (with education, etc), thus I'd like
to fix it.

And people tell me naming isn't that important. :-(


--
Be seeing you,
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbisYjqYW9gnvYPLGwb2A0cQ5-nZRcsQqWbVQAs-m%2BnM4%2Bw%40mail.gmail.com.

--0000000000002558930571c15feb
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 Tue, Jul 24, 2018 at 11:51 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a =
href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><sp=
an class=3D""><br><br>On Tuesday, July 24, 2018 at 11:35:27 AM UTC-4, Tony =
V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I r=
eally think the answer for all this is a way to have:</div><div><br></div><=
div>Criteria:<br></div><div>- no &lt; operator (or &lt;=3D&gt; etc)</div><d=
iv>- (thus) no std::less</div><div>- map &quot;just works&quot;</div></div>=
</blockquote><div><br></div></span><div>I assume you mean &quot;just works =
without an explicit comparison functor&quot;.<br></div></div></blockquote><=
div><br></div><div>yep.</div><div> <br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div></div><div><br></div><div>Personally, I <i>don&#39;t=
</i> want that. If a type is not comparable, that means you <i>should</i> h=
ave to explicitly provide a comparison functor. This is in fact why ordered=
 containers take functors. It seems decidedly incoherent to say that `T` is=
 not comparable but `T` has some innate ordering that ordered containers wi=
ll use.</div><div><br></div><div>If an ordering is good enough to be used b=
y default for ordered containers, then it&#39;s good enough to be used by `=
operator&lt;`. And if it isn&#39;t good enough for the latter, then it&#39;=
s not good enough for the former.</div><br></div></blockquote><div><br></di=
v><div>
<div><br></div><div>The fundamental problem is that std::map is=20
misnamed.=C2=A0 It should have been called ordered_map.=C2=A0 But most peop=
le=20
don&#39;t use it for ordering; they just use it for mapping.=C2=A0 That&#39=
;s why=20
people expect it to &quot;just work&quot;.</div><div><br></div><div>And the=
 problem seems to not go away (with education, etc), thus I&#39;d like to f=
ix it.<br></div><div><br></div><div>And people tell me naming isn&#39;t tha=
t important. :-(<br></div></div></div><br clear=3D"all"><br>-- <br><div cla=
ss=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">=
<div>Be seeing you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbisYjqYW9gnvYPLGwb2A0cQ5-nZRcsQq=
WbVQAs-m%2BnM4%2Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbisYjqYW=
9gnvYPLGwb2A0cQ5-nZRcsQqWbVQAs-m%2BnM4%2Bw%40mail.gmail.com</a>.<br />

--0000000000002558930571c15feb--

.

--00000000000030bc4c0571c16119
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 24, 2018 at 12:11 PM, Andrey Semashev <andrey.semashev@gmail.com
> wrote:

> On 07/24/18 18:35, Tony V E wrote:
>
>> I really think the answer for all this is a way to have:
>>
>> Criteria:
>> - no < operator (or <=> etc)
>> - (thus) no std::less
>> - map "just works"
>>
>> My thoughts so far are either:
>>
>> A. map checks whether std::less "works" for the given type (this requires
>> some convoluted template stuff, but it can hide inside map and std::less),
>> and if std::less doesn't work, something else (ie std::order) is
>> substituted.  std::order would probably default to compiler generated
>> memberwise lexicographical order
>>
>> or
>>
>> B. The type (ie uuid) would define a internal typedef uuid::order than
>> map would look for.  This is more of an "opt-in" hack.  (And thus
>> uuid::order would need a less-likely name, ie uuid::order_for_map).
>> std::map would use K::order by default, or only when std::less doesn't
>> compile. Something like that.
>>
>> or
>>
>> C. something else.
>>
>> But the criteria at the top are, I think, what we want.
>>
>
> Personally, it looks like over-engineering to me. This approach introduces
> a new customization point, which does not seem necessary. Or a bit of magic
> in the interaction between map and uuid, which is worse. IMHO, just
> defining the ordering operator for uuids and reusing the existing
> infrastructure is the right way to go as it provides the most benefit and
> causes the least surprise to users.
>
>

Yes, it looks like over-engineering to me as well - I'd prefer a simpler
solution, or at least a way to "sell" it as appearing simple :-)
But it is also a problem that keeps coming up, and is causing ripple
effects elsewhere.

We are now at the point where many (in the field and on the committee)
think almost all types should have <, even when meaningless.  All because,
essentially, map was misnamed.

Maybe I should just propose a separate type, same as std::map, except it
uses a better default ordering.  Maybe remove iterator stability guarantees
while I'm at it.  (Could I remove enough spec that both map and
unordered_map are valid implementations?)

C. std::just_map?



> However, I always preferred naming my ordering predicates as
> something_order or something like that instead of something_less because
> ordering rarely has anything to do with one element being somehow less or
> greater than the other. So I would be in favor of a general nomenclature
> change from "comparing elements for less/greater" to "imposing an order
> between elements", with comparison being just a default case.
>
>
>


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

--00000000000030bc4c0571c16119
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 Tue, Jul 24, 2018 at 12:11 PM, Andrey Semashev <span dir=3D"ltr">&lt=
;<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.sema=
shev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><spa=
n>On 07/24/18 18:35, Tony V E wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I really think the answer for all this is a way to have:<br>
<br>
Criteria:<br>
- no &lt; operator (or &lt;=3D&gt; etc)<br>
- (thus) no std::less<br>
- map &quot;just works&quot;<br>
<br>
My thoughts so far are either:<br>
<br>
A. map checks whether std::less &quot;works&quot; for the given type (this =
requires some convoluted template stuff, but it can hide inside map and std=
::less),<br>
and if std::less doesn&#39;t work, something else (ie std::order) is substi=
tuted.=C2=A0 std::order would probably default to compiler generated member=
wise lexicographical order<br>
<br>
or<br>
<br>
B. The type (ie uuid) would define a internal typedef uuid::order than map =
would look for.=C2=A0 This is more of an &quot;opt-in&quot; hack.=C2=A0 (An=
d thus uuid::order would need a less-likely name, ie uuid::order_for_map).=
=C2=A0 std::map would use K::order by default, or only when std::less doesn=
&#39;t compile. Something like that.<br>
<br>
or<br>
<br>
C. something else.<br>
<br>
But the criteria at the top are, I think, what we want.<br>
</blockquote>
<br></span>
Personally, it looks like over-engineering to me. This approach introduces =
a new customization point, which does not seem necessary. Or a bit of magic=
 in the interaction between map and uuid, which is worse. IMHO, just defini=
ng the ordering operator for uuids and reusing the existing infrastructure =
is the right way to go as it provides the most benefit and causes the least=
 surprise to users.<br>
<br></blockquote><div><br></div><div><br></div><div>Yes, it looks like over=
-engineering to me as well - I&#39;d prefer a simpler solution, or at least=
 a way to &quot;sell&quot; it as appearing simple :-)</div><div>But it is a=
lso a problem that keeps coming up, and is causing ripple effects elsewhere=
..</div><div><br></div><div>We are now at the point where many (in the field=
 and on the committee) think almost all types should have &lt;, even when m=
eaningless.=C2=A0 All because, essentially, map was misnamed.</div><div><br=
></div><div>Maybe I should just propose a separate type, same as std::map, =
except it uses a better default ordering.=C2=A0 Maybe remove iterator stabi=
lity guarantees while I&#39;m at it.=C2=A0 (Could I remove enough spec that=
 both map and unordered_map are valid implementations?)<br></div><div><br><=
/div>C. std::just_map?<br></div><div class=3D"gmail_quote"><div><br></div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
However, I always preferred naming my ordering predicates as something_orde=
r or something like that instead of something_less because ordering rarely =
has anything to do with one element being somehow less or greater than the =
other. So I would be in favor of a general nomenclature change from &quot;c=
omparing elements for less/greater&quot; to &quot;imposing an order between=
 elements&quot;, with comparison being just a default case.<span><br>
<br>
<br></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=
=3D"m_8205698952232463089gmail_signature" data-smartmail=3D"gmail_signature=
"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiud74d6HvushEE30iS3rEnfMJSGeMwJ=
Vj1qGCfDzvoQ9g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiud74d6Hvus=
hEE30iS3rEnfMJSGeMwJVj1qGCfDzvoQ9g%40mail.gmail.com</a>.<br />

--00000000000030bc4c0571c16119--

.

------=_Part_9047_848133906.1532450367518
Content-Type: multipart/alternative;
 boundary="----=_Part_9048_253889310.1532450367518"

------=_Part_9048_253889310.1532450367518
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tuesday, July 24, 2018 at 12:12:54 PM UTC-4, j c wrote:
>
> On Tue, Jul 24, 2018 at 5:06 PM, <floria...@gmail.com <javascript:>>=20
> wrote:
>
>> Le mardi 24 juillet 2018 17:51:14 UTC+2, Nicol Bolas a =C3=A9crit :
>>>
>>> On Tuesday, July 24, 2018 at 11:35:27 AM UTC-4, Tony V E wrote:
>>>>
>>>> I really think the answer for all this is a way to have:
>>>>
>>>> Criteria:
>>>> - no < operator (or <=3D> etc)
>>>> - (thus) no std::less
>>>> - map "just works"
>>>>
>>>
>>> I assume you mean "just works without an explicit comparison functor".
>>>
>>> Personally, I *don't* want that. If a type is not comparable, that=20
>>> means you *should* have to explicitly provide a comparison functor.=20
>>> This is in fact why ordered containers take functors. It seems decidedl=
y=20
>>> incoherent to say that `T` is not comparable but `T` has some innate=20
>>> ordering that ordered containers will use.
>>>
>>> If an ordering is good enough to be used by default for ordered=20
>>> containers, then it's good enough to be used by `operator<`. And if it=
=20
>>> isn't good enough for the latter, then it's not good enough for the for=
mer.
>>>
>>>
>> I completely disagree with you here. It is really easy to create some=20
>> mathematics objects where you can have trivial total order, but where su=
ch=20
>> an order has no mathematical meaning.
>> I give you a few on them: complex numbers, vectors or matrices.
>>
>> Having an arbitrary order that has no real meaning is interesting becaus=
e=20
>> then, you can use binary search on them.
>> Why couldn't you use binary search on std::complex<float>, while you=20
>> could on std::pair<float, float>?
>>
>> The situation is even simpler with uuids as there is no IEEE 754=20
>> arithmetic complexity (floats are not totally ordered, and testing equal=
ity=20
>> on them is usually buggy).
>> So I understand why std::map<float, Value> is not authorized, but I don'=
t=20
>> understand why std::map<std::uuid, Value> shouldn't be authorized.
>>
>> To summarize, I would say we have two types of order: the semantic order=
,=20
>> the one accessible with the operators =3D=3D, !=3D, <, <=3D, >, >=3D, an=
d a=20
>> (hopefully total) arbitrary order that can be used in std::map/std::set,=
=20
>> testing uniqueness...
>>
>
>
> Totally agree, if Java can find a way to compare UUIDs then C++ *must*=20
> too, otherwise this proposal may as well be rejected.
>
> https://docs.oracle.com/javase/9/docs/api/java/util/UUID.html#compareTo-j=
ava.util.UUID-
>

The question is not one of determining a way to compare UUIDs; there are=20
several alternatives. The problem is that canonizing an alternative as the=
=20
comparison prevents implementation variances.

For example, let's say you store UUIDs in a 64-bit build as a sequence of=
=20
`uint64_t`s. The fastest way to compare them therefore is to compare each=
=20
64-bit word in sequence. However, this will produce a different ordering=20
from a 32-bit build that uses a sequence of `uint32_t`s.

You could enforce a consistent ordering by forcing lexicographic ordering=
=20
(bytewise, in the order defined by UUID from lowest to highest). But that=
=20
ordering will be slower than the unit-wise, arbitrary ordering. So making=
=20
it the default is one of those "paying for a feature you don't use" things=
=20
that C++ is supposed to avoid.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5dc1d8b2-b640-4345-be95-2b7f8a4fd123%40isocpp.or=
g.

------=_Part_9048_253889310.1532450367518
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, July 24, 2018 at 12:12:54 PM UTC-4, j c wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cla=
ss=3D"gmail_quote">On Tue, Jul 24, 2018 at 5:06 PM,  <span dir=3D"ltr">&lt;=
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"p36LWpq9=
DAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">flori=
a...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204=
,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><=
span>Le mardi 24 juillet 2018 17:51:14 UTC+2, Nicol Bolas a =C3=A9crit=C2=
=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;pad=
ding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bord=
er-left-style:solid"><div dir=3D"ltr">On Tuesday, July 24, 2018 at 11:35:27=
 AM UTC-4, Tony V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bord=
er-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>I really t=
hink the answer for all this is a way to have:</div><div><br></div><div>Cri=
teria:<br></div><div>- no &lt; operator (or &lt;=3D&gt; etc)</div><div>- (t=
hus) no std::less</div><div>- map &quot;just works&quot;</div></div></block=
quote><div><br></div><div>I assume you mean &quot;just works without an exp=
licit comparison functor&quot;.<br></div><div><br></div><div>Personally, I =
<i>don&#39;t</i> want that. If a type is not comparable, that means you <i>=
should</i> have to explicitly provide a comparison functor. This is in fact=
 why ordered containers take functors. It seems decidedly incoherent to say=
 that `T` is not comparable but `T` has some innate ordering that ordered c=
ontainers will use.</div><div><br></div><div>If an ordering is good enough =
to be used by default for ordered containers, then it&#39;s good enough to =
be used by `operator&lt;`. And if it isn&#39;t good enough for the latter, =
then it&#39;s not good enough for the former.</div><br></div></blockquote><=
div><br></div></span><div>I completely disagree with you here. It is really=
 easy to create some mathematics objects where you can have trivial total o=
rder, but where such an order has no mathematical meaning.</div><div>I give=
 you a few on them: complex numbers, vectors or matrices.</div><div><br></d=
iv><div>Having an arbitrary order that has no real meaning is interesting b=
ecause then, you can use binary search on them.</div><div>Why couldn&#39;t =
you use binary search on std::complex&lt;float&gt;, while you could on std:=
:pair&lt;float, float&gt;?</div><div><br></div><div>The situation is even s=
impler with uuids as there is no IEEE 754 arithmetic complexity (floats are=
 not totally ordered, and testing equality on them is usually buggy).</div>=
<div>So I understand why std::map&lt;float, Value&gt; is not authorized, bu=
t I don&#39;t understand why std::map&lt;std::uuid, Value&gt; shouldn&#39;t=
 be authorized.</div><div><br></div><div>To summarize, I would say we have =
two types of order: the semantic order, the one accessible with the operato=
rs =3D=3D, !=3D, &lt;, &lt;=3D, &gt;, &gt;=3D, and a (hopefully total) arbi=
trary order that can be used in std::map/std::set, testing uniqueness...<br=
></div></div></blockquote><div><br></div><div><br></div><div>Totally agree,=
 if Java can find a way to compare UUIDs then C++ *must* too, otherwise thi=
s proposal may as well be rejected.<br><a href=3D"https://docs.oracle.com/j=
avase/9/docs/api/java/util/UUID.html#compareTo-java.util.UUID-" target=3D"_=
blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.=
com/url?q\x3dhttps%3A%2F%2Fdocs.oracle.com%2Fjavase%2F9%2Fdocs%2Fapi%2Fjava=
%2Futil%2FUUID.html%23compareTo-java.util.UUID-\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNHXhIvNXAGJoXtlfnqdgWZRKzPAZA&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.oracle.com=
%2Fjavase%2F9%2Fdocs%2Fapi%2Fjava%2Futil%2FUUID.html%23compareTo-java.util.=
UUID-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXhIvNXAGJoXtlfnqdgWZRKzPAZA&=
#39;;return true;">https://docs.oracle.com/<wbr>javase/9/docs/api/java/util=
/<wbr>UUID.html#compareTo-java.util.<wbr>UUID-</a></div></div></div></div><=
/blockquote><div><br></div><div>The question is not one of determining a wa=
y to compare UUIDs; there are several alternatives. The problem is that can=
onizing an alternative as the comparison prevents implementation variances.=
</div><div><br></div><div>For example, let&#39;s say you store UUIDs in a 6=
4-bit build as a sequence of `uint64_t`s. The fastest way to compare them t=
herefore is to compare each 64-bit word in sequence. However, this will pro=
duce a different ordering from a 32-bit build that uses a sequence of `uint=
32_t`s.</div><div><br></div><div>You could enforce a consistent ordering by=
 forcing lexicographic ordering (bytewise, in the order defined by UUID fro=
m lowest to highest). But that ordering will be slower than the unit-wise, =
arbitrary ordering. So making it the default is one of those &quot;paying f=
or a feature you don&#39;t use&quot; things that C++ is supposed to avoid.<=
/div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5dc1d8b2-b640-4345-be95-2b7f8a4fd123%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5dc1d8b2-b640-4345-be95-2b7f8a4fd123=
%40isocpp.org</a>.<br />

------=_Part_9048_253889310.1532450367518--

------=_Part_9047_848133906.1532450367518--

.

On 07/24/18 19:39, Nicol Bolas wrote:
> On Tuesday, July 24, 2018 at 12:12:54 PM UTC-4, j c wrote:
>
>     Totally agree, if Java can find a way to compare UUIDs then C++
>     *must* too, otherwise this proposal may as well be rejected.
>     https://docs.oracle.com/javase/9/docs/api/java/util/UUID.html#compareTo-java.util.UUID-
>     <https://docs.oracle.com/javase/9/docs/api/java/util/UUID.html#compareTo-java.util.UUID->
>
> The question is not one of determining a way to compare UUIDs; there are
> several alternatives. The problem is that canonizing an alternative as
> the comparison prevents implementation variances.
>
> For example, let's say you store UUIDs in a 64-bit build as a sequence
> of `uint64_t`s. The fastest way to compare them therefore is to compare
> each 64-bit word in sequence. However, this will produce a different
> ordering from a 32-bit build that uses a sequence of `uint32_t`s.
>
> You could enforce a consistent ordering by forcing lexicographic
> ordering (bytewise, in the order defined by UUID from lowest to
> highest). But that ordering will be slower than the unit-wise, arbitrary
> ordering. So making it the default is one of those "paying for a feature
> you don't use" things that C++ is supposed to avoid.

IMHO, even if we have to canonize the ordering, it would be better than
having to implement or specify one in the user's code. Uuids are ids,
comparison and participating in lookup operations are their key
functions which should be made as efficient and easy to use as possible.

If we don't mandate internal representation of std::uuid, a reasonable
canonized ordering can be implemented efficiently on different
architectures. For instance, lexicographic ordering can be made
efficient regardless of the target machine endianness or word size if
you arrange the underlying bytes the most convenient way. This was the
reason I was insisting on making std::uuid representation as opaque as
possible.

However, I reiterate, I don't see much use in mandating any *particular*
ordering because most of the time we don't care about the order. One
exception I can think of is ensuring portable serialization of an
ordered sequence of uuids, but it is special enough to explicitly
specify the ordering predicate.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c864c3ce-253b-7bdb-0e21-f4e3ded4be12%40gmail.com.

.

------=_Part_9165_1727886786.1532451810254
Content-Type: multipart/alternative;
 boundary="----=_Part_9166_244970319.1532451810255"

------=_Part_9166_244970319.1532451810255
Content-Type: text/plain; charset="UTF-8"



On Tuesday, July 24, 2018 at 12:37:38 PM UTC-4, Tony V E wrote:
>
>
>
> On Tue, Jul 24, 2018 at 12:11 PM, Andrey Semashev <andrey....@gmail.com
> <javascript:>> wrote:
>
>> On 07/24/18 18:35, Tony V E wrote:
>>
>>> I really think the answer for all this is a way to have:
>>>
>>> Criteria:
>>> - no < operator (or <=> etc)
>>> - (thus) no std::less
>>> - map "just works"
>>>
>>> My thoughts so far are either:
>>>
>>> A. map checks whether std::less "works" for the given type (this
>>> requires some convoluted template stuff, but it can hide inside map and
>>> std::less),
>>> and if std::less doesn't work, something else (ie std::order) is
>>> substituted.  std::order would probably default to compiler generated
>>> memberwise lexicographical order
>>>
>>> or
>>>
>>> B. The type (ie uuid) would define a internal typedef uuid::order than
>>> map would look for.  This is more of an "opt-in" hack.  (And thus
>>> uuid::order would need a less-likely name, ie uuid::order_for_map).
>>> std::map would use K::order by default, or only when std::less doesn't
>>> compile. Something like that.
>>>
>>> or
>>>
>>> C. something else.
>>>
>>> But the criteria at the top are, I think, what we want.
>>>
>>
>> Personally, it looks like over-engineering to me. This approach
>> introduces a new customization point, which does not seem necessary. Or a
>> bit of magic in the interaction between map and uuid, which is worse. IMHO,
>> just defining the ordering operator for uuids and reusing the existing
>> infrastructure is the right way to go as it provides the most benefit and
>> causes the least surprise to users.
>>
>>
>
> Yes, it looks like over-engineering to me as well - I'd prefer a simpler
> solution, or at least a way to "sell" it as appearing simple :-)
> But it is also a problem that keeps coming up, and is causing ripple
> effects elsewhere.
>
> We are now at the point where many (in the field and on the committee)
> think almost all types should have <, even when meaningless.  All because,
> essentially, map was misnamed.
>

Are people really so averse to adding that third template parameter?


> Maybe I should just propose a separate type, same as std::map, except it
> uses a better default ordering.  Maybe remove iterator stability guarantees
> while I'm at it.  (Could I remove enough spec that both map and
> unordered_map are valid implementations?)
>

Don't forget `flat_map`.

In any case, such a type is a pure dictionary, a way to insert, find, and
remove values by keys. If there needs to be an iteration mechanism, then it
needs to be through a "get a range" function, rather than the dictionary
itself *being* a range. Indeed, I would say that you should have distinct
functions for getting the range of values and the range of keys. (how many
times have you iterated through a `map` without caring about the key?) And
any insertions or removals will invalidate such ranges entirely (iterators,
pointers and references), thus allowing `flat_map` to work.

The ordering for such a dictionary is the means by which to build the
searching functionality. As such, I would say that this dictionary type
should not even expose the order as a functor parameter; there would be
some default ordering for a type that could be specified, and that's the
ordering that it always uses.

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

------=_Part_9166_244970319.1532451810255
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, July 24, 2018 at 12:37:38 PM UTC-4, To=
ny V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<br><div><br><div class=3D"gmail_quote">On Tue, Jul 24, 2018 at 12:11 PM, A=
ndrey Semashev <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"Frta7_O-DAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">andrey....@gmail.com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><span>On 07/24/18 18:35, Tony V E wrote:<=
br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I really think the answer for all this is a way to have:<br>
<br>
Criteria:<br>
- no &lt; operator (or &lt;=3D&gt; etc)<br>
- (thus) no std::less<br>
- map &quot;just works&quot;<br>
<br>
My thoughts so far are either:<br>
<br>
A. map checks whether std::less &quot;works&quot; for the given type (this =
requires some convoluted template stuff, but it can hide inside map and std=
::less),<br>
and if std::less doesn&#39;t work, something else (ie std::order) is substi=
tuted.=C2=A0 std::order would probably default to compiler generated member=
wise lexicographical order<br>
<br>
or<br>
<br>
B. The type (ie uuid) would define a internal typedef uuid::order than map =
would look for.=C2=A0 This is more of an &quot;opt-in&quot; hack.=C2=A0 (An=
d thus uuid::order would need a less-likely name, ie uuid::order_for_map).=
=C2=A0 std::map would use K::order by default, or only when std::less doesn=
&#39;t compile. Something like that.<br>
<br>
or<br>
<br>
C. something else.<br>
<br>
But the criteria at the top are, I think, what we want.<br>
</blockquote>
<br></span>
Personally, it looks like over-engineering to me. This approach introduces =
a new customization point, which does not seem necessary. Or a bit of magic=
 in the interaction between map and uuid, which is worse. IMHO, just defini=
ng the ordering operator for uuids and reusing the existing infrastructure =
is the right way to go as it provides the most benefit and causes the least=
 surprise to users.<br>
<br></blockquote><div><br></div><div><br></div><div>Yes, it looks like over=
-engineering to me as well - I&#39;d prefer a simpler solution, or at least=
 a way to &quot;sell&quot; it as appearing simple :-)</div><div>But it is a=
lso a problem that keeps coming up, and is causing ripple effects elsewhere=
..</div><div><br></div><div>We are now at the point where many (in the field=
 and on the committee) think almost all types should have &lt;, even when m=
eaningless.=C2=A0 All because, essentially, map was misnamed.</div></div></=
div></div></blockquote><div><br></div><div>Are people really so averse to a=
dding that third template parameter?<br></div><div>=C2=A0</div><blockquote =
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_=
quote"><div>Maybe I should just propose a separate type, same as std::map, =
except it uses a better default ordering.=C2=A0 Maybe remove iterator stabi=
lity guarantees while I&#39;m at it.=C2=A0 (Could I remove enough spec that=
 both map and unordered_map are valid implementations?)<br></div></div></di=
v></div></blockquote><div><br></div><div>Don&#39;t forget `flat_map`.</div>=
<div><br></div><div>In any case, such a type is a pure dictionary, a way to=
 insert, find, and remove values by keys. If there needs to be an iteration=
 mechanism, then it needs to be through a &quot;get a range&quot; function,=
 rather than the dictionary itself <i>being</i> a range. Indeed, I would sa=
y that you should have distinct functions for getting the range of values a=
nd the range of keys. (how many times have you iterated through a `map` wit=
hout caring about the key?) And any insertions or removals will invalidate =
such ranges entirely (iterators, pointers and references), thus allowing `f=
lat_map` to work.</div><div><br></div><div>The ordering for such a dictiona=
ry is the means by which to build the searching functionality. As such, I w=
ould say that this dictionary type should not even expose the order as a fu=
nctor parameter; there would be some default ordering for a type that could=
 be specified, and that&#39;s the ordering that it always uses.<br></div></=
div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4bca27fa-bd8b-4066-81cf-a9cdeb92ea6c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4bca27fa-bd8b-4066-81cf-a9cdeb92ea6c=
%40isocpp.org</a>.<br />

------=_Part_9166_244970319.1532451810255--

------=_Part_9165_1727886786.1532451810254--

.

------=_Part_1176_1387297564.1532452348487
Content-Type: multipart/alternative;
 boundary="----=_Part_1177_1416010947.1532452348488"

------=_Part_1177_1416010947.1532452348488
Content-Type: text/plain; charset="UTF-8"

On Tuesday, July 24, 2018 at 1:03:15 PM UTC-4, Andrey Semashev wrote:
>
> On 07/24/18 19:39, Nicol Bolas wrote:
> > On Tuesday, July 24, 2018 at 12:12:54 PM UTC-4, j c wrote:
> >
> >     Totally agree, if Java can find a way to compare UUIDs then C++
> >     *must* too, otherwise this proposal may as well be rejected.
> >
> https://docs.oracle.com/javase/9/docs/api/java/util/UUID.html#compareTo-java.util.UUID-
> >     <
> https://docs.oracle.com/javase/9/docs/api/java/util/UUID.html#compareTo-java.util.UUID->
>
> >
> > The question is not one of determining a way to compare UUIDs; there are
> > several alternatives. The problem is that canonizing an alternative as
> > the comparison prevents implementation variances.
> >
> > For example, let's say you store UUIDs in a 64-bit build as a sequence
> > of `uint64_t`s. The fastest way to compare them therefore is to compare
> > each 64-bit word in sequence. However, this will produce a different
> > ordering from a 32-bit build that uses a sequence of `uint32_t`s.
> >
> > You could enforce a consistent ordering by forcing lexicographic
> > ordering (bytewise, in the order defined by UUID from lowest to
> > highest). But that ordering will be slower than the unit-wise, arbitrary
> > ordering. So making it the default is one of those "paying for a feature
> > you don't use" things that C++ is supposed to avoid.
>
> IMHO, even if we have to canonize the ordering, it would be better than
> having to implement or specify one in the user's code. Uuids are ids,
> comparison and participating in lookup operations are their key
> functions which should be made as efficient and easy to use as possible.
>
> If we don't mandate internal representation of std::uuid, a reasonable
> canonized ordering can be implemented efficiently on different
> architectures. For instance, lexicographic ordering can be made
> efficient regardless of the target machine endianness or word size if
> you arrange the underlying bytes the most convenient way. This was the
> reason I was insisting on making std::uuid representation as opaque as
> possible.
>
> However, I reiterate, I don't see much use in mandating any *particular*
> ordering because most of the time we don't care about the order. One
> exception I can think of is ensuring portable serialization of an
> ordered sequence of uuids, but it is special enough to explicitly
> specify the ordering predicate.
>

So long as you cannot *prevent* people from relying on an unspecified
order, mandating an unspecified order opens up too many avenues for failure.

But you're right; if you are clever about storing UUIDs, then you can
retain the effects of a lexicographical ordering without having to do
bytewise comparisons. And since we can detect the endian-ness of a platform
now, we can actually do that without resorting to non-standard features (on
platforms with endians, at any rate).

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

------=_Part_1177_1416010947.1532452348488
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, July 24, 2018 at 1:03:15 PM UTC-4, Andrey Sema=
shev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 07/24/18 19:39, =
Nicol Bolas wrote:
<br>&gt; On Tuesday, July 24, 2018 at 12:12:54 PM UTC-4, j c wrote:
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 Totally agree, if Java can find a way to compare UUI=
Ds then C++
<br>&gt; =C2=A0 =C2=A0 *must* too, otherwise this proposal may as well be r=
ejected.
<br>&gt; =C2=A0 =C2=A0 <a href=3D"https://docs.oracle.com/javase/9/docs/api=
/java/util/UUID.html#compareTo-java.util.UUID-" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhtt=
ps%3A%2F%2Fdocs.oracle.com%2Fjavase%2F9%2Fdocs%2Fapi%2Fjava%2Futil%2FUUID.h=
tml%23compareTo-java.util.UUID-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXh=
IvNXAGJoXtlfnqdgWZRKzPAZA&#39;;return true;" onclick=3D"this.href=3D&#39;ht=
tps://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.oracle.com%2Fjavase%2F9%2F=
docs%2Fapi%2Fjava%2Futil%2FUUID.html%23compareTo-java.util.UUID-\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNHXhIvNXAGJoXtlfnqdgWZRKzPAZA&#39;;return true=
;">https://docs.oracle.com/<wbr>javase/9/docs/api/java/util/<wbr>UUID.html#=
compareTo-java.util.<wbr>UUID-</a>
<br>&gt; =C2=A0 =C2=A0 &lt;<a href=3D"https://docs.oracle.com/javase/9/docs=
/api/java/util/UUID.html#compareTo-java.util.UUID-" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\=
x3dhttps%3A%2F%2Fdocs.oracle.com%2Fjavase%2F9%2Fdocs%2Fapi%2Fjava%2Futil%2F=
UUID.html%23compareTo-java.util.UUID-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQ=
jCNHXhIvNXAGJoXtlfnqdgWZRKzPAZA&#39;;return true;" onclick=3D"this.href=3D&=
#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.oracle.com%2Fjavase%=
2F9%2Fdocs%2Fapi%2Fjava%2Futil%2FUUID.html%23compareTo-java.util.UUID-\x26s=
a\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXhIvNXAGJoXtlfnqdgWZRKzPAZA&#39;;retur=
n true;">https://docs.oracle.com/<wbr>javase/9/docs/api/java/util/<wbr>UUID=
..html#compareTo-java.util.<wbr>UUID-</a>&gt;
<br>&gt;=20
<br>&gt; The question is not one of determining a way to compare UUIDs; the=
re are=20
<br>&gt; several alternatives. The problem is that canonizing an alternativ=
e as=20
<br>&gt; the comparison prevents implementation variances.
<br>&gt;=20
<br>&gt; For example, let&#39;s say you store UUIDs in a 64-bit build as a =
sequence=20
<br>&gt; of `uint64_t`s. The fastest way to compare them therefore is to co=
mpare=20
<br>&gt; each 64-bit word in sequence. However, this will produce a differe=
nt=20
<br>&gt; ordering from a 32-bit build that uses a sequence of `uint32_t`s.
<br>&gt;=20
<br>&gt; You could enforce a consistent ordering by forcing lexicographic=
=20
<br>&gt; ordering (bytewise, in the order defined by UUID from lowest to=20
<br>&gt; highest). But that ordering will be slower than the unit-wise, arb=
itrary=20
<br>&gt; ordering. So making it the default is one of those &quot;paying fo=
r a feature=20
<br>&gt; you don&#39;t use&quot; things that C++ is supposed to avoid.
<br>
<br>IMHO, even if we have to canonize the ordering, it would be better than=
=20
<br>having to implement or specify one in the user&#39;s code. Uuids are id=
s,=20
<br>comparison and participating in lookup operations are their key=20
<br>functions which should be made as efficient and easy to use as possible=
..
<br>
<br>If we don&#39;t mandate internal representation of std::uuid, a reasona=
ble=20
<br>canonized ordering can be implemented efficiently on different=20
<br>architectures. For instance, lexicographic ordering can be made=20
<br>efficient regardless of the target machine endianness or word size if=
=20
<br>you arrange the underlying bytes the most convenient way. This was the=
=20
<br>reason I was insisting on making std::uuid representation as opaque as=
=20
<br>possible.
<br>
<br>However, I reiterate, I don&#39;t see much use in mandating any *partic=
ular*=20
<br>ordering because most of the time we don&#39;t care about the order. On=
e=20
<br>exception I can think of is ensuring portable serialization of an=20
<br>ordered sequence of uuids, but it is special enough to explicitly=20
<br>specify the ordering predicate.
<br></blockquote><div><br></div><div>So long as you cannot <i>prevent</i> p=
eople from relying on an unspecified order, mandating an unspecified order =
opens up too many avenues for failure.</div><div><br></div><div>But you&#39=
;re right; if you are clever about storing UUIDs, then you can retain the e=
ffects of a lexicographical ordering without having to do bytewise comparis=
ons. And since we can detect the endian-ness of a platform now, we can actu=
ally do that without resorting to non-standard features (on platforms with =
endians, at any rate).<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/28f5beda-4351-40fd-8084-3bfeae2be787%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/28f5beda-4351-40fd-8084-3bfeae2be787=
%40isocpp.org</a>.<br />

------=_Part_1177_1416010947.1532452348488--

------=_Part_1176_1387297564.1532452348487--

.

------=_Part_9321_1949238556.1532452429552
Content-Type: multipart/alternative;
 boundary="----=_Part_9322_766600086.1532452429552"

------=_Part_9322_766600086.1532452429552
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Le mardi 24 juillet 2018 19:03:30 UTC+2, Nicol Bolas a =C3=A9crit :
>
>
>
> On Tuesday, July 24, 2018 at 12:37:38 PM UTC-4, Tony V E wrote:
>>
>>
>>
>> On Tue, Jul 24, 2018 at 12:11 PM, Andrey Semashev <andrey....@gmail.com>=
=20
>> wrote:
>>
>>> On 07/24/18 18:35, Tony V E wrote:
>>>
>>>> I really think the answer for all this is a way to have:
>>>>
>>>> Criteria:
>>>> - no < operator (or <=3D> etc)
>>>> - (thus) no std::less
>>>> - map "just works"
>>>>
>>>> My thoughts so far are either:
>>>>
>>>> A. map checks whether std::less "works" for the given type (this=20
>>>> requires some convoluted template stuff, but it can hide inside map an=
d=20
>>>> std::less),
>>>> and if std::less doesn't work, something else (ie std::order) is=20
>>>> substituted.  std::order would probably default to compiler generated=
=20
>>>> memberwise lexicographical order
>>>>
>>>> or
>>>>
>>>> B. The type (ie uuid) would define a internal typedef uuid::order than=
=20
>>>> map would look for.  This is more of an "opt-in" hack.  (And thus=20
>>>> uuid::order would need a less-likely name, ie uuid::order_for_map). =
=20
>>>> std::map would use K::order by default, or only when std::less doesn't=
=20
>>>> compile. Something like that.
>>>>
>>>> or
>>>>
>>>> C. something else.
>>>>
>>>> But the criteria at the top are, I think, what we want.
>>>>
>>>
>>> Personally, it looks like over-engineering to me. This approach=20
>>> introduces a new customization point, which does not seem necessary. Or=
 a=20
>>> bit of magic in the interaction between map and uuid, which is worse. I=
MHO,=20
>>> just defining the ordering operator for uuids and reusing the existing=
=20
>>> infrastructure is the right way to go as it provides the most benefit a=
nd=20
>>> causes the least surprise to users.
>>>
>>>
>>
>> Yes, it looks like over-engineering to me as well - I'd prefer a simpler=
=20
>> solution, or at least a way to "sell" it as appearing simple :-)
>> But it is also a problem that keeps coming up, and is causing ripple=20
>> effects elsewhere.
>>
>> We are now at the point where many (in the field and on the committee)=
=20
>> think almost all types should have <, even when meaningless.  All becaus=
e,=20
>> essentially, map was misnamed.
>>
>
> Are people really so averse to adding that third template parameter?
>

Because the default should just work out of the box. period.
=20

> =20
>
>> Maybe I should just propose a separate type, same as std::map, except it=
=20
>> uses a better default ordering.  Maybe remove iterator stability guarant=
ees=20
>> while I'm at it.  (Could I remove enough spec that both map and=20
>> unordered_map are valid implementations?)
>>
>
> Don't forget `flat_map`.
>
> In any case, such a type is a pure dictionary, a way to insert, find, and=
=20
> remove values by keys. If there needs to be an iteration mechanism, then =
it=20
> needs to be through a "get a range" function, rather than the dictionary=
=20
> itself *being* a range. Indeed, I would say that you should have distinct=
=20
> functions for getting the range of values and the range of keys. (how man=
y=20
> times have you iterated through a `map` without caring about the key?) An=
d=20
> any insertions or removals will invalidate such ranges entirely (iterator=
s,=20
> pointers and references), thus allowing `flat_map` to work.
>
> The ordering for such a dictionary is the means by which to build the=20
> searching functionality. As such, I would say that this dictionary type=
=20
> should not even expose the order as a functor parameter; there would be=
=20
> some default ordering for a type that could be specified, and that's the=
=20
> ordering that it always uses.
>

There are many questions on the fly:
- Should we be able to have std:map<std::uuid, Value>? Definitely
- Should we be able to compare uuids with the natural operators? I'm not=20
sure, maybe
- Should the "default" order of uuids be fully specified? I would say yes,=
=20
but I would also be fine with no

Also, I would want to say that the only benefit to let uuid unspecified is=
=20
to optimize the ordering across architectures.
But here, we could say that the missed optimizations on some architectures=
=20
might not be a big problem because it will still be really fast (comparing=
=20
at most 2x16 bytes).
So fully specifying the order might be good enough.
And the natural order would be bytewise. On x86, this could be implemented=
=20
efficiently with SSE4.
And if the memory layout is not specified, then it is even simpler.

However, a unspecified order would also be viable.
There is already a standard type that have a not fully specified order:=20
char. Because the signed of char is not specfied, so is its order.
How many times did you find this problematic? I believe not so many.
And how many people will need cross-platform order, while also not knowing=
=20
the language differences on these platforms?

The unspecified order is not really problematic in practice.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/8deb17dc-1a74-4097-99c9-8b5285ecdaae%40isocpp.or=
g.

------=_Part_9322_766600086.1532452429552
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Le mardi 24 juillet 2018 19:03:30 UTC+2, Nicol Bol=
as a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><br>On Tuesday, July 24, 2018 at 12:37:38 PM UTC-4, Tony V E w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><br>=
<div class=3D"gmail_quote">On Tue, Jul 24, 2018 at 12:11 PM, Andrey Semashe=
v <span dir=3D"ltr">&lt;<a rel=3D"nofollow">andrey....@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><span>On 07/24/18 18:35, Tony=
 V E wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I really think the answer for all this is a way to have:<br>
<br>
Criteria:<br>
- no &lt; operator (or &lt;=3D&gt; etc)<br>
- (thus) no std::less<br>
- map &quot;just works&quot;<br>
<br>
My thoughts so far are either:<br>
<br>
A. map checks whether std::less &quot;works&quot; for the given type (this =
requires some convoluted template stuff, but it can hide inside map and std=
::less),<br>
and if std::less doesn&#39;t work, something else (ie std::order) is substi=
tuted.=C2=A0 std::order would probably default to compiler generated member=
wise lexicographical order<br>
<br>
or<br>
<br>
B. The type (ie uuid) would define a internal typedef uuid::order than map =
would look for.=C2=A0 This is more of an &quot;opt-in&quot; hack.=C2=A0 (An=
d thus uuid::order would need a less-likely name, ie uuid::order_for_map).=
=C2=A0 std::map would use K::order by default, or only when std::less doesn=
&#39;t compile. Something like that.<br>
<br>
or<br>
<br>
C. something else.<br>
<br>
But the criteria at the top are, I think, what we want.<br>
</blockquote>
<br></span>
Personally, it looks like over-engineering to me. This approach introduces =
a new customization point, which does not seem necessary. Or a bit of magic=
 in the interaction between map and uuid, which is worse. IMHO, just defini=
ng the ordering operator for uuids and reusing the existing infrastructure =
is the right way to go as it provides the most benefit and causes the least=
 surprise to users.<br>
<br></blockquote><div><br></div><div><br></div><div>Yes, it looks like over=
-engineering to me as well - I&#39;d prefer a simpler solution, or at least=
 a way to &quot;sell&quot; it as appearing simple :-)</div><div>But it is a=
lso a problem that keeps coming up, and is causing ripple effects elsewhere=
..</div><div><br></div><div>We are now at the point where many (in the field=
 and on the committee) think almost all types should have &lt;, even when m=
eaningless.=C2=A0 All because, essentially, map was misnamed.</div></div></=
div></div></blockquote><div><br></div><div>Are people really so averse to a=
dding that third template parameter?<br></div></div></blockquote><div><br><=
/div><div>Because the default should just work out of the box. period.<br><=
/div><div>=C2=A0</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><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=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>Maybe I should just=
 propose a separate type, same as std::map, except it uses a better default=
 ordering.=C2=A0 Maybe remove iterator stability guarantees while I&#39;m a=
t it.=C2=A0 (Could I remove enough spec that both map and unordered_map are=
 valid implementations?)<br></div></div></div></div></blockquote><div><br><=
/div><div>Don&#39;t forget `flat_map`.</div><div><br></div><div>In any case=
, such a type is a pure dictionary, a way to insert, find, and remove value=
s by keys. If there needs to be an iteration mechanism, then it needs to be=
 through a &quot;get a range&quot; function, rather than the dictionary its=
elf <i>being</i> a range. Indeed, I would say that you should have distinct=
 functions for getting the range of values and the range of keys. (how many=
 times have you iterated through a `map` without caring about the key?) And=
 any insertions or removals will invalidate such ranges entirely (iterators=
, pointers and references), thus allowing `flat_map` to work.</div><div><br=
></div><div>The ordering for such a dictionary is the means by which to bui=
ld the searching functionality. As such, I would say that this dictionary t=
ype should not even expose the order as a functor parameter; there would be=
 some default ordering for a type that could be specified, and that&#39;s t=
he ordering that it always uses.<br></div></div></blockquote><div><br></div=
><div><div>There are many questions on the fly:</div><div>- Should we be ab=
le to have std:map&lt;std::uuid, Value&gt;? Definitely</div><div>- Should w=
e be able to compare uuids with the natural operators? I&#39;m not sure, ma=
ybe</div><div>- Should the &quot;default&quot; order of uuids be fully spec=
ified? I would say yes, but I would also be fine with no<br></div><div><br>=
</div>Also, I would want to say that the only benefit to let uuid unspecifi=
ed is to optimize the ordering across architectures.<br>But
 here, we could say that the missed optimizations on some architectures=20
might not be a big problem because it will still be really fast=20
(comparing at most 2x16 bytes).<br>So fully specifying the order might be g=
ood enough.<br>And the natural order would be bytewise. On x86, this could =
be implemented efficiently with SSE4.</div><div>And if the memory layout is=
 not specified, then it is even simpler.<br></div><div><br>However, a unspe=
cified order would also be viable.<br>There
 is already a standard type that have a not fully specified order: char.
 Because the signed of char is not specfied, so is its order.<br>How many t=
imes did you find this problematic? I believe not so many.<br>And how many =
people will need cross-platform order, while also not knowing the language =
differences on these platforms?<br><br>The unspecified order is not really =
problematic in practice.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8deb17dc-1a74-4097-99c9-8b5285ecdaae%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8deb17dc-1a74-4097-99c9-8b5285ecdaae=
%40isocpp.org</a>.<br />

------=_Part_9322_766600086.1532452429552--

------=_Part_9321_1949238556.1532452429552--

.

--0000000000004366a40571c1f1d1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 24 Jul 2018 at 18:13, <florian.csdt@gmail.com> wrote:

>
>
> Le mardi 24 juillet 2018 19:03:30 UTC+2, Nicol Bolas a =C3=A9crit :
>>
>>
>>
>> On Tuesday, July 24, 2018 at 12:37:38 PM UTC-4, Tony V E wrote:
>>>
>>>
>>>
>>> On Tue, Jul 24, 2018 at 12:11 PM, Andrey Semashev <andrey....@gmail.com=
>
>>> wrote:
>>>
>>>> On 07/24/18 18:35, Tony V E wrote:
>>>>
>>>>> I really think the answer for all this is a way to have:
>>>>>
>>>>> Criteria:
>>>>> - no < operator (or <=3D> etc)
>>>>> - (thus) no std::less
>>>>> - map "just works"
>>>>>
>>>>> My thoughts so far are either:
>>>>>
>>>>> A. map checks whether std::less "works" for the given type (this
>>>>> requires some convoluted template stuff, but it can hide inside map a=
nd
>>>>> std::less),
>>>>> and if std::less doesn't work, something else (ie std::order) is
>>>>> substituted.  std::order would probably default to compiler generated
>>>>> memberwise lexicographical order
>>>>>
>>>>> or
>>>>>
>>>>> B. The type (ie uuid) would define a internal typedef uuid::order tha=
n
>>>>> map would look for.  This is more of an "opt-in" hack.  (And thus
>>>>> uuid::order would need a less-likely name, ie uuid::order_for_map).
>>>>> std::map would use K::order by default, or only when std::less doesn'=
t
>>>>> compile. Something like that.
>>>>>
>>>>> or
>>>>>
>>>>> C. something else.
>>>>>
>>>>> But the criteria at the top are, I think, what we want.
>>>>>
>>>>
>>>> Personally, it looks like over-engineering to me. This approach
>>>> introduces a new customization point, which does not seem necessary. O=
r a
>>>> bit of magic in the interaction between map and uuid, which is worse. =
IMHO,
>>>> just defining the ordering operator for uuids and reusing the existing
>>>> infrastructure is the right way to go as it provides the most benefit =
and
>>>> causes the least surprise to users.
>>>>
>>>>
>>>
>>> Yes, it looks like over-engineering to me as well - I'd prefer a simple=
r
>>> solution, or at least a way to "sell" it as appearing simple :-)
>>> But it is also a problem that keeps coming up, and is causing ripple
>>> effects elsewhere.
>>>
>>> We are now at the point where many (in the field and on the committee)
>>> think almost all types should have <, even when meaningless.  All becau=
se,
>>> essentially, map was misnamed.
>>>
>>
>> Are people really so averse to adding that third template parameter?
>>
>
> Because the default should just work out of the box. period.
>

Not when it's illogical. People should be prevented from doing illogical
things at compile time. The correct container where the key is a uuid is an
unordered_map.

A std::map<uuid, T> should statically assert and refuse to compile, with an
error message that refers the author to the UUID spec.



>
>
>>
>>
>>> Maybe I should just propose a separate type, same as std::map, except i=
t
>>> uses a better default ordering.  Maybe remove iterator stability guaran=
tees
>>> while I'm at it.  (Could I remove enough spec that both map and
>>> unordered_map are valid implementations?)
>>>
>>
>> Don't forget `flat_map`.
>>
>> In any case, such a type is a pure dictionary, a way to insert, find, an=
d
>> remove values by keys. If there needs to be an iteration mechanism, then=
 it
>> needs to be through a "get a range" function, rather than the dictionary
>> itself *being* a range. Indeed, I would say that you should have
>> distinct functions for getting the range of values and the range of keys=
..
>> (how many times have you iterated through a `map` without caring about t=
he
>> key?) And any insertions or removals will invalidate such ranges entirel=
y
>> (iterators, pointers and references), thus allowing `flat_map` to work.
>>
>> The ordering for such a dictionary is the means by which to build the
>> searching functionality. As such, I would say that this dictionary type
>> should not even expose the order as a functor parameter; there would be
>> some default ordering for a type that could be specified, and that's the
>> ordering that it always uses.
>>
>
> There are many questions on the fly:
> - Should we be able to have std:map<std::uuid, Value>? Definitely
> - Should we be able to compare uuids with the natural operators? I'm not
> sure, maybe
> - Should the "default" order of uuids be fully specified? I would say yes=
,
> but I would also be fine with no
>
> Also, I would want to say that the only benefit to let uuid unspecified i=
s
> to optimize the ordering across architectures.
> But here, we could say that the missed optimizations on some architecture=
s
> might not be a big problem because it will still be really fast (comparin=
g
> at most 2x16 bytes).
> So fully specifying the order might be good enough.
> And the natural order would be bytewise. On x86, this could be implemente=
d
> efficiently with SSE4.
> And if the memory layout is not specified, then it is even simpler.
>
> However, a unspecified order would also be viable.
> There is already a standard type that have a not fully specified order:
> char. Because the signed of char is not specfied, so is its order.
> How many times did you find this problematic? I believe not so many.
> And how many people will need cross-platform order, while also not knowin=
g
> the language differences on these platforms?
>
> The unspecified order is not really problematic in practice.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8deb17dc-1a7=
4-4097-99c9-8b5285ecdaae%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8deb17dc-1a=
74-4097-99c9-8b5285ecdaae%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CALvx3haiA6oRyeLWfv9_0JTC6h740AdXUUb3uWwz%3D3hoE=
QOsVg%40mail.gmail.com.

--0000000000004366a40571c1f1d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, 24 Jul 2018 at 18:13, &lt;<a href=3D"mailto:florian.csdt@gmail.com">flori=
an.csdt@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><br><br>Le mardi 24 juillet 2018 19:03:30 UTC+2, Nicol Bolas=
 a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><br><br>On Tuesday, July 24, 2018 at 12:37:38 PM UTC-4, Tony V E wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><br><div cl=
ass=3D"gmail_quote">On Tue, Jul 24, 2018 at 12:11 PM, Andrey Semashev <span=
 dir=3D"ltr">&lt;<a rel=3D"nofollow">andrey....@gmail.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><span>On 07/24/18 18:35, Tony V E wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I really think the answer for all this is a way to have:<br>
<br>
Criteria:<br>
- no &lt; operator (or &lt;=3D&gt; etc)<br>
- (thus) no std::less<br>
- map &quot;just works&quot;<br>
<br>
My thoughts so far are either:<br>
<br>
A. map checks whether std::less &quot;works&quot; for the given type (this =
requires some convoluted template stuff, but it can hide inside map and std=
::less),<br>
and if std::less doesn&#39;t work, something else (ie std::order) is substi=
tuted.=C2=A0 std::order would probably default to compiler generated member=
wise lexicographical order<br>
<br>
or<br>
<br>
B. The type (ie uuid) would define a internal typedef uuid::order than map =
would look for.=C2=A0 This is more of an &quot;opt-in&quot; hack.=C2=A0 (An=
d thus uuid::order would need a less-likely name, ie uuid::order_for_map).=
=C2=A0 std::map would use K::order by default, or only when std::less doesn=
&#39;t compile. Something like that.<br>
<br>
or<br>
<br>
C. something else.<br>
<br>
But the criteria at the top are, I think, what we want.<br>
</blockquote>
<br></span>
Personally, it looks like over-engineering to me. This approach introduces =
a new customization point, which does not seem necessary. Or a bit of magic=
 in the interaction between map and uuid, which is worse. IMHO, just defini=
ng the ordering operator for uuids and reusing the existing infrastructure =
is the right way to go as it provides the most benefit and causes the least=
 surprise to users.<br>
<br></blockquote><div><br></div><div><br></div><div>Yes, it looks like over=
-engineering to me as well - I&#39;d prefer a simpler solution, or at least=
 a way to &quot;sell&quot; it as appearing simple :-)</div><div>But it is a=
lso a problem that keeps coming up, and is causing ripple effects elsewhere=
..</div><div><br></div><div>We are now at the point where many (in the field=
 and on the committee) think almost all types should have &lt;, even when m=
eaningless.=C2=A0 All because, essentially, map was misnamed.</div></div></=
div></div></blockquote><div><br></div><div>Are people really so averse to a=
dding that third template parameter?<br></div></div></blockquote><div><br><=
/div><div>Because the default should just work out of the box. period.<br><=
/div></div></blockquote><div><br></div><div>Not when it&#39;s illogical. Pe=
ople should be prevented from doing illogical things at compile time. The c=
orrect container where the key is a uuid is an unordered_map.=C2=A0</div><d=
iv><br></div><div>A std::map&lt;uuid, T&gt; should statically assert and re=
fuse to compile, with an error message that refers the author to the UUID s=
pec.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div></div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>May=
be I should just propose a separate type, same as std::map, except it uses =
a better default ordering.=C2=A0 Maybe remove iterator stability guarantees=
 while I&#39;m at it.=C2=A0 (Could I remove enough spec that both map and u=
nordered_map are valid implementations?)<br></div></div></div></div></block=
quote><div><br></div><div>Don&#39;t forget `flat_map`.</div><div><br></div>=
<div>In any case, such a type is a pure dictionary, a way to insert, find, =
and remove values by keys. If there needs to be an iteration mechanism, the=
n it needs to be through a &quot;get a range&quot; function, rather than th=
e dictionary itself <i>being</i> a range. Indeed, I would say that you shou=
ld have distinct functions for getting the range of values and the range of=
 keys. (how many times have you iterated through a `map` without caring abo=
ut the key?) And any insertions or removals will invalidate such ranges ent=
irely (iterators, pointers and references), thus allowing `flat_map` to wor=
k.</div><div><br></div><div>The ordering for such a dictionary is the means=
 by which to build the searching functionality. As such, I would say that t=
his dictionary type should not even expose the order as a functor parameter=
; there would be some default ordering for a type that could be specified, =
and that&#39;s the ordering that it always uses.<br></div></div></blockquot=
e><div><br></div><div><div>There are many questions on the fly:</div><div>-=
 Should we be able to have std:map&lt;std::uuid, Value&gt;? Definitely</div=
><div>- Should we be able to compare uuids with the natural operators? I&#3=
9;m not sure, maybe</div><div>- Should the &quot;default&quot; order of uui=
ds be fully specified? I would say yes, but I would also be fine with no<br=
></div><div><br></div>Also, I would want to say that the only benefit to le=
t uuid unspecified is to optimize the ordering across architectures.<br>But
 here, we could say that the missed optimizations on some architectures=20
might not be a big problem because it will still be really fast=20
(comparing at most 2x16 bytes).<br>So fully specifying the order might be g=
ood enough.<br>And the natural order would be bytewise. On x86, this could =
be implemented efficiently with SSE4.</div><div>And if the memory layout is=
 not specified, then it is even simpler.<br></div><div><br>However, a unspe=
cified order would also be viable.<br>There
 is already a standard type that have a not fully specified order: char.
 Because the signed of char is not specfied, so is its order.<br>How many t=
imes did you find this problematic? I believe not so many.<br>And how many =
people will need cross-platform order, while also not knowing the language =
differences on these platforms?<br><br>The unspecified order is not really =
problematic in practice.<br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8deb17dc-1a74-4097-99c9-8b5285ecdaae%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8deb17dc-1a74-=
4097-99c9-8b5285ecdaae%40isocpp.org</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3haiA6oRyeLWfv9_0JTC6h740AdXUUb3=
uWwz%3D3hoEQOsVg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haiA6oRye=
LWfv9_0JTC6h740AdXUUb3uWwz%3D3hoEQOsVg%40mail.gmail.com</a>.<br />

--0000000000004366a40571c1f1d1--

.

------=_Part_9071_214734073.1532453186572
Content-Type: multipart/alternative;
 boundary="----=_Part_9072_1311020918.1532453186573"

------=_Part_9072_1311020918.1532453186573
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Le mardi 24 juillet 2018 19:17:55 UTC+2, Richard Hodges a =C3=A9crit :
>
>
>
> On Tue, 24 Jul 2018 at 18:13, <floria...@gmail.com <javascript:>> wrote:
>
>>
>>
>> Le mardi 24 juillet 2018 19:03:30 UTC+2, Nicol Bolas a =C3=A9crit :
>>>
>>>
>>>
>>> On Tuesday, July 24, 2018 at 12:37:38 PM UTC-4, Tony V E wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Jul 24, 2018 at 12:11 PM, Andrey Semashev <andrey....@gmail.co=
m
>>>> > wrote:
>>>>
>>>>> On 07/24/18 18:35, Tony V E wrote:
>>>>>
>>>>>> I really think the answer for all this is a way to have:
>>>>>>
>>>>>> Criteria:
>>>>>> - no < operator (or <=3D> etc)
>>>>>> - (thus) no std::less
>>>>>> - map "just works"
>>>>>>
>>>>>> My thoughts so far are either:
>>>>>>
>>>>>> A. map checks whether std::less "works" for the given type (this=20
>>>>>> requires some convoluted template stuff, but it can hide inside map =
and=20
>>>>>> std::less),
>>>>>> and if std::less doesn't work, something else (ie std::order) is=20
>>>>>> substituted.  std::order would probably default to compiler generate=
d=20
>>>>>> memberwise lexicographical order
>>>>>>
>>>>>> or
>>>>>>
>>>>>> B. The type (ie uuid) would define a internal typedef uuid::order=20
>>>>>> than map would look for.  This is more of an "opt-in" hack.  (And th=
us=20
>>>>>> uuid::order would need a less-likely name, ie uuid::order_for_map). =
=20
>>>>>> std::map would use K::order by default, or only when std::less doesn=
't=20
>>>>>> compile. Something like that.
>>>>>>
>>>>>> or
>>>>>>
>>>>>> C. something else.
>>>>>>
>>>>>> But the criteria at the top are, I think, what we want.
>>>>>>
>>>>>
>>>>> Personally, it looks like over-engineering to me. This approach=20
>>>>> introduces a new customization point, which does not seem necessary. =
Or a=20
>>>>> bit of magic in the interaction between map and uuid, which is worse.=
 IMHO,=20
>>>>> just defining the ordering operator for uuids and reusing the existin=
g=20
>>>>> infrastructure is the right way to go as it provides the most benefit=
 and=20
>>>>> causes the least surprise to users.
>>>>>
>>>>>
>>>>
>>>> Yes, it looks like over-engineering to me as well - I'd prefer a=20
>>>> simpler solution, or at least a way to "sell" it as appearing simple :=
-)
>>>> But it is also a problem that keeps coming up, and is causing ripple=
=20
>>>> effects elsewhere.
>>>>
>>>> We are now at the point where many (in the field and on the committee)=
=20
>>>> think almost all types should have <, even when meaningless.  All beca=
use,=20
>>>> essentially, map was misnamed.
>>>>
>>>
>>> Are people really so averse to adding that third template parameter?
>>>
>>
>> Because the default should just work out of the box. period.
>>
>
> Not when it's illogical. People should be prevented from doing illogical=
=20
> things at compile time. The correct container where the key is a uuid is =
an=20
> unordered_map.=20
>
> A std::map<uuid, T> should statically assert and refuse to compile, with=
=20
> an error message that refers the author to the UUID spec.
>
> Why is it illogical in that case?
Would your opinion change if there where a flat_map that has no unordered=
=20
equivalent?
Also, std::map<float, T> is valid while completely illogical... (I would=20
personally remove this one, but that's another story)

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/147cdc7d-32a3-4426-b2ad-43d8c577209a%40isocpp.or=
g.

------=_Part_9072_1311020918.1532453186573
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Le mardi 24 juillet 2018 19:17:55 UTC+2, Richard H=
odges a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, 24 =
Jul 2018 at 18:13, &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"XWlMyibBDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#=
39;;return true;">floria...@gmail.com</a>&gt; wrote:<br></div><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"><br><br>Le mardi 24 juillet 2018 19:03:3=
0 UTC+2, Nicol Bolas a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><br><br>On Tuesday, July 24, 2018 at 12:37:38 PM UTC-=
4, Tony V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<br><div><br><div class=3D"gmail_quote">On Tue, Jul 24, 2018 at 12:11 PM, A=
ndrey Semashev <span dir=3D"ltr">&lt;<a rel=3D"nofollow">andrey....@gmail.c=
om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 07/24/1=
8 18:35, Tony V E wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I really think the answer for all this is a way to have:<br>
<br>
Criteria:<br>
- no &lt; operator (or &lt;=3D&gt; etc)<br>
- (thus) no std::less<br>
- map &quot;just works&quot;<br>
<br>
My thoughts so far are either:<br>
<br>
A. map checks whether std::less &quot;works&quot; for the given type (this =
requires some convoluted template stuff, but it can hide inside map and std=
::less),<br>
and if std::less doesn&#39;t work, something else (ie std::order) is substi=
tuted.=C2=A0 std::order would probably default to compiler generated member=
wise lexicographical order<br>
<br>
or<br>
<br>
B. The type (ie uuid) would define a internal typedef uuid::order than map =
would look for.=C2=A0 This is more of an &quot;opt-in&quot; hack.=C2=A0 (An=
d thus uuid::order would need a less-likely name, ie uuid::order_for_map).=
=C2=A0 std::map would use K::order by default, or only when std::less doesn=
&#39;t compile. Something like that.<br>
<br>
or<br>
<br>
C. something else.<br>
<br>
But the criteria at the top are, I think, what we want.<br>
</blockquote>
<br></span>
Personally, it looks like over-engineering to me. This approach introduces =
a new customization point, which does not seem necessary. Or a bit of magic=
 in the interaction between map and uuid, which is worse. IMHO, just defini=
ng the ordering operator for uuids and reusing the existing infrastructure =
is the right way to go as it provides the most benefit and causes the least=
 surprise to users.<br>
<br></blockquote><div><br></div><div><br></div><div>Yes, it looks like over=
-engineering to me as well - I&#39;d prefer a simpler solution, or at least=
 a way to &quot;sell&quot; it as appearing simple :-)</div><div>But it is a=
lso a problem that keeps coming up, and is causing ripple effects elsewhere=
..</div><div><br></div><div>We are now at the point where many (in the field=
 and on the committee) think almost all types should have &lt;, even when m=
eaningless.=C2=A0 All because, essentially, map was misnamed.</div></div></=
div></div></blockquote><div><br></div><div>Are people really so averse to a=
dding that third template parameter?<br></div></div></blockquote><div><br><=
/div><div>Because the default should just work out of the box. period.<br><=
/div></div></blockquote><div><br></div><div>Not when it&#39;s illogical. Pe=
ople should be prevented from doing illogical things at compile time. The c=
orrect container where the key is a uuid is an unordered_map.=C2=A0</div><d=
iv><br></div><div>A std::map&lt;uuid, T&gt; should statically assert and re=
fuse to compile, with an error message that refers the author to the UUID s=
pec.</div><br></div></div></blockquote><div>Why is it illogical in that cas=
e?</div><div>Would your opinion change if there where a flat_map that has n=
o unordered equivalent?</div><div>Also, std::map&lt;float, T&gt; is valid w=
hile completely illogical... (I would personally remove this one, but that&=
#39;s another story)<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/147cdc7d-32a3-4426-b2ad-43d8c577209a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/147cdc7d-32a3-4426-b2ad-43d8c577209a=
%40isocpp.org</a>.<br />

------=_Part_9072_1311020918.1532453186573--

------=_Part_9071_214734073.1532453186572--

.

--00000000000093eb4e0571c21fc0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 24 Jul 2018 at 18:26, <florian.csdt@gmail.com> wrote:

>
>
> Le mardi 24 juillet 2018 19:17:55 UTC+2, Richard Hodges a =C3=A9crit :
>>
>>
>>
>> On Tue, 24 Jul 2018 at 18:13, <floria...@gmail.com> wrote:
>>
>>>
>>>
>>> Le mardi 24 juillet 2018 19:03:30 UTC+2, Nicol Bolas a =C3=A9crit :
>>>>
>>>>
>>>>
>>>> On Tuesday, July 24, 2018 at 12:37:38 PM UTC-4, Tony V E wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 24, 2018 at 12:11 PM, Andrey Semashev <
>>>>> andrey....@gmail.com> wrote:
>>>>>
>>>>>> On 07/24/18 18:35, Tony V E wrote:
>>>>>>
>>>>>>> I really think the answer for all this is a way to have:
>>>>>>>
>>>>>>> Criteria:
>>>>>>> - no < operator (or <=3D> etc)
>>>>>>> - (thus) no std::less
>>>>>>> - map "just works"
>>>>>>>
>>>>>>> My thoughts so far are either:
>>>>>>>
>>>>>>> A. map checks whether std::less "works" for the given type (this
>>>>>>> requires some convoluted template stuff, but it can hide inside map=
 and
>>>>>>> std::less),
>>>>>>> and if std::less doesn't work, something else (ie std::order) is
>>>>>>> substituted.  std::order would probably default to compiler generat=
ed
>>>>>>> memberwise lexicographical order
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> B. The type (ie uuid) would define a internal typedef uuid::order
>>>>>>> than map would look for.  This is more of an "opt-in" hack.  (And t=
hus
>>>>>>> uuid::order would need a less-likely name, ie uuid::order_for_map).
>>>>>>> std::map would use K::order by default, or only when std::less does=
n't
>>>>>>> compile. Something like that.
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> C. something else.
>>>>>>>
>>>>>>> But the criteria at the top are, I think, what we want.
>>>>>>>
>>>>>>
>>>>>> Personally, it looks like over-engineering to me. This approach
>>>>>> introduces a new customization point, which does not seem necessary.=
 Or a
>>>>>> bit of magic in the interaction between map and uuid, which is worse=
.. IMHO,
>>>>>> just defining the ordering operator for uuids and reusing the existi=
ng
>>>>>> infrastructure is the right way to go as it provides the most benefi=
t and
>>>>>> causes the least surprise to users.
>>>>>>
>>>>>>
>>>>>
>>>>> Yes, it looks like over-engineering to me as well - I'd prefer a
>>>>> simpler solution, or at least a way to "sell" it as appearing simple =
:-)
>>>>> But it is also a problem that keeps coming up, and is causing ripple
>>>>> effects elsewhere.
>>>>>
>>>>> We are now at the point where many (in the field and on the committee=
)
>>>>> think almost all types should have <, even when meaningless.  All bec=
ause,
>>>>> essentially, map was misnamed.
>>>>>
>>>>
>>>> Are people really so averse to adding that third template parameter?
>>>>
>>>
>>> Because the default should just work out of the box. period.
>>>
>>
>> Not when it's illogical. People should be prevented from doing illogical
>> things at compile time. The correct container where the key is a uuid is=
 an
>> unordered_map.
>>
>> A std::map<uuid, T> should statically assert and refuse to compile, with
>> an error message that refers the author to the UUID spec.
>>
>> Why is it illogical in that case?
>

Because a UUID carries no semantic concept of ordering. They are not
logically orderable. They are merely unique.

It's like trying to order human fingerprints. It makes no sense.


> Would your opinion change if there where a flat_map that has no unordered
> equivalent?
>

No. UUIDs are about unique identification only. Data structures that carry
a UUID which also need to be ordered (e.g. by timestamp) will carry other
orderable members. Use those for ordered indexes.


> Also, std::map<float, T> is valid while completely illogical... (I would
> personally remove this one, but that's another story)
>

It should certainly emit a warning, becoming an error in 2023.


> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/147cdc7d-32a=
3-4426-b2ad-43d8c577209a%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/147cdc7d-32=
a3-4426-b2ad-43d8c577209a%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CALvx3hbocS%3D_dxqjitHcdR1tjoxuWuSmYxN94cbQayPmj=
Ea9Vg%40mail.gmail.com.

--00000000000093eb4e0571c21fc0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, 24 Jul 2018 at 18:26, &lt;<a href=3D"mailto:florian.csdt@gmail.com">flori=
an.csdt@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><br><br>Le mardi 24 juillet 2018 19:17:55 UTC+2, Richard Hod=
ges a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, 24 Jul 201=
8 at 18:13, &lt;<a rel=3D"nofollow">floria...@gmail.com</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>Le mardi 24 ju=
illet 2018 19:03:30 UTC+2, Nicol Bolas a =C3=A9crit=C2=A0:<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"><br><br>On Tuesday, July 24, 2018 a=
t 12:37:38 PM UTC-4, Tony V E wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><br><div><br><div class=3D"gmail_quote">On Tue, Jul 24, 2=
018 at 12:11 PM, Andrey Semashev <span dir=3D"ltr">&lt;<a rel=3D"nofollow">=
andrey....@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><span>On 07/24/18 18:35, Tony V E wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I really think the answer for all this is a way to have:<br>
<br>
Criteria:<br>
- no &lt; operator (or &lt;=3D&gt; etc)<br>
- (thus) no std::less<br>
- map &quot;just works&quot;<br>
<br>
My thoughts so far are either:<br>
<br>
A. map checks whether std::less &quot;works&quot; for the given type (this =
requires some convoluted template stuff, but it can hide inside map and std=
::less),<br>
and if std::less doesn&#39;t work, something else (ie std::order) is substi=
tuted.=C2=A0 std::order would probably default to compiler generated member=
wise lexicographical order<br>
<br>
or<br>
<br>
B. The type (ie uuid) would define a internal typedef uuid::order than map =
would look for.=C2=A0 This is more of an &quot;opt-in&quot; hack.=C2=A0 (An=
d thus uuid::order would need a less-likely name, ie uuid::order_for_map).=
=C2=A0 std::map would use K::order by default, or only when std::less doesn=
&#39;t compile. Something like that.<br>
<br>
or<br>
<br>
C. something else.<br>
<br>
But the criteria at the top are, I think, what we want.<br>
</blockquote>
<br></span>
Personally, it looks like over-engineering to me. This approach introduces =
a new customization point, which does not seem necessary. Or a bit of magic=
 in the interaction between map and uuid, which is worse. IMHO, just defini=
ng the ordering operator for uuids and reusing the existing infrastructure =
is the right way to go as it provides the most benefit and causes the least=
 surprise to users.<br>
<br></blockquote><div><br></div><div><br></div><div>Yes, it looks like over=
-engineering to me as well - I&#39;d prefer a simpler solution, or at least=
 a way to &quot;sell&quot; it as appearing simple :-)</div><div>But it is a=
lso a problem that keeps coming up, and is causing ripple effects elsewhere=
..</div><div><br></div><div>We are now at the point where many (in the field=
 and on the committee) think almost all types should have &lt;, even when m=
eaningless.=C2=A0 All because, essentially, map was misnamed.</div></div></=
div></div></blockquote><div><br></div><div>Are people really so averse to a=
dding that third template parameter?<br></div></div></blockquote><div><br><=
/div><div>Because the default should just work out of the box. period.<br><=
/div></div></blockquote><div><br></div><div>Not when it&#39;s illogical. Pe=
ople should be prevented from doing illogical things at compile time. The c=
orrect container where the key is a uuid is an unordered_map.=C2=A0</div><d=
iv><br></div><div>A std::map&lt;uuid, T&gt; should statically assert and re=
fuse to compile, with an error message that refers the author to the UUID s=
pec.</div><br></div></div></blockquote><div>Why is it illogical in that cas=
e?</div></div></blockquote><div><br></div><div>Because a UUID carries no se=
mantic concept of ordering. They are not logically orderable. They are mere=
ly unique.</div><div><br></div><div>It&#39;s like trying to order human fin=
gerprints. It makes no sense.</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>Would your opinion change if there where a fl=
at_map that has no unordered equivalent?</div></div></blockquote><div><br><=
/div><div>No. UUIDs are about unique identification only. Data structures t=
hat carry a UUID which also need to be ordered (e.g. by timestamp) will car=
ry other orderable members. Use those for ordered indexes.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Also, std::map&l=
t;float, T&gt; is valid while completely illogical... (I would personally r=
emove this one, but that&#39;s another story)<br></div></div></blockquote><=
div><br></div><div>It should certainly emit a warning, becoming an error in=
 2023.</div><div>=C2=A0</div><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></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/147cdc7d-32a3-4426-b2ad-43d8c577209a%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/147cdc7d-32a3-=
4426-b2ad-43d8c577209a%40isocpp.org</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hbocS%3D_dxqjitHcdR1tjoxuWuSmYx=
N94cbQayPmjEa9Vg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbocS%3D_=
dxqjitHcdR1tjoxuWuSmYxN94cbQayPmjEa9Vg%40mail.gmail.com</a>.<br />

--00000000000093eb4e0571c21fc0--

.

On 07/24/18 20:17, Richard Hodges wrote:
>=20
> On Tue, 24 Jul 2018 at 18:13, <florian.csdt@gmail.com=20
> <mailto:florian.csdt@gmail.com>> wrote:
>=20
>     Le mardi 24 juillet 2018 19:03:30 UTC+2, Nicol Bolas a =C3=A9crit=C2=
=A0:
>=20
>         Are people really so averse to adding that third template paramet=
er?
>=20
>     Because the default should just work out of the box. period.
>=20
> Not when it's illogical. People should be prevented from doing illogical=
=20
> things at compile time. The correct container where the key is a uuid is=
=20
> an unordered_map.

Arbitrary ordering is not illogical. Most of the time this is the kind=20
of ordering you need to implement lookup.

unordered_map may have implications on lookup performance. For example,=20
when data comes from external sources, hash function may become a target=20
for an attack.

> A std::map<uuid, T> should statically assert and refuse to compile, with=
=20
> an error message that refers the author to the UUID spec.

What is the benefit of this limitation? I could have=20
boost::intrusive::set of elements with an ordering predicate that=20
involves uuids only as a part of what could be called "a composite key",=20
with other parts supporting ordering. Prohibiting ordering uuids gives=20
me no benefits and only forces implementing workarounds.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5cc78a49-ebf7-9857-c2f4-fe2d8ad73cf1%40gmail.com=
..

.

--00000000000019c3100571c232dd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 24 Jul 2018 at 18:31, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On 07/24/18 20:17, Richard Hodges wrote:
> >
> > On Tue, 24 Jul 2018 at 18:13, <florian.csdt@gmail.com
> > <mailto:florian.csdt@gmail.com>> wrote:
> >
> >     Le mardi 24 juillet 2018 19:03:30 UTC+2, Nicol Bolas a =C3=A9crit :
> >
> >         Are people really so averse to adding that third template
> parameter?
> >
> >     Because the default should just work out of the box. period.
> >
> > Not when it's illogical. People should be prevented from doing illogica=
l
> > things at compile time. The correct container where the key is a uuid i=
s
> > an unordered_map.
>
> Arbitrary ordering is not illogical. Most of the time this is the kind
> of ordering you need to implement lookup.
>

Inefficient lookup.


>
> unordered_map may have implications on lookup performance. For example,
> when data comes from external sources, hash function may become a target
> for an attack.
>

Google submitted a paper on the deficiencies of std::hash and how to fix
it. It specifically covered predictability as a problem. Not just for
security, but also because of the kind of developer behaviour it encourages=
..


>
> > A std::map<uuid, T> should statically assert and refuse to compile, wit=
h
> > an error message that refers the author to the UUID spec.
>
> What is the benefit of this limitation? I could have
> boost::intrusive::set of elements with an ordering predicate that
> involves uuids only as a part of what could be called "a composite key",
> with other parts supporting ordering. Prohibiting ordering uuids gives
> me no benefits and only forces implementing workarounds.
>

If it's a UUID it has no place in an ordered index. There will be other
fields in your data on which you can order. The UUID in your row is to
uniquely identify this row or some other entity. Again, think fingerprints
rather than date of birth.


>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5cc78a49-ebf=
7-9857-c2f4-fe2d8ad73cf1%40gmail.com
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CALvx3hbL8v4TKxnLWCx7frKcgPf%2BtrdO0ajnicm%2BHLd=
SREu_6A%40mail.gmail.com.

--00000000000019c3100571c232dd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, 24 Jul 2018 at 18:31, Andrey Semashev &lt;<a href=3D"mailto:andrey.semash=
ev@gmail.com">andrey.semashev@gmail.com</a>&gt; wrote:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">On 07/24/18 20:17, Richard Hodges wrote:<br>
&gt; <br>
&gt; On Tue, 24 Jul 2018 at 18:13, &lt;<a href=3D"mailto:florian.csdt@gmail=
..com" target=3D"_blank">florian.csdt@gmail.com</a> <br>
&gt; &lt;mailto:<a href=3D"mailto:florian.csdt@gmail.com" target=3D"_blank"=
>florian.csdt@gmail.com</a>&gt;&gt; wrote:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0Le mardi 24 juillet 2018 19:03:30 UTC+2, Nicol Bola=
s a =C3=A9crit=C2=A0:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Are people really so averse to adding=
 that third template parameter?<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0Because the default should just work out of the box=
.. period.<br>
&gt; <br>
&gt; Not when it&#39;s illogical. People should be prevented from doing ill=
ogical <br>
&gt; things at compile time. The correct container where the key is a uuid =
is <br>
&gt; an unordered_map.<br>
<br>
Arbitrary ordering is not illogical. Most of the time this is the kind <br>
of ordering you need to implement lookup.<br></blockquote><div><br></div><d=
iv>Inefficient lookup.</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<br>
unordered_map may have implications on lookup performance. For example, <br=
>
when data comes from external sources, hash function may become a target <b=
r>
for an attack.<br></blockquote><div><br></div><div>Google submitted a paper=
 on the deficiencies of std::hash and how to fix it. It specifically covere=
d predictability as a problem. Not just for security, but also because of t=
he kind of developer behaviour it encourages.</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<br>
&gt; A std::map&lt;uuid, T&gt; should statically assert and refuse to compi=
le, with <br>
&gt; an error message that refers the author to the UUID spec.<br>
<br>
What is the benefit of this limitation? I could have <br>
boost::intrusive::set of elements with an ordering predicate that <br>
involves uuids only as a part of what could be called &quot;a composite key=
&quot;, <br>
with other parts supporting ordering. Prohibiting ordering uuids gives <br>
me no benefits and only forces implementing workarounds.<br></blockquote><d=
iv><br></div><div>If it&#39;s a UUID it has no place in an ordered index. T=
here will be other fields in your data on which you can order. The UUID in =
your row is to uniquely identify this row or some other entity. Again, thin=
k fingerprints rather than date of birth.=C2=A0</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5cc78a49-ebf7-9857-c2f4-fe2d8ad73cf1%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/5cc78a49-ebf7-9857-c2f4-fe2d8ad73cf1%40=
gmail.com</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hbL8v4TKxnLWCx7frKcgPf%2BtrdO0a=
jnicm%2BHLdSREu_6A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbL8v4T=
KxnLWCx7frKcgPf%2BtrdO0ajnicm%2BHLdSREu_6A%40mail.gmail.com</a>.<br />

--00000000000019c3100571c232dd--

.

--0000000000002f332a0571c23d44
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 24, 2018 at 1:30 PM Richard Hodges <hodges.r@gmail.com> wrote:

> Because a UUID carries no semantic concept of ordering. They are not
> logically orderable. They are merely unique.
>

Wikipedia says,

In its canonical textual representation, the sixteen octets of a UUID are
represented as 32 hexadecimal (base 16) digits, displayed in five groups
separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters
(32 alphanumeric characters and four hyphens). For example:
123e4567-e89b-12d3-a456-426655440000

That suggests lexicographic ordering by group integer value.

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

--0000000000002f332a0571c23d44
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jul 24=
, 2018 at 1:30 PM Richard Hodges &lt;<a href=3D"mailto:hodges.r@gmail.com">=
hodges.r@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div class=3D"gmail_quote"><div>Because a UUID carries no seman=
tic concept of ordering. They are not logically orderable. They are merely =
unique.</div></div></div></blockquote><div><br>Wikipedia says,<br><br>In it=
s canonical textual representation, the sixteen octets of a UUID are repres=
ented as 32 hexadecimal (base 16) digits, displayed in five groups separate=
d by hyphens, in the form 8-4-4-4-12 for a total of 36 characters (32 alpha=
numeric characters and four hyphens). For example:<br>123e4567-e89b-12d3-a4=
56-426655440000<br><br>That suggests lexicographic ordering by group intege=
r value.</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYToeyJh12o_MzNZ3HW-vN%2BJJCwfZ=
xVYRA8yANvDh5Uew%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYToeyJh1=
2o_MzNZ3HW-vN%2BJJCwfZxVYRA8yANvDh5Uew%40mail.gmail.com</a>.<br />

--0000000000002f332a0571c23d44--

.

--0000000000005c0fab0571c25236
Content-Type: text/plain; charset="UTF-8"

On Tue, 24 Jul 2018 at 18:39, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> On Tue, Jul 24, 2018 at 1:30 PM Richard Hodges <hodges.r@gmail.com> wrote:
>
>> Because a UUID carries no semantic concept of ordering. They are not
>> logically orderable. They are merely unique.
>>
>
> Wikipedia says,
>
> In its canonical textual representation, the sixteen octets of a UUID are
> represented as 32 hexadecimal (base 16) digits, displayed in five groups
> separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters
> (32 alphanumeric characters and four hyphens). For example:
> 123e4567-e89b-12d3-a456-426655440000
>
> That suggests lexicographic ordering by group integer value.
>

That would be an ordering of textual representation, not a logical ordering
of the UUID. It would be like ordering two JPEGs by their base64-encoded
representations. Utterly pointless.



> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYToeyJh12o_MzNZ3HW-vN%2BJJCwfZxVYRA8yANvDh5Uew%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYToeyJh12o_MzNZ3HW-vN%2BJJCwfZxVYRA8yANvDh5Uew%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

--0000000000005c0fab0571c25236
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, 24 Jul 2018 at 18:39, Hyman Rosen &lt;<a href=3D"mailto:hyman.rosen@gmail=
..com">hyman.rosen@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, Jul 24, 2018 at 1:30 PM Richard Hodges &lt;<a href=3D"mailto:hodges.r@gma=
il.com" target=3D"_blank">hodges.r@gmail.com</a>&gt; wrote:</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 class=3D"gmail_quote"><div>Becau=
se a UUID carries no semantic concept of ordering. They are not logically o=
rderable. They are merely unique.</div></div></div></blockquote><div><br>Wi=
kipedia says,<br><br>In its canonical textual representation, the sixteen o=
ctets of a UUID are represented as 32 hexadecimal (base 16) digits, display=
ed in five groups separated by hyphens, in the form 8-4-4-4-12 for a total =
of 36 characters (32 alphanumeric characters and four hyphens). For example=
:<br>123e4567-e89b-12d3-a456-426655440000<br><br>That suggests lexicographi=
c ordering by group integer value.</div></div></div></blockquote><div><br><=
/div><div>That would be an ordering of textual representation, not a logica=
l ordering of the UUID. It would be like ordering two JPEGs by their base64=
-encoded representations. Utterly pointless.</div><div><br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYToeyJh12o_MzNZ3HW-vN%2BJJCwfZ=
xVYRA8yANvDh5Uew%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAHSYqdYToeyJh12o_MzNZ3HW-vN%2BJJCwfZxVYRA8yANvDh5Uew%40mail.gmail.c=
om</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hbZ_EH8caKT0SUAkY2f3hSTMcXL7HCa=
T5PTPB_ES34f4Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbZ_EH8caKT=
0SUAkY2f3hSTMcXL7HCaT5PTPB_ES34f4Q%40mail.gmail.com</a>.<br />

--0000000000005c0fab0571c25236--

.

On 07/24/18 20:35, Richard Hodges wrote:
>=20
>=20
> On Tue, 24 Jul 2018 at 18:31, Andrey Semashev <andrey.semashev@gmail.com=
=20
> <mailto:andrey.semashev@gmail.com>> wrote:
>=20
>     On 07/24/18 20:17, Richard Hodges wrote:
>      >
>      > On Tue, 24 Jul 2018 at 18:13, <florian.csdt@gmail.com
>     <mailto:florian.csdt@gmail.com>
>      > <mailto:florian.csdt@gmail.com <mailto:florian.csdt@gmail.com>>>
>     wrote:
>      >
>      >=C2=A0 =C2=A0 =C2=A0Le mardi 24 juillet 2018 19:03:30 UTC+2, Nicol =
Bolas a =C3=A9crit=C2=A0:
>      >
>      >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Are people really so averse to ad=
ding that third template
>     parameter?
>      >
>      >=C2=A0 =C2=A0 =C2=A0Because the default should just work out of the=
 box. period.
>      >
>      > Not when it's illogical. People should be prevented from doing
>     illogical
>      > things at compile time. The correct container where the key is a
>     uuid is
>      > an unordered_map.
>=20
>     Arbitrary ordering is not illogical. Most of the time this is the kin=
d
>     of ordering you need to implement lookup.
>=20
> Inefficient lookup.

How is it any less efficient than a similar lookup with a semantic ordering=
?

>      > A std::map<uuid, T> should statically assert and refuse to
>     compile, with
>      > an error message that refers the author to the UUID spec.
>=20
>     What is the benefit of this limitation? I could have
>     boost::intrusive::set of elements with an ordering predicate that
>     involves uuids only as a part of what could be called "a composite
>     key",
>     with other parts supporting ordering. Prohibiting ordering uuids give=
s
>     me no benefits and only forces implementing workarounds.
>=20
> If it's a UUID it has no place in an ordered index. There will be other=
=20
> fields in your data on which you can order. The UUID in your row is to=20
> uniquely identify this row or some other entity.

I'm sorry, but it doesn't work like that. There is a use case that=20
involves an uuid as a part of the key, so saying that it can't be used=20
in the lookup is not the answer.

I was particular about my question - what is the practical benefit of=20
your proposal? It doesn't make my code simpler, quite the opposite. Its=20
performance and security benefits are questionable. It doesn't make the=20
code more understandable. It looks like the only reason you made it is=20
because you require semantic ordering in general. If so then sorry, I=20
disagree.

> Again, think=20
> fingerprints rather than date of birth.

I'm not an expert, but AFAIK, matching fingerprints involves computing a=20
metric of similarity, which can be ordered (i.e. you can pick the one=20
set of fingerprints that gives the best match out of many).

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/37231a99-6b5a-72ee-f77b-437f324bd0ad%40gmail.com=
..

.

On 2018-07-24 13:26, florian.csdt@gmail.com wrote:
> Also, std::map<float, T> is valid while completely illogical... (I would
> personally remove this one, but that's another story)

Why?

I have a data set that consists of a bunch of items that have been
sampled over a real-valued interval. I need to be able to search on
these items according to their position on that interval.

A std::map<float, T> is the natural choice for such an operation.
(Though I will grant that doing equality key comparisons is probably
incorrect. Correct practice in this case will tend toward using
lower_bound/upper_bound instead, with maybe some helpers to do "fuzzy
find".)

--
Matthew

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

.

--000000000000af97ae0571c33e22
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 24 Jul 2018 at 19:52, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On 07/24/18 20:35, Richard Hodges wrote:
> >
> >
> > On Tue, 24 Jul 2018 at 18:31, Andrey Semashev <andrey.semashev@gmail.co=
m
> > <mailto:andrey.semashev@gmail.com>> wrote:
> >
> >     On 07/24/18 20:17, Richard Hodges wrote:
> >      >
> >      > On Tue, 24 Jul 2018 at 18:13, <florian.csdt@gmail.com
> >     <mailto:florian.csdt@gmail.com>
> >      > <mailto:florian.csdt@gmail.com <mailto:florian.csdt@gmail.com>>>
> >     wrote:
> >      >
> >      >     Le mardi 24 juillet 2018 19:03:30 UTC+2, Nicol Bolas a =C3=
=A9crit :
> >      >
> >      >         Are people really so averse to adding that third templat=
e
> >     parameter?
> >      >
> >      >     Because the default should just work out of the box. period.
> >      >
> >      > Not when it's illogical. People should be prevented from doing
> >     illogical
> >      > things at compile time. The correct container where the key is a
> >     uuid is
> >      > an unordered_map.
> >
> >     Arbitrary ordering is not illogical. Most of the time this is the
> kind
> >     of ordering you need to implement lookup.
> >
> > Inefficient lookup.
>
> How is it any less efficient than a similar lookup with a semantic
> ordering?
>
> >      > A std::map<uuid, T> should statically assert and refuse to
> >     compile, with
> >      > an error message that refers the author to the UUID spec.
> >
> >     What is the benefit of this limitation? I could have
> >     boost::intrusive::set of elements with an ordering predicate that
> >     involves uuids only as a part of what could be called "a composite
> >     key",
> >     with other parts supporting ordering. Prohibiting ordering uuids
> gives
> >     me no benefits and only forces implementing workarounds.
> >
> > If it's a UUID it has no place in an ordered index. There will be other
> > fields in your data on which you can order. The UUID in your row is to
> > uniquely identify this row or some other entity.
>
> I'm sorry, but it doesn't work like that. There is a use case that
> involves an uuid as a part of the key, so saying that it can't be used
> in the lookup is not the answer.
>
> I was particular about my question - what is the practical benefit of
> your proposal? It doesn't make my code simpler, quite the opposite. Its
> performance and security benefits are questionable. It doesn't make the
> code more understandable. It looks like the only reason you made it is
> because you require semantic ordering in general. If so then sorry, I
> disagree.
>
> > Again, think
> > fingerprints rather than date of birth.
>
> I'm not an expert, but AFAIK, matching fingerprints involves computing a
> metric of similarity, which can be ordered (i.e. you can pick the one
> set of fingerprints that gives the best match out of many).
>

In fairness, matching fingerprints is more akin to being given a UUID with
some bytes missing, and having to locate the most likely matching UUID from
a massive set.

By all means our "closeness" metric may be orderable in some way, but the
actual UUIDs or partial UUIDs, not so much.



>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/37231a99-6b5=
a-72ee-f77b-437f324bd0ad%40gmail.com
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CALvx3ha2LmXPma-8d1RCDqxmzSjrx-0eebxk9TykaNjSdY2=
_3g%40mail.gmail.com.

--000000000000af97ae0571c33e22
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, 24 Jul 2018 at 19:52, Andrey Semashev &lt;<a href=3D"mailto:andrey.semash=
ev@gmail.com">andrey.semashev@gmail.com</a>&gt; wrote:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">On 07/24/18 20:35, Richard Hodges wrote:<br>
&gt; <br>
&gt; <br>
&gt; On Tue, 24 Jul 2018 at 18:31, Andrey Semashev &lt;<a href=3D"mailto:an=
drey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gmail.com</a> <b=
r>
&gt; &lt;mailto:<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_bla=
nk">andrey.semashev@gmail.com</a>&gt;&gt; wrote:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0On 07/24/18 20:17, Richard Hodges wrote:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; On Tue, 24 Jul 2018 at 18:13, &lt;<a href=3D"=
mailto:florian.csdt@gmail.com" target=3D"_blank">florian.csdt@gmail.com</a>=
<br>
&gt;=C2=A0 =C2=A0 =C2=A0&lt;mailto:<a href=3D"mailto:florian.csdt@gmail.com=
" target=3D"_blank">florian.csdt@gmail.com</a>&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; &lt;mailto:<a href=3D"mailto:florian.csdt@gma=
il.com" target=3D"_blank">florian.csdt@gmail.com</a> &lt;mailto:<a href=3D"=
mailto:florian.csdt@gmail.com" target=3D"_blank">florian.csdt@gmail.com</a>=
&gt;&gt;&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0wrote:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;=C2=A0 =C2=A0 =C2=A0Le mardi 24 juillet 2018 1=
9:03:30 UTC+2, Nicol Bolas a =C3=A9crit=C2=A0:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Are people r=
eally so averse to adding that third template<br>
&gt;=C2=A0 =C2=A0 =C2=A0parameter?<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;=C2=A0 =C2=A0 =C2=A0Because the default should=
 just work out of the box. period.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; Not when it&#39;s illogical. People should be=
 prevented from doing<br>
&gt;=C2=A0 =C2=A0 =C2=A0illogical<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; things at compile time. The correct container=
 where the key is a<br>
&gt;=C2=A0 =C2=A0 =C2=A0uuid is<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; an unordered_map.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0Arbitrary ordering is not illogical. Most of the ti=
me this is the kind<br>
&gt;=C2=A0 =C2=A0 =C2=A0of ordering you need to implement lookup.<br>
&gt; <br>
&gt; Inefficient lookup.<br>
<br>
How is it any less efficient than a similar lookup with a semantic ordering=
?<br>
<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; A std::map&lt;uuid, T&gt; should statically a=
ssert and refuse to<br>
&gt;=C2=A0 =C2=A0 =C2=A0compile, with<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; an error message that refers the author to th=
e UUID spec.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0What is the benefit of this limitation? I could hav=
e<br>
&gt;=C2=A0 =C2=A0 =C2=A0boost::intrusive::set of elements with an ordering =
predicate that<br>
&gt;=C2=A0 =C2=A0 =C2=A0involves uuids only as a part of what could be call=
ed &quot;a composite<br>
&gt;=C2=A0 =C2=A0 =C2=A0key&quot;,<br>
&gt;=C2=A0 =C2=A0 =C2=A0with other parts supporting ordering. Prohibiting o=
rdering uuids gives<br>
&gt;=C2=A0 =C2=A0 =C2=A0me no benefits and only forces implementing workaro=
unds.<br>
&gt; <br>
&gt; If it&#39;s a UUID it has no place in an ordered index. There will be =
other <br>
&gt; fields in your data on which you can order. The UUID in your row is to=
 <br>
&gt; uniquely identify this row or some other entity.<br>
<br>
I&#39;m sorry, but it doesn&#39;t work like that. There is a use case that =
<br>
involves an uuid as a part of the key, so saying that it can&#39;t be used =
<br>
in the lookup is not the answer.<br>
<br>
I was particular about my question - what is the practical benefit of <br>
your proposal? It doesn&#39;t make my code simpler, quite the opposite. Its=
 <br>
performance and security benefits are questionable. It doesn&#39;t make the=
 <br>
code more understandable. It looks like the only reason you made it is <br>
because you require semantic ordering in general. If so then sorry, I <br>
disagree.<br>
<br>
&gt; Again, think <br>
&gt; fingerprints rather than date of birth.<br>
<br>
I&#39;m not an expert, but AFAIK, matching fingerprints involves computing =
a <br>
metric of similarity, which can be ordered (i.e. you can pick the one <br>
set of fingerprints that gives the best match out of many).<br></blockquote=
><div><br></div><div>In fairness, matching fingerprints is more akin to bei=
ng given a UUID with some bytes missing, and having to locate the most like=
ly matching UUID from a massive set.</div><div><br></div><div>By all means =
our &quot;closeness&quot; metric may be orderable in some way, but the actu=
al UUIDs or partial UUIDs, not so much.</div><div><br></div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/37231a99-6b5a-72ee-f77b-437f324bd0ad%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/37231a99-6b5a-72ee-f77b-437f324bd0ad%40=
gmail.com</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3ha2LmXPma-8d1RCDqxmzSjrx-0eebxk=
9TykaNjSdY2_3g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3ha2LmXPma-8=
d1RCDqxmzSjrx-0eebxk9TykaNjSdY2_3g%40mail.gmail.com</a>.<br />

--000000000000af97ae0571c33e22--

.

On 2018-07-24 13:30, Andrey Semashev wrote:
> Arbitrary ordering is not illogical. Most of the time this is the kind
> of ordering you need to implement lookup.

"Because our hashing function has a security vulnerability" is a
terrible argument why we need map<uuid>. If there is any validity to
that argument, we need to fix our hashing, instead.

(I am recalling something I noticed over in Qt's world about whether
QHash could be deprecated that mentioned std::hash and salting...)

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dee7b6d1-2f61-3840-8eae-29dfae11aab7%40gmail.com.

.

On 2018-07-24 13:52, Andrey Semashev wrote:
> On 07/24/18 20:35, Richard Hodges wrote:
>> Again, think fingerprints rather than date of birth.
>
> I'm not an expert, but AFAIK, matching fingerprints involves computing a
> metric of similarity, which can be ordered (i.e. you can pick the one
> set of fingerprints that gives the best match out of many).

So... your proposal would be to arbitrarily pick some "master"
fingerprint and order the fingerprints in your database based on how
similar they are to this "master" fingerprint?

That... is just downright bizarre.

Maybe we should change map<string> to order based on how many letters
have to be added/changed/removed in order to transmute the key into a
copy of the Gettysburg Address.

--
Matthew

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

.

--00000000000049e5a60571c38d78
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 24, 2018 at 1:45 PM Richard Hodges <hodges.r@gmail.com> wrote:

> On Tue, 24 Jul 2018 at 18:39, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>
>> That suggests lexicographic ordering by group integer value.
>>
> That would be an ordering of textual representation, not a logical
> ordering of the UUID. It would be like ordering two JPEGs by their
> base64-encoded representations. Utterly pointless.
>

It provides a portable total ordering of UUIDs.  That's point enough.
It makes just as much sense as lexicographic ordering of strings.

Besides which, here is a quote from RFC 4122, which defines UUIDs:
<https://tools.ietf.org/html/rfc4122>

      UUIDs, as defined in this document, can also be ordered
      lexicographically.  For a pair of UUIDs, the first one follows the
      second if the most significant field in which the UUIDs differ is
      greater for the first UUID.  The second precedes the first if the
      most significant field in which the UUIDs differ is greater for
      the second UUID.


When the defining document for UUIDs defines their order, it is hardly
"pointless"
to ask that this ordering be implemented.

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

--00000000000049e5a60571c38d78
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jul 24=
, 2018 at 1:45 PM Richard Hodges &lt;<a href=3D"mailto:hodges.r@gmail.com">=
hodges.r@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Tue, 24 Jul 2018 at 18:39, Hyman Rosen &lt;<a href=3D"mailto:hyman.rosen=
@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>&gt; wrote:</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_quote"><div>That suggests lexicographic ordering by group integer=
 value.</div></div></div></blockquote><div>That would be an ordering of tex=
tual representation, not a logical ordering of the UUID. It would be like o=
rdering two JPEGs by their base64-encoded representations. Utterly pointles=
s.</div></div></div></blockquote><div><br>It provides a portable total orde=
ring of UUIDs.=C2=A0 That&#39;s point enough.<br>It makes just as much sens=
e as lexicographic ordering of strings.<br><br>Besides which, here is a quo=
te from RFC 4122, which defines UUIDs:<br>&lt;<a href=3D"https://tools.ietf=
..org/html/rfc4122">https://tools.ietf.org/html/rfc4122</a>&gt;<br>

<pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;ma=
rgin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:in=
itial;text-decoration-color:initial">      UUIDs, as defined in this docume=
nt, can also be ordered
      lexicographically.  For a pair of UUIDs, the first one follows the
      second if the most significant field in which the UUIDs differ is
      greater for the first UUID.  The second precedes the first if the
      most significant field in which the UUIDs differ is greater for
      the second UUID.</pre>

<br>When the defining document for UUIDs defines their order, it is hardly =
&quot;pointless&quot;<br>to ask that this ordering be implemented.</div></d=
iv></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYqiTY3MExXxijg%3DcG5PwTuFqrFLA=
nYqCar5B%3D6uaXu9Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYqiTY3=
MExXxijg%3DcG5PwTuFqrFLAnYqCar5B%3D6uaXu9Q%40mail.gmail.com</a>.<br />

--00000000000049e5a60571c38d78--

.

On July 24, 2018 11:01:25 PM Andrey Semashev <andrey.semashev@gmail.com> wrote:

> On July 24, 2018 9:57:22 PM Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>
>> On 2018-07-24 13:52, Andrey Semashev wrote:
>>> On 07/24/18 20:35, Richard Hodges wrote:
>>>> Again, think fingerprints rather than date of birth.
>>>
>>> I'm not an expert, but AFAIK, matching fingerprints involves computing a
>>> metric of similarity, which can be ordered (i.e. you can pick the one
>>> set of fingerprints that gives the best match out of many).
>>
>> So... your proposal would be to arbitrarily pick some "master"
>> fingerprint and order the fingerprints in your database based on how
>> similar they are to this "master" fingerprint?
>
> I have no idea and no intention to propose a solution to fingerprint
> lookup. My point was only that fingerprints could be reasonably ordered in
> some context.
>
>> That... is just downright bizarre.
>>
>> Maybe we should change map<string> to order based on how many letters
>> have to be added/changed/removed in order to transmute the key into a
>> copy of the Gettysburg Address.
>
> Actually, I did have a case when I needed to find an entry of a data
> structure with a string key closest to input. Having something to help
> solving this class of problems in the standard library would be useful.
>
> Anyway, all this is OT.

Sorry, I meant to send it to the list.



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

.

--000000000000ef92040571c5684b
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 24, 2018 at 3:12 PM, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> On Tue, Jul 24, 2018 at 1:45 PM Richard Hodges <hodges.r@gmail.com> wrote:
>
>> On Tue, 24 Jul 2018 at 18:39, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>>
>>> That suggests lexicographic ordering by group integer value.
>>>
>> That would be an ordering of textual representation, not a logical
>> ordering of the UUID. It would be like ordering two JPEGs by their
>> base64-encoded representations. Utterly pointless.
>>
>
> It provides a portable total ordering of UUIDs.  That's point enough.
> It makes just as much sense as lexicographic ordering of strings.
>
> Besides which, here is a quote from RFC 4122, which defines UUIDs:
> <https://tools.ietf.org/html/rfc4122>
>
>       UUIDs, as defined in this document, can also be ordered
>       lexicographically.  For a pair of UUIDs, the first one follows the
>       second if the most significant field in which the UUIDs differ is
>       greater for the first UUID.  The second precedes the first if the
>       most significant field in which the UUIDs differ is greater for
>       the second UUID.
>
>
> When the defining document for UUIDs defines their order, it is hardly
> "pointless"
> to ask that this ordering be implemented.
>


Is that "can" in "can also be ordered..." just a statement of fact, or a
suggestion?

If we fix the representation (ie expose it via span<uint_least8_t> or
something), then that ordering might be slower on some systems.  Is it
worth it to enforce an ordering that would be consistent across
implementations, but ultimately meaningless?


--
Be seeing you,
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivv5S%2BxGh7JWuvckJT0boo34s5e%3D%2BtWaFeKk1H3iot8uA%40mail.gmail.com.

--000000000000ef92040571c5684b
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 Tue, Jul 24, 2018 at 3:12 PM, Hyman Rosen <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_quote"><span class=3D""><div dir=3D"ltr">On Tue, Jul 24=
, 2018 at 1:45 PM Richard Hodges &lt;<a href=3D"mailto:hodges.r@gmail.com" =
target=3D"_blank">hodges.r@gmail.com</a>&gt; wrote:</div></span><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail=
_quote"><span class=3D""><div dir=3D"ltr">On Tue, 24 Jul 2018 at 18:39, Hym=
an Rosen &lt;<a href=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hym=
an.rosen@gmail.com</a>&gt; wrote:</div></span><span class=3D""><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_=
quote"><div>That suggests lexicographic ordering by group integer value.</d=
iv></div></div></blockquote><div>That would be an ordering of textual repre=
sentation, not a logical ordering of the UUID. It would be like ordering tw=
o JPEGs by their base64-encoded representations. Utterly pointless.</div></=
span></div></div></blockquote><div><br>It provides a portable total orderin=
g of UUIDs.=C2=A0 That&#39;s point enough.<br>It makes just as much sense a=
s lexicographic ordering of strings.<br><br>Besides which, here is a quote =
from RFC 4122, which defines UUIDs:<br>&lt;<a href=3D"https://tools.ietf.or=
g/html/rfc4122" target=3D"_blank">https://tools.ietf.org/html/<wbr>rfc4122<=
/a>&gt;<br>

<pre class=3D"m_3752108083543368251gmail-newpage" style=3D"font-size:13.333=
3px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);tex=
t-decoration-style:initial;text-decoration-color:initial">      UUIDs, as d=
efined in this document, can also be ordered
      lexicographically.  For a pair of UUIDs, the first one follows the
      second if the most significant field in which the UUIDs differ is
      greater for the first UUID.  The second precedes the first if the
      most significant field in which the UUIDs differ is greater for
      the second UUID.</pre>

<br>When the defining document for UUIDs defines their order, it is hardly =
&quot;pointless&quot;<br>to ask that this ordering be implemented.</div></d=
iv></div></blockquote><div><br></div><div><br></div><div>Is that &quot;can&=
quot; in &quot;can also be ordered...&quot; just a statement of fact, or a =
suggestion?</div><div><br></div><div>If we fix the representation (ie expos=
e it via span&lt;uint_least8_t&gt; or something), then that ordering might =
be slower on some systems.=C2=A0 Is it worth it to enforce an ordering that=
 would be consistent across implementations, but ultimately meaningless?<br=
></div><br clear=3D"all"></div><br>-- <br><div class=3D"gmail_signature" da=
ta-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></=
div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivv5S%2BxGh7JWuvckJT0boo34s5e%3=
D%2BtWaFeKk1H3iot8uA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivv5S=
%2BxGh7JWuvckJT0boo34s5e%3D%2BtWaFeKk1H3iot8uA%40mail.gmail.com</a>.<br />

--000000000000ef92040571c5684b--

.

--0000000000008300e00571c58b5c
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 24, 2018 at 5:26 PM Tony V E <tvaneerd@gmail.com> wrote:

> Is it worth it to enforce an ordering that would be consistent across
> implementations, but ultimately meaningless?
>

Yes.  Any time you find yourself deciding not to do something sensible
because
you think it would be it faster to do something else, notice that you're
succumbing
to optimizationism and don't let yourself do that.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYq-qTg%2BH9NZKdYQXvgFQj%3DBUJv2D_CyQeiunBHgHELew%40mail.gmail.com.

--0000000000008300e00571c58b5c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jul 24=
, 2018 at 5:26 PM Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com">tvanee=
rd@gmail.com</a>&gt; wrote:</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 class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Is it wort=
h it to enforce an ordering that would be consistent across implementations=
, but ultimately meaningless?<br></div></div></div></div></blockquote><div>=
<br>Yes.=C2=A0 Any time you find yourself deciding not to do something sens=
ible because<br>you think it would be it faster to do something else, notic=
e that you&#39;re succumbing<br>to optimizationism and don&#39;t let yourse=
lf do that.</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYq-qTg%2BH9NZKdYQXvgFQj%3DBUJv=
2D_CyQeiunBHgHELew%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYq-qTg=
%2BH9NZKdYQXvgFQj%3DBUJv2D_CyQeiunBHgHELew%40mail.gmail.com</a>.<br />

--0000000000008300e00571c58b5c--

.

--0000000000008eaaa50571c68e9e
Content-Type: text/plain; charset="UTF-8"

On Tue, 24 Jul 2018 at 21:13, Hyman Rosen <hyman.rosen@gmail.com> wrote:

> On Tue, Jul 24, 2018 at 1:45 PM Richard Hodges <hodges.r@gmail.com> wrote:
>
>> On Tue, 24 Jul 2018 at 18:39, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>>
>>> That suggests lexicographic ordering by group integer value.
>>>
>> That would be an ordering of textual representation, not a logical
>> ordering of the UUID. It would be like ordering two JPEGs by their
>> base64-encoded representations. Utterly pointless.
>>
>
> It provides a portable total ordering of UUIDs.  That's point enough.
> It makes just as much sense as lexicographic ordering of strings.
>
> Besides which, here is a quote from RFC 4122, which defines UUIDs:
> <https://tools.ietf.org/html/rfc4122>
>
>       UUIDs, as defined in this document, can also be ordered
>       lexicographically.  For a pair of UUIDs, the first one follows the
>       second if the most significant field in which the UUIDs differ is
>       greater for the first UUID.  The second precedes the first if the
>       most significant field in which the UUIDs differ is greater for
>       the second UUID.
>
>
> When the defining document for UUIDs defines their order, it is hardly
> "pointless"
> to ask that this ordering be implemented.
>

I think you make an excellent point. I bow to the authority of the RFC and
agree that lexical ordering would be the logic default ordering choice in
order to match the wording of the document.

I still think that the ordering is pointless, but a specification is a
specification and a user of an UUID object will expect it to implement the
specification fully.

I reverse my earlier arguments as to whether there should be an operator <.

With the caveat that anyone caught using it in one of my projects would
need to be prepared to explain themselves!


> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYqiTY3MExXxijg%3DcG5PwTuFqrFLAnYqCar5B%3D6uaXu9Q%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYqiTY3MExXxijg%3DcG5PwTuFqrFLAnYqCar5B%3D6uaXu9Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3ha9AX8vDfco2dmyAsbj66Av7%2BiK%2BvB%2BGsnday%2BtV_QVdg%40mail.gmail.com.

--0000000000008eaaa50571c68e9e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, 24 Jul 2018 at 21:13, Hyman Rosen &lt;<a href=3D"mailto:hyman.rosen@gmail=
..com">hyman.rosen@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, Jul 24, 2018 at 1:45 PM Richard Hodges &lt;<a href=3D"mailto:hodges.r@gma=
il.com" target=3D"_blank">hodges.r@gmail.com</a>&gt; wrote:</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmai=
l_quote"><div dir=3D"ltr">On Tue, 24 Jul 2018 at 18:39, Hyman Rosen &lt;<a =
href=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.c=
om</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><div class=3D"gmail_quote"><div>That suggests lexicographic =
ordering by group integer value.</div></div></div></blockquote><div>That wo=
uld be an ordering of textual representation, not a logical ordering of the=
 UUID. It would be like ordering two JPEGs by their base64-encoded represen=
tations. Utterly pointless.</div></div></div></blockquote><div><br>It provi=
des a portable total ordering of UUIDs.=C2=A0 That&#39;s point enough.<br>I=
t makes just as much sense as lexicographic ordering of strings.<br><br>Bes=
ides which, here is a quote from RFC 4122, which defines UUIDs:<br>&lt;<a h=
ref=3D"https://tools.ietf.org/html/rfc4122" target=3D"_blank">https://tools=
..ietf.org/html/rfc4122</a>&gt;<br>

<pre class=3D"m_-8415730193911092488gmail-newpage" style=3D"font-size:13.33=
33px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);te=
xt-decoration-style:initial;text-decoration-color:initial">      UUIDs, as =
defined in this document, can also be ordered
      lexicographically.  For a pair of UUIDs, the first one follows the
      second if the most significant field in which the UUIDs differ is
      greater for the first UUID.  The second precedes the first if the
      most significant field in which the UUIDs differ is greater for
      the second UUID.</pre>

<br>When the defining document for UUIDs defines their order, it is hardly =
&quot;pointless&quot;<br>to ask that this ordering be implemented.</div></d=
iv></div></blockquote><div><br></div><div>I think you make an excellent poi=
nt. I bow to the authority of the RFC and agree that lexical ordering would=
 be the logic default ordering choice in order to match the wording of the =
document.</div><div><br></div><div>I still think that the ordering is point=
less, but a specification is a specification and a user of an UUID object w=
ill expect it to implement the specification fully.</div><div><br></div><di=
v>I reverse my earlier arguments as to whether there should be an operator =
&lt;.</div><div><br></div><div>With the caveat that anyone caught using it =
in one of my projects would need to be prepared to explain themselves!</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">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYqiTY3MExXxijg%3DcG5PwTuFqrFLA=
nYqCar5B%3D6uaXu9Q%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAHSYqdYqiTY3MExXxijg%3DcG5PwTuFqrFLAnYqCar5B%3D6uaXu9Q%40mail.gma=
il.com</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3ha9AX8vDfco2dmyAsbj66Av7%2BiK%2=
BvB%2BGsnday%2BtV_QVdg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3ha9=
AX8vDfco2dmyAsbj66Av7%2BiK%2BvB%2BGsnday%2BtV_QVdg%40mail.gmail.com</a>.<br=
 />

--0000000000008eaaa50571c68e9e--

.

--000000000000809f870571ce59fc
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 24, 2018 at 11:48 PM, Richard Hodges <hodges.r@gmail.com> wrote:

>
>
> On Tue, 24 Jul 2018 at 21:13, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>
>> On Tue, Jul 24, 2018 at 1:45 PM Richard Hodges <hodges.r@gmail.com>
>> wrote:
>>
>>> On Tue, 24 Jul 2018 at 18:39, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>>>
>>>> That suggests lexicographic ordering by group integer value.
>>>>
>>> That would be an ordering of textual representation, not a logical
>>> ordering of the UUID. It would be like ordering two JPEGs by their
>>> base64-encoded representations. Utterly pointless.
>>>
>>
>> It provides a portable total ordering of UUIDs.  That's point enough.
>> It makes just as much sense as lexicographic ordering of strings.
>>
>> Besides which, here is a quote from RFC 4122, which defines UUIDs:
>> <https://tools.ietf.org/html/rfc4122>
>>
>>       UUIDs, as defined in this document, can also be ordered
>>       lexicographically.  For a pair of UUIDs, the first one follows the
>>       second if the most significant field in which the UUIDs differ is
>>       greater for the first UUID.  The second precedes the first if the
>>       most significant field in which the UUIDs differ is greater for
>>       the second UUID.
>>
>>
>> When the defining document for UUIDs defines their order, it is hardly
>> "pointless"
>> to ask that this ordering be implemented.
>>
>
> I think you make an excellent point. I bow to the authority of the RFC and
> agree that lexical ordering would be the logic default ordering choice in
> order to match the wording of the document.
>
> I still think that the ordering is pointless, but a specification is a
> specification and a user of an UUID object will expect it to implement the
> specification fully.
>
> I reverse my earlier arguments as to whether there should be an operator <.
>
> With the caveat that anyone caught using it in one of my projects would
> need to be prepared to explain themselves!
>
>

You could say that for quite a few of C++'s features!

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

--000000000000809f870571ce59fc
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 Tue, Jul 24, 2018 at 11:48 PM, Richard Hodges <span dir=3D"ltr">&lt;=
<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><b=
r><br><div class=3D"gmail_quote"><span><div dir=3D"ltr">On Tue, 24 Jul 2018=
 at 21:13, Hyman Rosen &lt;<a href=3D"mailto:hyman.rosen@gmail.com" target=
=3D"_blank">hyman.rosen@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Tue, Jul 24, 2018 at 1:45 PM Richard Hodges &lt;<a href=3D"mailto:hodges=
..r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>&gt; wrote:</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Tue, 24 Jul 2018 at 18:39, Hyman Rosen=
 &lt;<a href=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen=
@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>That suggests lexico=
graphic ordering by group integer value.</div></div></div></blockquote><div=
>That would be an ordering of textual representation, not a logical orderin=
g of the UUID. It would be like ordering two JPEGs by their base64-encoded =
representations. Utterly pointless.</div></div></div></blockquote><div><br>=
It provides a portable total ordering of UUIDs.=C2=A0 That&#39;s point enou=
gh.<br>It makes just as much sense as lexicographic ordering of strings.<br=
><br>Besides which, here is a quote from RFC 4122, which defines UUIDs:<br>=
&lt;<a href=3D"https://tools.ietf.org/html/rfc4122" target=3D"_blank">https=
://tools.ietf.org/html/<wbr>rfc4122</a>&gt;<br>

<pre class=3D"m_1612412806352029924m_-8415730193911092488gmail-newpage" sty=
le=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:pag=
e;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:init=
ial">      UUIDs, as defined in this document, can also be ordered
      lexicographically.  For a pair of UUIDs, the first one follows the
      second if the most significant field in which the UUIDs differ is
      greater for the first UUID.  The second precedes the first if the
      most significant field in which the UUIDs differ is greater for
      the second UUID.</pre>

<br>When the defining document for UUIDs defines their order, it is hardly =
&quot;pointless&quot;<br>to ask that this ordering be implemented.</div></d=
iv></div></blockquote><div><br></div></span><div>I think you make an excell=
ent point. I bow to the authority of the RFC and agree that lexical orderin=
g would be the logic default ordering choice in order to match the wording =
of the document.</div><div><br></div><div>I still think that the ordering i=
s pointless, but a specification is a specification and a user of an UUID o=
bject will expect it to implement the specification fully.</div><div><br></=
div><div>I reverse my earlier arguments as to whether there should be an op=
erator &lt;.</div><div><br></div><div>With the caveat that anyone caught us=
ing it in one of my projects would need to be prepared to explain themselve=
s!</div><div><br></div></div></div></blockquote><div><br></div><div><br></d=
iv><div>You could say that for quite a few of C++&#39;s features!=C2=A0</di=
v></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFQaeCD5Y-m8gsq7C5qihdaLKv4g7um57Ewe=
CJaTHdZMFj01Gw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCD5Y-m8gsq7=
C5qihdaLKv4g7um57EweCJaTHdZMFj01Gw%40mail.gmail.com</a>.<br />

--000000000000809f870571ce59fc--

.

--0000000000008325480571f69b71
Content-Type: text/plain; charset="UTF-8"

The actual full quote from RFC 4122 is as follows:

*Consider each field of the UUID to be an unsigned integer as shown*
*in the table in section Section 4.1.2.  Then, to compare a pair of*
*UUIDs, arithmetically compare the corresponding fields from each*
*UUID in order of significance and according to their data type.*
*Two UUIDs are equal if and only if all the corresponding fields*
*are equal.*

*As an implementation note, equality comparison can be performed on*
*many systems by doing the appropriate byte-order canonicalization,*
*and then treating the two UUIDs as 128-bit unsigned integers.*

*UUIDs, as defined in this document, can also be ordered*
*lexicographically.  For a pair of UUIDs, the first one follows the*
*second if the most significant field in which the UUIDs differ is*
*greater for the first UUID.  The second precedes the first if the*
*most significant field in which the UUIDs differ is greater for*
*the second UUID.*

Although the first part seems to refer to equality comparison I see no
reason why it couldn't apply to ordering. The "can also be" from the last
paragraph seem to indicate that the above paragraphs do indeed refer to
ordering too.




On Wed, Jul 25, 2018 at 1:48 AM Richard Hodges <hodges.r@gmail.com> wrote:

>
>
> On Tue, 24 Jul 2018 at 21:13, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>
>> On Tue, Jul 24, 2018 at 1:45 PM Richard Hodges <hodges.r@gmail.com>
>> wrote:
>>
>>> On Tue, 24 Jul 2018 at 18:39, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>>>
>>>> That suggests lexicographic ordering by group integer value.
>>>>
>>> That would be an ordering of textual representation, not a logical
>>> ordering of the UUID. It would be like ordering two JPEGs by their
>>> base64-encoded representations. Utterly pointless.
>>>
>>
>> It provides a portable total ordering of UUIDs.  That's point enough.
>> It makes just as much sense as lexicographic ordering of strings.
>>
>> Besides which, here is a quote from RFC 4122, which defines UUIDs:
>> <https://tools.ietf.org/html/rfc4122>
>>
>>       UUIDs, as defined in this document, can also be ordered
>>       lexicographically.  For a pair of UUIDs, the first one follows the
>>       second if the most significant field in which the UUIDs differ is
>>       greater for the first UUID.  The second precedes the first if the
>>       most significant field in which the UUIDs differ is greater for
>>       the second UUID.
>>
>>
>> When the defining document for UUIDs defines their order, it is hardly
>> "pointless"
>> to ask that this ordering be implemented.
>>
>
> I think you make an excellent point. I bow to the authority of the RFC and
> agree that lexical ordering would be the logic default ordering choice in
> order to match the wording of the document.
>
> I still think that the ordering is pointless, but a specification is a
> specification and a user of an UUID object will expect it to implement the
> specification fully.
>
> I reverse my earlier arguments as to whether there should be an operator <.
>
> With the caveat that anyone caught using it in one of my projects would
> need to be prepared to explain themselves!
>
>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYqiTY3MExXxijg%3DcG5PwTuFqrFLAnYqCar5B%3D6uaXu9Q%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYqiTY3MExXxijg%3DcG5PwTuFqrFLAnYqCar5B%3D6uaXu9Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3ha9AX8vDfco2dmyAsbj66Av7%2BiK%2BvB%2BGsnday%2BtV_QVdg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3ha9AX8vDfco2dmyAsbj66Av7%2BiK%2BvB%2BGsnday%2BtV_QVdg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxvN0vNwT%2B5-QODXVaDUMd14NhqJJBP-OUEc_FHYkKjBQ%40mail.gmail.com.

--0000000000008325480571f69b71
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The actual full quote from RFC 4122 is as follows:<div><br=
></div><div><div><i>Consider each field of the UUID to be an unsigned integ=
er as shown</i></div><div><i>in the table in section Section 4.1.2.=C2=A0 T=
hen, to compare a pair of</i></div><div><i>UUIDs, arithmetically compare th=
e corresponding fields from each</i></div><div><i>UUID in order of signific=
ance and according to their data type.</i></div><div><i>Two UUIDs are equal=
 if and only if all the corresponding fields</i></div><div><i>are equal.</i=
></div><div><i><br></i></div><div><i>As an implementation note, equality co=
mparison can be performed on</i></div><div><i>many systems by doing the app=
ropriate byte-order canonicalization,</i></div><div><i>and then treating th=
e two UUIDs as 128-bit unsigned integers.</i></div><div><i><br></i></div><d=
iv><i>UUIDs, as defined in this document, can also be ordered</i></div><div=
><i>lexicographically.=C2=A0 For a pair of UUIDs, the first one follows the=
</i></div><div><i>second if the most significant field in which the UUIDs d=
iffer is</i></div><div><i>greater for the first UUID.=C2=A0 The second prec=
edes the first if the</i></div><div><i>most significant field in which the =
UUIDs differ is greater for</i></div><div><i>the second UUID.</i></div></di=
v><div><br></div><div>Although the first part seems to refer to equality co=
mparison I see no reason why it couldn&#39;t apply to ordering. The &quot;c=
an also be&quot; from the last paragraph seem to indicate that the above pa=
ragraphs do indeed refer to ordering too.</div><div><br></div><div><br></di=
v><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On W=
ed, Jul 25, 2018 at 1:48 AM Richard Hodges &lt;<a href=3D"mailto:hodges.r@g=
mail.com">hodges.r@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"lt=
r">On Tue, 24 Jul 2018 at 21:13, Hyman Rosen &lt;<a href=3D"mailto:hyman.ro=
sen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quo=
te"><div dir=3D"ltr">On Tue, Jul 24, 2018 at 1:45 PM Richard Hodges &lt;<a =
href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>=
&gt; wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, 24 Jul 2018 at=
 18:39, Hyman Rosen &lt;<a href=3D"mailto:hyman.rosen@gmail.com" target=3D"=
_blank">hyman.rosen@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>T=
hat suggests lexicographic ordering by group integer value.</div></div></di=
v></blockquote><div>That would be an ordering of textual representation, no=
t a logical ordering of the UUID. It would be like ordering two JPEGs by th=
eir base64-encoded representations. Utterly pointless.</div></div></div></b=
lockquote><div><br>It provides a portable total ordering of UUIDs.=C2=A0 Th=
at&#39;s point enough.<br>It makes just as much sense as lexicographic orde=
ring of strings.<br><br>Besides which, here is a quote from RFC 4122, which=
 defines UUIDs:<br>&lt;<a href=3D"https://tools.ietf.org/html/rfc4122" targ=
et=3D"_blank">https://tools.ietf.org/html/rfc4122</a>&gt;<br>

<pre class=3D"m_3815793270438766831m_-8415730193911092488gmail-newpage" sty=
le=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:pag=
e;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:init=
ial">      UUIDs, as defined in this document, can also be ordered
      lexicographically.  For a pair of UUIDs, the first one follows the
      second if the most significant field in which the UUIDs differ is
      greater for the first UUID.  The second precedes the first if the
      most significant field in which the UUIDs differ is greater for
      the second UUID.</pre>

<br>When the defining document for UUIDs defines their order, it is hardly =
&quot;pointless&quot;<br>to ask that this ordering be implemented.</div></d=
iv></div></blockquote><div><br></div><div>I think you make an excellent poi=
nt. I bow to the authority of the RFC and agree that lexical ordering would=
 be the logic default ordering choice in order to match the wording of the =
document.</div><div><br></div><div>I still think that the ordering is point=
less, but a specification is a specification and a user of an UUID object w=
ill expect it to implement the specification fully.</div><div><br></div><di=
v>I reverse my earlier arguments as to whether there should be an operator =
&lt;.</div><div><br></div><div>With the caveat that anyone caught using it =
in one of my projects would need to be prepared to explain themselves!</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">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYqiTY3MExXxijg%3DcG5PwTuFqrFLA=
nYqCar5B%3D6uaXu9Q%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAHSYqdYqiTY3MExXxijg%3DcG5PwTuFqrFLAnYqCar5B%3D6uaXu9Q%40mail.gma=
il.com</a>.<br>
</blockquote></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3ha9AX8vDfco2dmyAsbj66Av7%2BiK%2=
BvB%2BGsnday%2BtV_QVdg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid=
/std-proposals/CALvx3ha9AX8vDfco2dmyAsbj66Av7%2BiK%2BvB%2BGsnday%2BtV_QVdg%=
40mail.gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxvN0vNwT%2B5-QODXVaDUMd14Nhq=
JJBP-OUEc_FHYkKjBQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BgtASxvN0=
vNwT%2B5-QODXVaDUMd14NhqJJBP-OUEc_FHYkKjBQ%40mail.gmail.com</a>.<br />

--0000000000008325480571f69b71--

.