On 7/23/16 5:44 PM, Rufus Smith wrote:
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.
Again, I want to stress that Object.opEquals has been around since early
D1 days, @nogc is only a few years old, it was not a wrong decision.
@nogc cannot be added without breaking code, and even if you could, it's
not correct for opEquals.
The issue is one of design, Object should not define which attributes
are acceptable on all objects, that should be up to the class designer.
The solution is to deprecate and remove all convenience functions from
Object.
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.
This is an extreme solution for a minor problem.
-Steve
