On Saturday, 23 July 2016 at 17:04:42 UTC, Jonathan Marler wrote:
On Saturday, 23 July 2016 at 16:46:20 UTC, Jonathan Marler
wrote:
[...]
Actually Im going to disagree with myself. This technique
actually wouldn't work with virtual methods:)
I don't think we have the big problems with @nogc that people
points out.
I mean, we cannot decide that specific methods or opXXX must
always be @nogc. That's too restrictive.
So, what we need to do is:
- use templates: with them, we can have our algorithms be @safe
when applied to @safe types, @nogc when applied to @nogc types,
and so on; for example, instead of taking a specific delegate
type, we shall always accept a generic type, and use traits to
guarantee it is some delegate; in this way, we can accept @safe
delegate and propagate @safety to our algorithm, or accept
@system and have our algorithm usable in @system code; same with
@nogc et al.
- when we use virtual methods, we are giving up all
compiler-checked attributes; in this situation we have two
options:
- we trust what we are doing: e.g. we cannot mark a thing
@nogc, but we know it is and the profiler confirms that no
allocation happens, so we are happy; our aim is having code that
doesn't freeze because of collections, and not marking code @nogc.
- we must have @nogc (or @whatever): then we know we cannot
use certain classes, because they are definitely @nogc; so we
cast the objects we get to the classes/interfaces that we know
are @nogc (and are marked as such), and then our code is @nogc;
as you see, you don't need Object to have @nogc methods; you only
need the specific classes you use have it; if you want to work on
generic objects, and as such cannot do specific casts, then you
should definitely be using templates.
The only real problems I found till now are:
- some things in Phobos that shall be @nogc are not; they shall
be refactored to have that attribute (but this is not always easy
and requires time)
- the interface IAllocator is mostly used with @nogc allocators,
but cannot have the said attribute (as I explained above, it must
not restrict the possibility of allocators); it shall have a
sub-interface NoGCAllocator, so that code can accept a @nogc
allocator parameter without using templates (of course templates
are fine, and are what we use now, but if everyone uses
templates, why have IAllocator in the first place? IMHO we must
have or both or none).
