12/21/2012 12:44 PM, Timon Gehr пишет:
> On 12/21/2012 06:41 AM, Walter Bright wrote:
>> ....
>>
>> D has an excellent module system.
>
> ... modulo the private symbol clash issue. For all I know it is
> deliberate, which is embarrassing. Other than obviously breaking
> modularity, it severely restricts the usefulness of symbol
> disambiguation (which it makes necessary when it should not be), because
> the disambiguating alias may introduce more conflicts even if it is
> private, all over the code base.
>

+1. It never made any sense to me that private is visible but not accessible. A carryover from C++ I guess (but there we just hide stuff out of the header file, use awful internal namespaces etc.).

> Eg:
>
> https://github.com/D-Programming-Language/druntime/pull/298#discussion_r1691013
>
>
>> No, I don't think Go or anyone else has a better one.
>
> Other languages that support modules usually get hiding of private
> symbols (or equivalent) right.


-- 
Dmitry Olshansky

Walter Bright:

> another large source of irritation if unused imports are errors.

In Go even unused variables are *errors* :-)


> D has an excellent module system. No, I don't think Go or anyone else has a better one.

I think D module system is a primitive tool compared to (S)ML module system.

http://en.wikipedia.org/wiki/Standard_ML#Module_system

More info on SML module system can be found with Google.

Bye,
bearophile

On Friday, December 21, 2012 12:57:10 Dmitry Olshansky wrote:
> +1. It never made any sense to me that private is visible but not accessible. A carryover from C++ I guess (but there we just hide stuff out of the header file, use awful internal namespaces etc.).

It also makes stuff like private aliases useless. I don't really know of any reason _not_ to fix it. At minimum, private symbols should be removed from overload sets outside of their module, though they may need to remain visible (but inaccessible) in dealing with stuff other than overload sets.

- Jonathan M Davis

On 12/21/2012 12:58 AM, bearophile wrote:
> Walter Bright:
>> D has an excellent module system. No, I don't think Go or anyone else has a
>> better one.
>
> I think D module system is a primitive tool compared to (S)ML module system.
>
> http://en.wikipedia.org/wiki/Standard_ML#Module_system

Then why did you bother with the Go module system?

Walter Bright:

> Then why did you bother with the Go module system?

The Go and D module systems are comparable, while the SML module system is something quite different and another (higher) level.

Bye,
bearophile

On Friday, 21 December 2012 at 08:58:03 UTC, bearophile wrote:
> Walter Bright:
>
>> another large source of irritation if unused imports are errors.
>
> In Go even unused variables are *errors* :-)
>
>
>> D has an excellent module system. No, I don't think Go or anyone else has a better one.
>
> I think D module system is a primitive tool compared to (S)ML module system.
>
> http://en.wikipedia.org/wiki/Standard_ML#Module_system
>
> More info on SML module system can be found with Google.
>
> Bye,
> bearophile

SML modules are something entirely different from D modules. If you want SML module like functionality in D, the closest thing are actually structs with all members static (or just wrapping your functions in a template), not modules.

On Friday, 21 December 2012 at 08:58:03 UTC, bearophile wrote:
> Walter Bright:
>
>> another large source of irritation if unused imports are errors.
>
> In Go even unused variables are *errors* :-)

This is a tricky one. On one hand, it *is* a useful way to catch errors, but on the other it's a constant source of irritation when you are tinkering with code during development/debugging.

On Friday, 21 December 2012 at 13:19:32 UTC, Peter Alexander
wrote:
> On Friday, 21 December 2012 at 08:58:03 UTC, bearophile wrote:
>> Walter Bright:
>>
>>> another large source of irritation if unused imports are errors.
>>
>> In Go even unused variables are *errors* :-)
>
> This is a tricky one. On one hand, it *is* a useful way to catch errors, but on the other it's a constant source of irritation when you are tinkering with code during development/debugging.

I would consider those not as (language, compile-time) errors but
(not-)compliance with strictness-levels.

However, it is reasonable to include something like strictness
levels as part of the compiler? (think gcc with MISRA-C
integrated).

jerro:

> SML modules are something entirely different from D modules.

Yep. (That's what I have said to Walter).


> If you want SML module like functionality in D,

I don't. I (did) want modules to have the same name as their files.

Bye,
bearophile

On 12/21/12, bearophile <bearophileHUGS@lycos.com> wrote:
> Walter Bright:
>
>> another large source of irritation if unused imports are errors.
>
> In Go even unused variables are *errors* :-)

There was a long blost post somewhat recently (well, it might be from this year at least) where the author complained how the Go compiler likes to error on the most trivial things, and how it interrupts the workflow of the programmer. The link is somewhere on reddit.

If I really want to get all the warnings I would want to have a special flag for these kinds of trivial things (which will probably never happen), but then again I might as well use another tool for it.

Speaking of tools: you could fork DMD, add all the warnings you want in the front-end and provide a script for users that automatically git clones your repo and builds the custom DMD, which can then be used as a lint tool. That way you avoid having to create something from scratch, and avoid redistribution issues.