www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Vote for std.uuid

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
As been mentioned previously, std.uuid is quite small so we've settled 
for shorter review period. That period ended as of some hours ago.

It's time to start voting on its inclusion into Phobos. The voting ends 
at 25-26 June.

---
Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html
---

The rules are as usual: only one one vote.
Leaving a one-line short "reason" note is encouraged.

Let's reuse the old review thread for further discussions if any,
as thread pooling is more efficient :)

-- 
Dmitry Olshansky
Jun 19 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 19-06-2012 13:24, Dmitry Olshansky wrote:

 As been mentioned previously, std.uuid is quite small so we've settled
 for shorter review period. That period ended as of some hours ago.

 It's time to start voting on its inclusion into Phobos. The voting ends
 at 25-26 June.

 ---
 Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
 API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html
 ---

 The rules are as usual: only one one vote.
 Leaving a one-line short "reason" note is encouraged.

 Let's reuse the old review thread for further discussions if any,
 as thread pooling is more efficient :)


+1 from me. Module looks very well-designed.

Nitpicks about the docs (if this is not too late):

* Wrap stuff like UUID.init in $(D ...).
* "... small size, of 128-bits, or 16-bytes" -> "... small size, of 128 
bits, or 16 bytes".
* Be consistent about spelling in some cases: RFC 4112 vs rfc4112, uuid 
vs UUID, md5 vs MD5, etc.
* "reserved for future use" -> "Reserved for future use".
* "Parse an UUID from it's canonical string form" -> "Parse an UUID from 
its canonical string form".
* "An UUID in it's canonical form looks like this" -> "An UUID in its 
canonical form looks like this".
* s/hex-numbers/hex numbers/.
* s/UTF8/UTF-8/.
* s/boost/Boost/ in cases where you refer to the Boost project.
* s/phobos/Phobos/ in cases where you refer to the Phobos project.

But as said, these are just nitpicks. The module itself looks great!

BTW, good call on explicitly documenting CTFE support. We should do this 
more.

-- 
Alex Rřnne Petersen
alex lycus.org
http://lycus.org
Jun 19 2012
prev sibling next sibling parent reply "John Chapman" <johnch_atms hotmail.com> writes:
On Tuesday, 19 June 2012 at 11:24:50 UTC, Dmitry Olshansky wrote:

 As been mentioned previously, std.uuid is quite small so we've 
 settled for shorter review period. That period ended as of some 
 hours ago.

 It's time to start voting on its inclusion into Phobos. The 
 voting ends at 25-26 June.

 ---
 Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
 API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html
 ---


Yes.

Just a note on the documentation: replace "an UUID" with "a UUID".
Jun 19 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 19-06-2012 14:05, John Chapman wrote:

 On Tuesday, 19 June 2012 at 11:24:50 UTC, Dmitry Olshansky wrote:

 As been mentioned previously, std.uuid is quite small so we've settled
 for shorter review period. That period ended as of some hours ago.

 It's time to start voting on its inclusion into Phobos. The voting
 ends at 25-26 June.

 ---
 Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
 API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html
 ---


 Yes.

 Just a note on the documentation: replace "an UUID" with "a UUID".


And relatedly "a MD5" -> "an MD5".

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Jun 19 2012
parent Johannes Pfau <nospam example.com> writes:
Am Tue, 19 Jun 2012 14:19:53 +0200
schrieb Alex R=C3=B8nne Petersen <alex lycus.org>:


 On 19-06-2012 14:05, John Chapman wrote:

 On Tuesday, 19 June 2012 at 11:24:50 UTC, Dmitry Olshansky wrote:

 As been mentioned previously, std.uuid is quite small so we've
 settled for shorter review period. That period ended as of some
 hours ago.

 It's time to start voting on its inclusion into Phobos. The voting
 ends at 25-26 June.

 ---
 Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
 API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html
 ---


 Yes.

 Just a note on the documentation: replace "an UUID" with "a UUID".


=20
 And relatedly "a MD5" -> "an MD5".
=20


Thanks for your corrections, I read your replies and corrected those
errors. It's usually not allowed to update the code/docs in the voting
phase, but I hope it's OK in this case as these are mostly spelling
errors.
Jun 19 2012
prev sibling next sibling parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
On Tuesday, 19 June 2012 at 11:24:50 UTC, Dmitry Olshansky wrote:

 As been mentioned previously, std.uuid is quite small so we've 
 settled for shorter review period. That period ended as of some 
 hours ago.

 It's time to start voting on its inclusion into Phobos. The 
 voting ends at 25-26 June.

 ---
 Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
 API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html
 ---

 The rules are as usual: only one one vote.
 Leaving a one-line short "reason" note is encouraged.

 Let's reuse the old review thread for further discussions if 
 any,
 as thread pooling is more efficient :)


