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 =?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
prev sibling next sibling 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".

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 =?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
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 next sibling parent 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
prev sibling next sibling 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 next 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.

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