December 21, 2012
On 12/21/2012 4:16 AM, bearophile wrote:
> 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.

From your wikipedia link, the SML module system is just a way to symbolically import things. Just like with D imports. I didn't see anything wow about it.

December 21, 2012
On 12/21/2012 5:19 AM, 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.

Such a change may also make dustmite unworkable.

https://github.com/CyberShadow/DustMite/wiki
December 21, 2012
On 12/21/2012 5:40 AM, eles wrote:
> However, it is reasonable to include something like strictness
> levels as part of the compiler? (think gcc with MISRA-C
> integrated).

Having multiple languages via a switch leads to much confusion and cost. I try to avoid such as much as possible.
December 21, 2012
On 12/21/2012 6:52 AM, Andrej Mitrovic wrote:
> It seems the compiler doesn't complain about invalid import statements
> when it tries to find the module via its import path. Bug?


I'd have to say that's a bug.
December 21, 2012
On Friday, 21 December 2012 at 20:33:47 UTC, Jonathan M Davis wrote:
> If we didn't have -w,
> then we could use warnings for stuff which was probably but not definitively
> wrong and which was okay to force people to change […] But because
> of -w, you can't […]

I don't think this is a valid argument: GCC has a similar flag (-Werror) too that many people use – for eaxmple, Google build all their code with it enabled, and other companies probably just as well – but still the compiler has quite a number of "best practices" warnings, e.g. regarding operator precedence rules.

David
December 21, 2012
On Friday, December 21, 2012 12:41:42 Walter Bright wrote:
> On 12/21/2012 5:40 AM, eles wrote:
> > However, it is reasonable to include something like strictness levels as part of the compiler? (think gcc with MISRA-C integrated).
> 
> Having multiple languages via a switch leads to much confusion and cost. I try to avoid such as much as possible.

I would point out that -w does exactly that thanks to conditional compilation and compile-time introspection. Perfectly valid code can not only become invalid, but it can end up with very different semantics when -w and conditional compilation are combined. In the case of unused variables, if we were to warn for it and use -w, it would completely break Phobos due to many traits which have unused variables.

- Jonathan M Davis
December 21, 2012
On 12/21/2012 1:40 PM, Jonathan M Davis wrote:
> I would point out that -w does exactly that thanks to conditional compilation
> and compile-time introspection.

I know, and there are threads here where I opposed warnings very strongly.

December 21, 2012
On Friday, 21 December 2012 at 22:25:51 UTC, Walter Bright wrote:
> On 12/21/2012 1:40 PM, Jonathan M Davis wrote:
>> I would point out that -w does exactly that thanks to conditional compilation
>> and compile-time introspection.
>
> I know, and there are threads here where I opposed warnings very strongly.

Why not just make warnings a different class from normal errors, i.e. not increment global.errors for them? In fact, I seem to remember that we are doing this already?

David
December 22, 2012
On 12/21/2012 2:33 PM, David Nadlinger wrote:
> On Friday, 21 December 2012 at 22:25:51 UTC, Walter Bright wrote:
>> On 12/21/2012 1:40 PM, Jonathan M Davis wrote:
>>> I would point out that -w does exactly that thanks to conditional compilation
>>> and compile-time introspection.
>>
>> I know, and there are threads here where I opposed warnings very strongly.
>
> Why not just make warnings a different class from normal errors, i.e. not
> increment global.errors for them? In fact, I seem to remember that we are doing
> this already?

Considering all the discussion and debate about what to do with warnings and deprecations, I can't help but think the whole thing was a bad idea.

December 22, 2012
On 12/21/2012 12:44 AM, Timon Gehr wrote:
> ... 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.

The reason it is that way is to avoid having it behave gratuitously differently than how visibility works within classes and structs.