Yes! (mostly off topic) While my uuid module has been usable, 
I've never thought it reliable.
Jun 20 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, June 19, 2012 15:24:48 Dmitry Olshansky wrote:

 As been mentioned previously, std.uuid is quite small so we've settled
 for shorter review period. That period ended as of some hours ago.
 
 It's time to start voting on its inclusion into Phobos. The voting ends
 at 25-26 June.
 
 ---
 Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
 API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html
 ---
 
 The rules are as usual: only one one vote.
 Leaving a one-line short "reason" note is encouraged.
 
 Let's reuse the old review thread for further discussions if any,
 as thread pooling is more efficient :)


Yes.

- Jonathan M Davis
Jun 20 2012
prev sibling next sibling parent "Jonas Drewsen" <jdrewsen nospam.com> writes:
On Tuesday, 19 June 2012 at 11:24:50 UTC, Dmitry Olshansky wrote:

 As been mentioned previously, std.uuid is quite small so we've 
 settled for shorter review period. That period ended as of some 
 hours ago.

 It's time to start voting on its inclusion into Phobos. The 
 voting ends at 25-26 June.

 ---
 Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
 API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html
 ---

 The rules are as usual: only one one vote.
 Leaving a one-line short "reason" note is encouraged.

 Let's reuse the old review thread for further discussions if 
 any,
 as thread pooling is more efficient :)


Yes

Jonas Drewsen
Jun 21 2012
prev sibling next sibling parent Mike Wey <mike-wey example.com> writes:
Yes.

-- 
Mike Wey
Jun 21 2012
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 19-Jun-12 15:24, Dmitry Olshansky wrote:

 As been mentioned previously, std.uuid is quite small so we've settled
 for shorter review period. That period ended as of some hours ago.

 It's time to start voting on its inclusion into Phobos. The voting ends
 at 25-26 June.

 ---
 Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
 API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html
 ---

 The rules are as usual: only one one vote.
 Leaving a one-line short "reason" note is encouraged.

 Let's reuse the old review thread for further discussions if any,
 as thread pooling is more efficient :)


And it gets YES from me as well.
-- 
Dmitry Olshansky
Jun 21 2012
prev sibling next sibling parent "Masahiro Nakagawa" <repeatedly gmail.com> writes:
On Tuesday, 19 June 2012 at 11:24:50 UTC, Dmitry Olshansky wrote:

 As been mentioned previously, std.uuid is quite small so we've 
 settled for shorter review period. That period ended as of some 
 hours ago.

 It's time to start voting on its inclusion into Phobos. The 
 voting ends at 25-26 June.

 ---
 Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
 API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html
 ---

 The rules are as usual: only one one vote.
 Leaving a one-line short "reason" note is encouraged.

 Let's reuse the old review thread for further discussions if 
 any,
 as thread pooling is more efficient :)


Yes!
Good work :)
Jun 24 2012
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 19 June 2012 at 11:24:50 UTC, Dmitry Olshansky wrote:

 It's time to start voting on its inclusion into Phobos. The 
 voting ends at 25-26 June.


There is a serious  safe-ty issue with the current 
implementation: randomUUID/parseUUID are marked  trusted, but 
take an arbitrary range as template parameter, the methods of 
which might be  system.

I'm aware that this mistake is astonishingly easy to make, and 
that code like that can be extremely tiresome to get right – 
there is no way to mark only a part of a template function 
 trusted, so you can rely on inference for handling cases where 
safety depends on the template arguments. I should really try to 
find the time to finish my  trusted rant post soon…

However, under the assumption that the aforementioned issues will 
be fixed, I vote for Yes. The library is nothing spectacular, and 
I haven't had a chance to use it myself yet, but it seems like a 
solid, well-documented implementation.

David
Jun 24 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 24, 2012 15:30:15 David Nadlinger wrote:

 There is a serious  safe-ty issue with the current
 implementation: randomUUID/parseUUID are marked  trusted, but
 take an arbitrary range as template parameter, the methods of
 which might be  system.


Nice catch. I failed to notice that and should have.  trusted on templa=
ted=20
functions is generally wrong.


 I'm aware that this mistake is astonishingly easy to make, and
 that code like that can be extremely tiresome to get right =E2=80=93
 there is no way to mark only a part of a template function
  trusted, so you can rely on inference for handling cases where
 safety depends on the template arguments. I should really try to
 find the time to finish my  trusted rant post soon=E2=80=A6


It can be done with helper functions and code duplication. I did it for=
 save=20
in the recently added std.range.RefRange. But it's definitely true that=
 it=20
would be nice to be able to somehow mark certain function calls or stat=
ements=20
within a templated function as being  trusted without marking the whole=
 thing=20
as  trusted.

