I am not convinced this is the best way to go although it would be a relatively easy solution.
What I would personally prefer was if there was a language mechanism to mark theAllocator, processAllocator (iAllocator) to be @nogc as long as the allocator in question is not the GCAllocator. I am thinking specifically of the situation where vendor A can create a dynamic library in D that uses theAllocator and vendor B uses that library without necessarily having the source code. On Wed, Jul 27, 2016 at 7:05 AM, bitwise via Digitalmars-d <[email protected]> wrote: > On Tuesday, 26 July 2016 at 14:51:21 UTC, jmh530 wrote: >> >> On Tuesday, 26 July 2016 at 01:07:27 UTC, Chris Wright wrote: >>> >>> >>> @nogc conflates "doesn't allocate memory from the GC heap because I don't >>> want my application to use the GC at all" with "doesn't cause GC collection >>> pauses". >>> >>> The latter can have a @assumenogc annotation that works -- you call >>> GC.disable and GC.enable as appropriate. The former can't. >> >> >> For whatever reason, I like the idea of annotations behaving like enums. >> So instead of @gc or @assumenogc, you could have something like @nogc.false >> or @nogc.assume. You wouldn't add new annotations, just new behavior for >> existing annotations. > > > Chris is right that @safe/@trusted is not analogous to @nogc/@assumenogc, > but I still think @assumenogc is a good idea..or maybe @nogc(false) to offer > the opposite behaviour of @nogc. > > There are arguments that can be made against this idea, but IMO, it's really > hard to screw this up unintentionally. It's not like it's an invisible > implicit conversion. > > There are plenty of valid use cases. One, like I mentioned, about strongly > deterring allocations in certain contexts instead of completely disallowing > them. Also, deferring garbage collection until the end of a performance > sensitive algorithm that may still allocate, so that GC.collect can be > called manually afterward. > > Bit. >
