Should pure nothrow ---> @pure @nothrow ?

[bearophile]

Denis Koroskin:

> I think "do not affect the generated code" is a bit restricting.
> [...] There are endless possibilities.

Lombok gives annotations to reduce boring lines of Java code:
http://projectlombok.org/features/index.html

Some of those annotations:
@Getter / @Setter: Never write public int getFoo() {return foo;} again.

@ToString: No need to start a debugger to see your fields: Just let lombok generate a toString for you! (I think this can be automatic for D structs).

@EqualsAndHashCode: Equality made easy: Generates hashCode and equals implementations from the fields of your object.

@Synchronized: synchronized done right: Don't expose your locks.

More info on the @Synchronized:
>@Synchronized is a safer variant of the synchronized method modifier. Like synchronized, the annotation can be used on static and instance methods only. It operates similarly to the synchronized keyword, but it locks on different objects. The keyword locks on this, but the annotation locks on a field named $lock, which is private. If the field does not exist, it is created for you. If you annotate a static method, the annotation lo cks on a static field named $LOCK instead. If you want, you can create these locks yourself. The $lock and $LOCK fields will of course not be generated if you already created them yourself. You can also choose to lock on another field, by specifying it as parameter to the @Synchronized annotation. In this usage variant, the fields will not be created automatically, and you must explicitly create them yourself, or an error will be emitted. Locking on this or your own class object can have unfortunate side-effects, as other code not under your control can lock on these objects as well, which can cause race conditions and other nasty threading-related bugs.<

Bye,
bearophile