June 24, 2012 Re: Vote for std.uuid | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | 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 :)
|
June 24, 2012 Re: Vote for std.uuid | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | 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
|
June 24, 2012 Re: Vote for std.uuid | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 |
June 24, 2012 Re: Vote for std.uuid | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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 |
June 24, 2012 Re: Vote for std.uuid | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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
|
June 24, 2012 Re: Vote for std.uuid | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 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…
>
Good catch, I should have seen that. I'll fix it ASAP.
Seems I have to be more careful with @trusted in the future.
|
June 24, 2012 Re: Vote for std.uuid | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | 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 |
June 24, 2012 Re: Vote for std.uuid | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | 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 |
June 25, 2012 Re: Vote for std.uuid | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | 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. |
June 27, 2012 Re: Vote for std.uuid | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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
|
Copyright © 1999-2021 by the D Language Foundation