Proposed improvements to the separate compilation model

[Rob T]

On Tuesday, 5 March 2013 at 12:20:15 UTC, Dicebot wrote:
> On Tuesday, 5 March 2013 at 10:41:36 UTC, Jacob Carlborg wrote:
>> On 2013-03-05 09:48, Dicebot wrote:
>>
>>> I can find nothing on the topic of "separation" issue down 
>>> that link. In
>>> fact I have never met a C/C++ programmer saying fact of 
>>> having a
>>> separate headers is a problem, it was a loved feature if 
>>> anything.
>>> Problem was the way it was designed, via pre-processor. D 
>>> fixes this by
>>> introducing real symbolic imports and that is good, but 
>>> completely
>>> irrelevant to the topic of separation of interface and 
>>> implementation.
>>
>> We are all here :)
>
> Well, that is why I am so surprised and asking for rationale 
> with better explanation than "it is obvious". I am rather 
> astonished by an overall negative reaction to a long awaited 
> (by me) Andrei proposal.

Clearly there's a misunderstanding going on somewhere. For 
example when I say "code duplication" you say "There is close to 
zero code duplication." but from my POV there clearly is code 
duplication and it is indeed significant and completely 
unnecessary. Also my understanding of what a module accomplishes 
is a super set of what you think a module accomplishes, i.e., I 
include that it solves the code duplication problem, you don't.

I agree that the current method of automated .di generation is a 
failure, but I think it is a failure only because the programmer 
has no control over specifying what goes into the .di file from 
within the module source, and that the automated .di generation 
and maintenance implementation is incomplete.

At this point in the discussion, I don't see a sound reason why 
the automated .di generation cannot be fixed (proposed solutions 
haven't even been discussed in any depth), and regressing back to 
manual separation of code seems like a "quick fix" hack that 
introduces a set of serious problems that cancel out the benefits 
and probably make the situation worse.

You seem to support the idea of using manual .di generation and 
maintenance, which implies to me that you think automated .di 
generation cannot succeed, is this correct? If so, then I have to 
ask why?

--rt