www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.utf.decode nogc please

reply "Robert burner Schadek" <rburners gmail.com> writes:
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?
Oct 01 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/1/2014 3:10 AM, Robert burner Schadek wrote:

 Ideas, Suggestions ... ? any takers?


You can use .byDchar instead, which is nothrow  nogc.
Oct 01 2014
next sibling parent "Robert burner Schadek" <rburners gmail.com> writes:
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.
Oct 01 2014
prev sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
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.
Oct 01 2014
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
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.
Oct 01 2014
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Oct 03 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Oct 03 2014
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Oct 03 2014
prev sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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.
Oct 04 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Oct 04 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Saturday, 4 October 2014 at 22:02:14 UTC, Andrei Alexandrescu 
wrote:

 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


There was indeed agreement on reference counting (although 
someone suggested disallowing cycles or removing chaining 
altogether). But what I meant is that there was no agreement on a 
specific solution, and several ones were proposed, from full 
general compiler supported refcounting to library implementation.
Oct 05 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/5/14, 1:58 AM, "Marc Schütz" <schuetzm gmx.net>" wrote:

 There was indeed agreement on reference counting (although someone
 suggested disallowing cycles or removing chaining altogether). But what
 I meant is that there was no agreement on a specific solution, and
 several ones were proposed, from full general compiler supported
 refcounting to library implementation.


Understood, thanks. I think there's no other way around than language 
support. Here's a sketch of the solution:

* Introduce interface AutoRefCounted. For practical reasons it may 
inherit IUnknown, though that's not material to the concept.

* AutoRefCounted and any interface or class inheriting it have the 
compiler insert calls to methods that increment and decrement the 
reference count (e.g. AddRef/Release).

* All descendants of AutoRefCounted must be descendants of it through 
all paths (i.e. there can be no common descendants of AutoRefCounted and 
either IUnknown or Object).

* After all this infra is in place, unhook Throwable from its current 
place and have it inherit AutoRefCounted.

* All is good and there's much rejoicing.


Andrei
Oct 05 2014