Jump to page: 1 2
Thread overview
[Issue 13972] Make scoped, Unique, and RefCounted @nogc
Jan 12, 2015
Walter Bright
Jan 13, 2015
Kapps
Feb 11, 2015
Ulrich Küttler
Feb 12, 2015
weaselcat
Feb 17, 2015
Nick Treleaven
Mar 31, 2015
weaselcat
Apr 10, 2015
weaselcat
Apr 21, 2015
weaselcat
Jan 04, 2016
weaselcat
Dec 15, 2022
Nick Treleaven
Dec 16, 2022
RazvanN
January 12, 2015
https://issues.dlang.org/show_bug.cgi?id=13972

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com
           Hardware|x86                         |All
                 OS|Mac OS X                    |All

--
January 13, 2015
https://issues.dlang.org/show_bug.cgi?id=13972

Kapps <opantm2+dbugs@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |opantm2+dbugs@gmail.com

--- Comment #1 from Kapps <opantm2+dbugs@gmail.com> ---
I've looked at making some obvious things @nogc (RefCounted, std.container.array, etc), but have always been blocked by the use of exceptions. There was some talk about how to handle @nogc exceptions, but no real conclusion came of it. Virtually all of these structs that are supposed to completely avoid the GC do not actually do so because they allocate exceptions with the GC (whether by enforce or manually throwing). This is also one of the main reasons I never use @nogc in my own code, even though I avoid using the GC. In some cases there's an obvious solution, such as replacing `enforce(foo)` with:

````
if(foo is null) {
    static ex = cast(immutable)(new Exception("foo is null"));
    throw ex;
}
````

But that's considerably uglier and does not help in situations where the exception text includes additional information from runtime arguments. Also I'm not sure what kind of impact this would have if called and thrown in a catch block.

It would be nice to confirm what approach for avoiding GC exceptions should be used in Phobos, as AFAIK nothing was ever decided, and I'm not sure of an approach without drawbacks towards those who do use the GC.

--
February 11, 2015
https://issues.dlang.org/show_bug.cgi?id=13972

Ulrich Küttler <kuettler@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kuettler@gmail.com

--
February 11, 2015
https://issues.dlang.org/show_bug.cgi?id=13972

bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc

--- Comment #2 from bearophile_hugs@eml.cc ---
(In reply to Kapps from comment #1)

> if(foo is null) {
>     static ex = cast(immutable)(new Exception("foo is null"));
>     throw ex;

I think no cast is needed:

static immutable ex = new Exception("foo is null");


> and does not help in situations where the
> exception text includes additional information from runtime arguments.

The space for the extra information could be allocated statically, and pasted inside the buffer. But this makes the function not pure.


> Also
> I'm not sure what kind of impact this would have if called and thrown in a
> catch block.

In presence of exception chaining how are immutable exceptions working?

--
February 12, 2015
https://issues.dlang.org/show_bug.cgi?id=13972

weaselcat <r9shackleford@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r9shackleford@gmail.com

--- Comment #3 from weaselcat <r9shackleford@gmail.com> ---
Hi,
Is anyone working on this? It seems like a lot of effort to get RefCounted to
@nogc, just wanted to see if anyone else was working on it before I go any
further and possibly duplicate work.

I think for this to work properly some of the non-allocating GC functions will need to be annotated with @nogc so we can properly hold references to GC allocated memory - I'm not sure how else to work around this but maybe someone more experienced than I am knows. I opened an enhancement request about it, I'm not sure if it will go anywhere.

Bye.

--
February 12, 2015
https://issues.dlang.org/show_bug.cgi?id=13972

--- Comment #4 from Andrei Alexandrescu <andrei@erdani.com> ---
I don't think anyone is working on this for the time being.

Marking some of the low-level GC functions as @nogc seems like a good way to go.

--
February 17, 2015
https://issues.dlang.org/show_bug.cgi?id=13972

Nick Treleaven <ntrel-pub@mybtinternet.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ntrel-pub@mybtinternet.com

--
March 31, 2015
https://issues.dlang.org/show_bug.cgi?id=13972

weaselcat <r9shackleford@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |14171

--
April 10, 2015
https://issues.dlang.org/show_bug.cgi?id=13972
Issue 13972 depends on issue 14171, which changed state.

Issue 14171 Summary: Mark non-allocating GC functions as @nogc https://issues.dlang.org/show_bug.cgi?id=14171

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--
April 10, 2015
https://issues.dlang.org/show_bug.cgi?id=13972

--- Comment #5 from weaselcat <r9shackleford@gmail.com> ---
AFAICT The only thing blocking refcounted from being @nogc is the enforce in the initialize now.

--
« First   ‹ Prev
1 2