boost crowd.

[Timon Gehr]

On 11/28/2011 06:41 PM, Maxim Fomin wrote:
> 2011/11/28 Timon Gehr<timon.gehr at gmx.ch>:
>> On 11/28/2011 09:01 AM, so wrote:
>>>
>>> On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright
>>> <newshound2 at digitalmars.com>  wrote:
>>>
>>>> On 11/27/2011 4:44 PM, Alexey Veselovsky wrote:
>>>>>
>>>>> "D has a true module system that supports separate compilation and
>>>>> generates and uses module summaries (highbrowspeak for "header files")
>>>>> automatically from source, so you don't need to worry about
>>>>> maintaining redundant files separately, unless you really wish to, in
>>>>> which case you can. Yep, that stops that nag right in mid-sentence."
>>>>>
>>>>> But it is not true...
>>>>
>>>> How is it not true?
>>>
>>> I don't know if .di generation from .d or .h is any good or bad,
>>> but the comparison of auto-generated .di files to hand crafted .h files
>>> doesn't make sense.
>>
>> Nobody stops you from hand crafting *.di files.
>>
>
> And what sense is in hand crafting .di files? What would you do different?
> Remove method definitions/private members?

The main point is that some people want to have separate specification 
and implementation. If you don't separate the two, they risk being 
confused. (as is often the case with the D programming language and its 
reference implementation.)

In such a setting, the .di file can eg. act as a contract between 
library implementer and library user.

Eg:

// .di, this is the specification

module awesomeLibrary;

/**
  * Documentation comment
  */

int foo(in int x)
/// maybe documentation comment on in contract
in{assert(x<int.max);}
/// maybe documentation comment on out contract
out(result){assert(result>x);}

class Bar {
     int foo(int x)
     in{...}
     out{...}
}



// .d, the implementation

int foo(int x) { // (contract automatically read from .di file)
     return x+1;
}

class Bar{
     int foo(int x){
         return x + y;
     }
     private int y;
}




And that is the kind of stuff that does not work yet.