lately when working on std.string I run into problems making stuff nogc as std.utf.decode is not nogc.

https://issues.dlang.org/show_bug.cgi?id=13458

Also I would like a version of decode that takes the string not as ref.

Something like:

bool decode2(S,C)(S str, out C ret, out size_t strSliceIdx)
    if(isSomeString!S && isSomeChar!C) {}

where true is returned if the decode worked and false otherwise.

Ideas, Suggestions ... ? any takers?

On 10/1/2014 3:10 AM, Robert burner Schadek wrote:
> Ideas, Suggestions ... ? any takers?

You can use .byDchar instead, which is nothrow @nogc.

On Wednesday, 1 October 2014 at 10:51:25 UTC, Walter Bright wrote:
> On 10/1/2014 3:10 AM, Robert burner Schadek wrote:
>> Ideas, Suggestions ... ? any takers?
>
> You can use .byDchar instead, which is nothrow @nogc.

thanks, I will try that.

On Wednesday, 1 October 2014 at 10:51:25 UTC, Walter Bright wrote:
> On 10/1/2014 3:10 AM, Robert burner Schadek wrote:
>> Ideas, Suggestions ... ? any takers?
>
> You can use .byDchar instead, which is nothrow @nogc.

Being forced out of using exception just to be able to have the magic "@nogc" tag is the real issue here...

The original request was mostly for @nogc, not necessarilly for nothrow.

On Wednesday, 1 October 2014 at 10:10:51 UTC, Robert burner Schadek wrote:
> lately when working on std.string I run into problems making stuff nogc as std.utf.decode is not nogc.
>
> https://issues.dlang.org/show_bug.cgi?id=13458
>
> Also I would like a version of decode that takes the string not as ref.
>
> Something like:
>
> bool decode2(S,C)(S str, out C ret, out size_t strSliceIdx)
>     if(isSomeString!S && isSomeChar!C) {}
>
> where true is returned if the decode worked and false otherwise.
>
> Ideas, Suggestions ... ? any takers?

Kind of like the "non-throwing std.conv.to": I'm pretty sure that if you wrote your "tryDecode" function, then you could back-wards implement the old decode in terms of the new "tryDecode":

dchar decode(ref str)
{
    dchar ret;
    size_t idx;
    enforce(tryDecode(str, ret, idx));
    str = str[idx .. $];
    return ret;
}

The implementation of tryDecode would be pretty much the old one's implementation, exceptions replaced in favor of return false.

01-Oct-2014 14:10, Robert burner Schadek пишет:
> lately when working on std.string I run into problems making stuff nogc
> as std.utf.decode is not nogc.
>
> https://issues.dlang.org/show_bug.cgi?id=13458

Trivial to do. But before that somebody got to make  one of:

a) A policy on reuse of exceptions. Literally we have easy TLS why not put 1 copy of each possible exception there? (**ck the chaining, who need it anyway?)
b) Make all exceptions ref-counted.

The benefit of A is that "creating" exceptions becomes MUCH faster.

-- 
Dmitry Olshansky

On 10/3/14, 11:35 AM, Dmitry Olshansky wrote:
> 01-Oct-2014 14:10, Robert burner Schadek пишет:
>> lately when working on std.string I run into problems making stuff nogc
>> as std.utf.decode is not nogc.
>>
>> https://issues.dlang.org/show_bug.cgi?id=13458
>
> Trivial to do. But before that somebody got to make  one of:
>
> a) A policy on reuse of exceptions. Literally we have easy TLS why not
> put 1 copy of each possible exception there? (**ck the chaining, who
> need it anyway?)
> b) Make all exceptions ref-counted.
>
> The benefit of A is that "creating" exceptions becomes MUCH faster.

This seems to be going in circles. Didn't we just agree we solve this by making exceptions reference counted? Please advise. -- Andrei

03-Oct-2014 23:51, Andrei Alexandrescu пишет:
> On 10/3/14, 11:35 AM, Dmitry Olshansky wrote:
>> 01-Oct-2014 14:10, Robert burner Schadek пишет:
>>> lately when working on std.string I run into problems making stuff nogc
>>> as std.utf.decode is not nogc.
>>>
>>> https://issues.dlang.org/show_bug.cgi?id=13458
>>
>> Trivial to do. But before that somebody got to make  one of:
>>
>> a) A policy on reuse of exceptions. Literally we have easy TLS why not
>> put 1 copy of each possible exception there? (**ck the chaining, who
>> need it anyway?)
>> b) Make all exceptions ref-counted.
>>
>> The benefit of A is that "creating" exceptions becomes MUCH faster.
>
> This seems to be going in circles. Didn't we just agree we solve this by
> making exceptions reference counted? Please advise. -- Andrei
>

Lately I get to read NG once/twice a week.

I haven't seen or have missed big red
WE ARE MAKING EXCEPTIONS ref-counted "real soon"(TM)

Good to know anyway.

-- 
Dmitry Olshansky

On Friday, 3 October 2014 at 19:51:40 UTC, Andrei Alexandrescu wrote:
> On 10/3/14, 11:35 AM, Dmitry Olshansky wrote:
>> 01-Oct-2014 14:10, Robert burner Schadek пишет:
>>> lately when working on std.string I run into problems making stuff nogc
>>> as std.utf.decode is not nogc.
>>>
>>> https://issues.dlang.org/show_bug.cgi?id=13458
>>
>> Trivial to do. But before that somebody got to make  one of:
>>
>> a) A policy on reuse of exceptions. Literally we have easy TLS why not
>> put 1 copy of each possible exception there? (**ck the chaining, who
>> need it anyway?)
>> b) Make all exceptions ref-counted.
>>
>> The benefit of A is that "creating" exceptions becomes MUCH faster.
>
> This seems to be going in circles. Didn't we just agree we solve this by making exceptions reference counted? Please advise. -- Andrei

Depends on who "we" is. There was a large discussion with several alternative suggestions and no clear conclusion.

On 10/4/14, 4:24 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
> On Friday, 3 October 2014 at 19:51:40 UTC, Andrei Alexandrescu wrote:
>> On 10/3/14, 11:35 AM, Dmitry Olshansky wrote:
>>> 01-Oct-2014 14:10, Robert burner Schadek пишет:
>>>> lately when working on std.string I run into problems making stuff nogc
>>>> as std.utf.decode is not nogc.
>>>>
>>>> https://issues.dlang.org/show_bug.cgi?id=13458
>>>
>>> Trivial to do. But before that somebody got to make  one of:
>>>
>>> a) A policy on reuse of exceptions. Literally we have easy TLS why not
>>> put 1 copy of each possible exception there? (**ck the chaining, who
>>> need it anyway?)
>>> b) Make all exceptions ref-counted.
>>>
>>> The benefit of A is that "creating" exceptions becomes MUCH faster.
>>
>> This seems to be going in circles. Didn't we just agree we solve this
>> by making exceptions reference counted? Please advise. -- Andrei
>
> Depends on who "we" is. There was a large discussion with several
> alternative suggestions and no clear conclusion.

I proposed in this forum that we use reference counting and there was general agreement that that would help, no killer counterargument, and no other better solution. Conclusion was pretty clear to me: we move to reference counted exceptions. -- Andrei