On Saturday, 23 July 2016 at 17:27:24 UTC, Lodovico Giaretta
wrote:
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.
This is bad. It only creates a faulty foundation. The whole point
of nogc is to enforce nogc behavior. If you don't use it your not
enforcing anything and then things slip by only to create
problems later. This mentality is completely wrong and leads to
decay. This is exactly why we are discussing this right now,
because someone decided that it was ok to ignore other use cases
which eventually turn out to be quite important.
If, say, D was built without the GC, then adding the GC would be
much easier and more logical than what has been done, which is
built with GC and trying to remove it.
- 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).
Templates are not the end all be all. They don't allow for
run-time polymorphism, which is an important aspect of software.
What we should have is that when something is added or removed we
are 100%(or close as we can get) that the feature is correct and
causes no side effects. D's GC causes side effects because it was
assumed that there would not be any. Now the future is hear and
it's up to us to try and unravel the mess the past created. It's
always best to just do it right in the first place, it saves
everyone from the headache.
DMD should probably be branched, and all GC stuff removed, then
built back up to have the proper features that the GC version
has. I think someone has essentially done this on their own, but
never built it up to full capacity.
