Disallow null references in safe code?

Adam D. Ruppe destructionator at gmail.com
Tue Feb 4 20:23:56 PST 2014


On Tuesday, 4 February 2014 at 16:00:20 UTC, Meta wrote:
> I'm interested in how this might fit in with your recent 
> discovery in this thread:
>
> http://forum.dlang.org/thread/majnjuhxdefjuqjlpbmv@forum.dlang.org?page=1

There's a lot of potential for pluggable semantic checks with 
that. Earlier today, I toyed with it for checking virtual 
functions:

import core.config;
class Foo {
         @virtual void virt() {} /// annotated so OK
         void oops() {} // not annotated, yet virtual, we want a 
warning
}


module core.config;

string[] types;

template TypeCheck(T) {
         static if(is(T == class))
                 enum lol = virtualCheck!T();
}

enum virtual;

bool virtualCheck(T)() {
         foreach(member; __traits(derivedMembers, T)) {
                 static if(__traits(isVirtualFunction, 
__traits(getMember, T, member))) {
                         static if(__traits(getAttributes, 
__traits(getMember, T, member)).    length == 0)
                         pragma(msg, "Warning " ~ T.stringof ~ "." 
~ member ~ " is virtual");
                 }
         }
         return true;
}


Warning: Foo.oops is virtual




A similar thing could be set up for nullable, or maybe even 
borrowed (though it would fall short there without the help of 
the scope storage class on parameters and return values).


It'd scan all the types and if not explicitly marked nullable or 
NotNull, it can throw a static assert or pragma(msg).

But RtInfo can't see local variables nor module-level free 
functions, so it can't do a complete check. I'd love a "RTInfo 
for modules" (enhancement in bugzilla already) and a way to 
inspect local varaibles with __traits somehow too...



Anyway, bottom line is rtinfo can help add some of these 
semantics but wouldn't go all the way. Going all the way will 
break code, but I think it will be worth it. Breakage in general 
is wrong, but when it helps find latent bugs and is relatively 
easy to deal with (adding Nullable! or GC! in appropriate places) 
the benefits may be worth the cost. I believe that's the case 
here.


More information about the Digitalmars-d mailing list