std.utf.decode @nogc please

[Robert burner Schadek via Digitalmars-d]

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?

[Walter Bright via Digitalmars-d]

Post by Robert burner Schadek via Digitalmars-d
Ideas, Suggestions ... ? any takers?

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

[Robert burner Schadek via Digitalmars-d]

Post by Robert burner Schadek via Digitalmars-d
Ideas, Suggestions ... ? any takers?

thanks, I will try that.

[monarch_dodra via Digitalmars-d]

Post by Robert burner Schadek via Digitalmars-d
Ideas, Suggestions ... ? any takers?

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.

[monarch_dodra via Digitalmars-d]

On Wednesday, 1 October 2014 at 10:10:51 UTC, Robert burner

Post by Robert burner Schadek via Digitalmars-d
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.
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.

[Dmitry Olshansky via Digitalmars-d]

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.

[Andrei Alexandrescu via Digitalmars-d]

Post by Dmitry Olshansky via Digitalmars-d

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

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

[Dmitry Olshansky via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d

Post by Dmitry Olshansky via Digitalmars-d

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

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.

[via Digitalmars-d]

On Friday, 3 October 2014 at 19:51:40 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d

Post by Dmitry Olshansky via Digitalmars-d

Post by Robert burner Schadek via Digitalmars-d
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

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.

[Andrei Alexandrescu via Digitalmars-d]

Post by via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

Post by Dmitry Olshansky via Digitalmars-d

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

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

[via Digitalmars-d]

On Saturday, 4 October 2014 at 22:02:14 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d

Post by via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d

Post by Dmitry Olshansky via Digitalmars-d

Post by Robert burner Schadek via Digitalmars-d
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

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.

[Andrei Alexandrescu via Digitalmars-d]

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