Bolts 1.4 - added experimental signatures for D

[aliak]

Hi,

I've released an experimental implementation of the concept of 
traits/signatures/protocols-ish. The basics seems to work 
decently well, with very decent error messages e.g.:

source/bolts/experimental/signature.d(111,17): Error: static 
assert:  "Type Y is missing the following members of enum X: 
["three"]
   source/bolts/experimental/signature.d(156): <-- Signature Sig 
defined here.
   source/bolts/experimental/signature.d(166): <-- Mixed in here."

Package: https://code.dlang.org/packages/bolts
Implementation PR: https://github.com/aliak00/bolts/pull/6/files

I'm not sure about a few things thought and wouldn't mind some 
feedback.

1. Malleable properties. Take input ranges for example:

struct InputRange(T) {
   bool empty() { return true; }
   // other members...
}

This works:

struct SomeRange(T) {
   mixin ModelsSignature!(InputRange!T));
   bool empty() { return true; }
   // other members...
}

But for variations such as infinite ranges, this will not work

struct SomeRange(T) {
   mixin ModelsSignature!(InputRange!T));
   enum empty = false;
   // other members...
}

The way I'm thinking of handling it right now is by using UDAs?

struct InputRange(T) {
   @onlyAssign
   bool empty;
   // other members...
}

So then the mixin template Models will check if a name has the 
UDA onlyAssign attached to it, and if so it will be more lenient 
with the SomeRange struct.

Does anyone have any other suggestions?

2. Naming. Not very happy with onlyAssign, and also 
ModelsSignature. Any bikesheds? :p

3. Having to implement functions. Like in the InputRange 
signature above, I had to implement function empty. So for that 
I'm thinking templates? Something like:

struct Signature {
   mixin Function!("f", int(int, int));
}

Or the like? And the mixin would put in a stubbed function named 
"f" that returns int.init

Opinions?

Cheers,
- ali