Andrei Alexandrescu:

3. Reserved identifiers (checkDefinedNames). A C and C++ naming rule that often gets forgotten is that all identifiers starting with an underscore followed by an uppercase letter, plus all identifiers containing two consecutive underscores, are reserved by the implementation. (Of course there are exceptions to the rule in our code, such as _GNU_SOURCE or _XOPEN_SOURCE, which is why flint keeps aside a whitelist while checking for reserved identifier patterns.)<

D language has similar rules, but I don't rember if the D compiler warns against usage of similar identifiers.

8. Initializing a variable from itself (checkInitializeFromItself). We found that people wrote constructors like:

class X {
   int a_;
   X(const X& rhs) : a_(a_) {}
   X(int a) : a_(a_) {}

The intent was to use a_(rhs.a_) in the first constructor and a_(a) in the second. That hardly ever helps, and the compiler keeps mum about it. We like to say, "There's a flint rule for that," in order to resolve the problem.<

I'd like a similar warning in the D compiler for a similar (very) common bug:

class Foo {
   int x;
   this(int x_) { this.x = x; }
void main() {}

16. Check against throwing new-allocated bald pointers (checkThrowsHeapException). This eliminates the throw new T anti-pattern.<

I don't fully understand this.

The "throw new Exception(...)" pattern in D was recently discussed, and sometimes re-using an Exception is more efficient.

20. Pass cheap types by value (checkFollyStringPieceByValue). Certain user-defined types, such as iterators or pair of iterators, are small and cheap to copy so it's virtually always better to pass them by value instead of the conservative reference to const. Folly's StringPiece is an example - it occupies two words and has raw copy semantics.<

In D there is about the same problem.

Additionally the D compiler doesn't warn if you do kind of the opposite:

alias MyArr = int[5000];
void foo(MyArr x) {}
void main() {}


Reply via email to