On Sat, 28 Feb 2009 13:03:05 -0800, Andrei Alexandrescu wrote:

> Walter Bright wrote:
>> Jarrett Billingsley wrote:
>>> See it's funny, since in the other post, you said that using an autogenerated header file is semantically indistinguishable from compiling it to a metadata file.  And here you're pointing out an obvious shortcoming!
>> 
>> You can make hand-generated ones, too. The idea of keeping private imports private is to explicitly *avoid* dependencies on knowing the contents. It's a principle of encapsulization.
> 
> encapsuli...what? I definitedly need to conceptify that one :o).

I think the word Walter was reaching for was "encapsulement"  ;-)

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

On Sat, Feb 28, 2009 at 5:30 PM, Derek Parnell <derek@psych.ward> wrote:

>>> You can make hand-generated ones, too. The idea of keeping private imports private is to explicitly *avoid* dependencies on knowing the contents. It's a principle of encapsulization.
>>
>> encapsuli...what? I definitedly need to conceptify that one :o).
>
> I think the word Walter was reaching for was "encapsulement"  ;-)

Encapsulosity.

Walter Bright wrote:
> Christopher Wright wrote:
>> Additionally, the compiler has sufficient information to complain about the problem at compile time, but it doesn't. That is a bug.
> 
> No, it does not. The compiler doesn't know about private imports of separately compiled modules.

Okay, the compiler could gain that information, but it does not, since it is not required. In many cases, the compiler could detect these issues. Detecting these would be a reasonable, if low priority, enhancement.

Christopher Wright wrote:
> Walter Bright wrote:
>> Christopher Wright wrote:
>>> Additionally, the compiler has sufficient information to complain about the problem at compile time, but it doesn't. That is a bug.
>>
>> No, it does not. The compiler doesn't know about private imports of separately compiled modules.
> 
> Okay, the compiler could gain that information, but it does not, since it is not required. In many cases, the compiler could detect these issues. Detecting these would be a reasonable, if low priority, enhancement.

The problem if it detects it in an implementation-defined manner is the source code is no longer portable.

Walter Bright wrote:
> Christopher Wright wrote:
>> Walter Bright wrote:
>>> Christopher Wright wrote:
>>>> Additionally, the compiler has sufficient information to complain about the problem at compile time, but it doesn't. That is a bug.
>>>
>>> No, it does not. The compiler doesn't know about private imports of separately compiled modules.
>>
>> Okay, the compiler could gain that information, but it does not, since it is not required. In many cases, the compiler could detect these issues. Detecting these would be a reasonable, if low priority, enhancement.
> 
> The problem if it detects it in an implementation-defined manner is the source code is no longer portable.

... If the result of compilation provably won't *run* anyway, what's the problem with a compile-time error?

Frits van Bommel wrote:
> Walter Bright wrote:
>> Christopher Wright wrote:
>>> Walter Bright wrote:
>>>> Christopher Wright wrote:
>>>>> Additionally, the compiler has sufficient information to complain about the problem at compile time, but it doesn't. That is a bug.
>>>>
>>>> No, it does not. The compiler doesn't know about private imports of separately compiled modules.
>>>
>>> Okay, the compiler could gain that information, but it does not, since it is not required. In many cases, the compiler could detect these issues. Detecting these would be a reasonable, if low priority, enhancement.
>>
>> The problem if it detects it in an implementation-defined manner is the source code is no longer portable.
> 
> ... If the result of compilation provably won't *run* anyway, what's the problem with a compile-time error?

Right. It's like the compiler warning you if your program starts with "assert (false)".

Frits van Bommel wrote:
> Walter Bright wrote:
>> The problem if it detects it in an implementation-defined manner is the source code is no longer portable.
> 
> ... If the result of compilation provably won't *run* anyway, what's the problem with a compile-time error?

Nothing, it's just that the compiler cannot prove it is an error.

Walter Bright wrote:
> Frits van Bommel wrote:
>> Walter Bright wrote:
>>> The problem if it detects it in an implementation-defined manner is the source code is no longer portable.
>>
>> ... If the result of compilation provably won't *run* anyway, what's the problem with a compile-time error?
> 
> Nothing, it's just that the compiler cannot prove it is an error.

Not even on a best-effort basis?
It doesn't have to catch every possible case; I for one would be perfectly fine with it if it didn't catch the "I omitted a private import from my .di file" case...

Frits van Bommel wrote:
> Not even on a best-effort basis?
> It doesn't have to catch every possible case; I for one would be perfectly fine with it if it didn't catch the "I omitted a private import from my .di file" case...

Doing so would require full blown data flow analysis, which the front end is not equipped to do.