- Jonathan M Davis
Jun 24 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 24-06-2012 15:40, Jonathan M Davis wrote:

 On Sunday, June 24, 2012 15:30:15 David Nadlinger wrote:

 There is a serious  safe-ty issue with the current
 implementation: randomUUID/parseUUID are marked  trusted, but
 take an arbitrary range as template parameter, the methods of
 which might be  system.


 Nice catch. I failed to notice that and should have.  trusted on templated
 functions is generally wrong.


 I'm aware that this mistake is astonishingly easy to make, and
 that code like that can be extremely tiresome to get right –
 there is no way to mark only a part of a template function
  trusted, so you can rely on inference for handling cases where
 safety depends on the template arguments. I should really try to
 find the time to finish my  trusted rant post soon…


 It can be done with helper functions and code duplication. I did it for save
 in the recently added std.range.RefRange. But it's definitely true that it
 would be nice to be able to somehow mark certain function calls or statements
 within a templated function as being  trusted without marking the whole thing
 as  trusted.

 - Jonathan M Davis


Call me weird, but that seems like it would completely undermine the 
 safe'ty system, no? Maybe I'm misunderstanding? It just seems like that 
kind of escape hatch would result in  safe meaning basically nothing...

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Jun 24 2012
parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 24 June 2012 at 14:17:14 UTC, Alex Rønne Petersen 
wrote:

 Call me weird, but that seems like it would completely 
 undermine the  safe'ty system, no? Maybe I'm misunderstanding? 
 It just seems like that kind of escape hatch would result in 
  safe meaning basically nothing...


 safe just means that somebody promised you that the piece of 
code in question is memory safe – either the compiler by 
disallowing pointer arithmetic, ..., or the implementor using 
 trusted. We really shouldn't continue the discussion in this 
thread, though.

David
Jun 24 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/24/12 9:40 AM, Jonathan M Davis wrote:

 On Sunday, June 24, 2012 15:30:15 David Nadlinger wrote:

 There is a serious  safe-ty issue with the current
 implementation: randomUUID/parseUUID are marked  trusted, but
 take an arbitrary range as template parameter, the methods of
 which might be  system.


 Nice catch. I failed to notice that and should have.  trusted on templated
 functions is generally wrong.


Yah, inferred qualifiers need generally not be specified with templates 
unless explicitly meant to restrict code.

Andrei
Jun 27 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/27/2012 02:53 PM, Andrei Alexandrescu wrote:

 On 6/24/12 9:40 AM, Jonathan M Davis wrote:

 On Sunday, June 24, 2012 15:30:15 David Nadlinger wrote:

 There is a serious  safe-ty issue with the current
 implementation: randomUUID/parseUUID are marked  trusted, but
 take an arbitrary range as template parameter, the methods of
 which might be  system.


 Nice catch. I failed to notice that and should have.  trusted on
 templated
 functions is generally wrong.


 Yah, inferred qualifiers need generally not be specified with templates
 unless explicitly meant to restrict code.

 Andrei


The issue is this one:

auto fun(alias a)(){ // inferred  system for  safe a
     ... // trusted code
     a();
     ... // trusted code
}

IIRC std.conv.emplace suffers from the same problem.
Jun 27 2012
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Sun, 24 Jun 2012 15:30:15 +0200
schrieb "David Nadlinger" <see klickverbot.at>:


 On Tuesday, 19 June 2012 at 11:24:50 UTC, Dmitry Olshansky wrote:

 It's time to start voting on its inclusion into Phobos. The=20
 voting ends at 25-26 June.


=20
 There is a serious  safe-ty issue with the current=20
 implementation: randomUUID/parseUUID are marked  trusted, but=20
 take an arbitrary range as template parameter, the methods of=20
 which might be  system.
=20
 I'm aware that this mistake is astonishingly easy to make, and=20
 that code like that can be extremely tiresome to get right =E2=80=93=20
 there is no way to mark only a part of a template function=20
  trusted, so you can rely on inference for handling cases where=20
 safety depends on the template arguments. I should really try to=20
 find the time to finish my  trusted rant post soon=E2=80=A6
=20


Good catch, I should have seen that. I'll fix it ASAP.

Seems I have to be more careful with  trusted in the future.
Jun 24 2012
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 19-Jun-12 15:24, Dmitry Olshansky wrote:

 As been mentioned previously, std.uuid is quite small so we've settled
 for shorter review period. That period ended as of some hours ago.

 It's time to start voting on its inclusion into Phobos. The voting ends
 at 25-26 June.


Only few hours left.
Just to notify that if somebody thought to cast a vote sometime later 
that it'd better be now or never.

-- 
Dmitry Olshansky
Jun 24 2012
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 25-Jun-12 00:04, Dmitry Olshansky wrote:

 On 19-Jun-12 15:24, Dmitry Olshansky wrote:

 As been mentioned previously, std.uuid is quite small so we've settled
 for shorter review period. That period ended as of some hours ago.

 It's time to start voting on its inclusion into Phobos. The voting ends
 at 25-26 June.


 Only few hours left.
 Just to notify that if somebody thought to cast a vote sometime later
 that it'd better be now or never.


Oops, nevermind I somehow skipped one day. So it's about 28 hours...
In any case it's soon comes to an end :)

-- 
Dmitry Olshansky
Jun 24 2012
prev sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
Got to go with yes on this one. Well documented, seems sanely 
designed, and UUIDs are common enough that having a module for 
them in Phobos makes sense.
Jun 24 2012