Comment by WalterBright | Hacker News Reader

Comment by WalterBright | Hacker News Reader

> Enable all warnings!

The trouble I've run into with that is different compilers have different warnings, sometimes they are mutually contradictory, so it is not possible to have portable code that doesn't trigger warnings in one compiler or another.

I.e. the general problem with warnings is the language gets balkanized into multiple competing and incompatible dialects.

What should happen is to carefully examine the warnings, and adopt the best into the language Standard as errors.

For example:

    if (a < b < c)

That is pretty much 100% a bug in the code. Just make it illegal already. D does.

For another:

    for (i = 0; i < 10; ++i);
    {
        ...
    }

Long ago, an expert C programmer came to me once and said he'd spent all day trying to figure out why his loop only executed once. I pointed to the semicolon. He sighed. I put a warning for that in the compiler. I noticed that other compilers eventually did, too.

In D, it's an error.

A third example:

In the Joint Fighter coding standard, it says don't use `l` as an integer suffixe, as in `124l`, because in many fonts it looks like `1241`. Solution: D does not allow `l` as a suffix. There's is no reason to support that suffix. No reason to put it in coding standard. Do the world a favor, just make it illegal. Done!

The warnings problem is nicely solved in Rust:

• There's a built-in way to silence specific warnings for specific portions of the code. When the compiler is wrong, instead of obfuscating the code to hide it from the compiler, you can directly mark "I know what I'm doing". Standard C can't do it, and compiler-specific #pragmas are much more clunky.

• Builds of dependencies automatically suppress lints, so builds with a -Werror equivalent won't break on someone else's code (that you may not be able to fix), just because your compiler has added new lints.

This kind of thing has been proposed many times over the years. It even existed back in the 1980s. I don't care much for it because it balkanizes the language into mulitple sub-languages.

I don't see what is there to balkanize. Are you against any lints that aren't formally specified or may have false positives?

If the compiler warns that e.g. you have an unused function argument, it may be a mistake, or it may be intentional (e.g. it's a callback for something that passes the arg anyway). Then you either have ad-hoc syntax extensions or dummy expressions for convincing the compiler it's used, which may fail in another compiler that defines "used" differently, or you explicitly silence the warning. Unused is relatively easy, but there's a whole category of pedantic lints for other code smells.

I've resisted adding warnings to D for a long time. A couple have crept in, due to strong desire from the D community. A warning is a strong symptom of the language designer(s) being unable to decide what the language rules should be. So they make multiple languages based on switches. That's what balkanization is.

D is a better language for having only a small number of warnings. It'd be even better with zero!

I don't think it's possible to have a language so perfect that nobody can write bad/weird code in it. There are always going to be cases of code that is technically permissible, but very unlikely to be intended, and warrant a "did you really mean to do this?" lint.

e.g. `unsigned < 0` is likely a mistake, but maybe comes from a macro/generic code that allows multiple types, or the zero is from some configurable constant. I don't see how flagging this is balkanizing anything.

If the compiler doesn't flag code smells, it's a missed opportunity to help users and catch mistakes early. OTOH if the compiler turns potentially-benign things and unidiomatic code into hard errors, then it's annoying during development and refactorings.

golang tried the no-warnings approach, and IMHO it's not working well. Sometimes it's too pedantic, but sometimes not strict enough. It sprouted `errcheck` and `go vet` to bring the warnings back.

Needing the warnings is still a failure of language design. Not being able to think of a better way isn't an excuse!

> sometimes they are mutually contradictory

Right, there are definitely some C++ specific warnings for different language compat rules (around std::move IIRC) that are non-mutually-satisfyable.

This article recommends -Weverything w/ Clang. Clang developers DO NOT ENDORSE the use of -Weverything.

> (a < b < c)

On the other hand the intention (assuming numerical types) is clear, if people keep doing this, what machine code is emitted by common compilers for the "best" way to express this? And how about for the idiomatic way to express it? Perhaps the insight, if it's common, is that we should provide a nice way to do this which emits efficient machine code.

Rust says "chained comparison" is forbidden, so it knows what we're going for here, and indeed it suggests you might want (a < b) && (b < c) which is how I'd write this, but of course the opposite could be faster, as perhaps could ((a+1)..c).contains(&b) and either may make more sense in context of the usage.

If you really want (a < b < c), then write it as ((a < b) < c) which D will accept with a shrug that the programmer might know what he's doing.

I meant that the intent is obviously the chained comparison. If lots of people do this (I have no idea) then it'd be nice to ensure we're doing that nicely, and if necessary here's syntax for expressing it (not in C though, where it already does the wrong thing).

What on Earth does your D expression do for numeric types? And why?

In Rust I can write this only if, in fact, c is always ordered with respect to a boolean which means c is itself a boolean. Since c is a boolean then ((a<b)<c) actually means ((a>=b) && c) which er... I guess? I doubt that writing either when you really meant the other will make your intent clear.

> I meant that the intent is obviously the chained comparison.

Yes, "Is `b` between `a` and `c`?" is a natural and common question to ask. FWIW, Julia does lower `a < b < c` as a chained comparison:

  julia> Meta.@lower a < b < c
  :($(Expr(:thunk, CodeInfo(
      @ none within `top-level scope`
  1 ─ %1 = a < b
  └──      goto #3 if not %1
  2 ─ %3 = b < c
  └──      return %3
  3 ─      return false
  ))))

That is, it turns `a < b < c` into `(a < b) && (b < c)`. You can make the chain arbitrarily (within reason) long.

Of course, if a language doesn't lower chained comparisons in this way, I would much rather have a compiler error than have it silently return `(a < b) < c`.

> I would much rather have a compiler error than have it silently return `(a < b) < c`

Exactly.

Sure, we're all in agreement that C and C++ (and probably some other semi-colon languages) make the wrong choice here.

In Godbolt I see "missing closing `)` after `if (a < b`" from D which unlike the Rust error doesn't acknowledge the user's intent and instead is talking about grammar. Hopefully the user will go read the documentation and find out that nope, you can't do that in D, because if they just adjust their code to silence the errors then they end up with ((a < b) < c) and that does... not do what they intended.

D does it with a grammar rule, not by looking for the case after the AST is constructed. It simply won't parse. Hence the origin of that error message.

I just tried Python, and it behaves like Julia.

So I agree the two reasonable behaviors are: 1. Chain the operations like Julia/Python 2. Throw an error, ideally with an informative message.

those misplaced semicolons are things i have only ever seen in extreme beginner code - "semicolon is a line terminator" school of thought. still. a warning would be good. nothing to do with the language itself, of course.

I've made the same mistake now and then. But I never suffer from it, as the compiler zaps me with a fatal error. It appears in other contexts, too, like:

    if (condition);
    {
        ...
    }

well, i guess we probably all have our favourite mindless error that we keep repeating but i can't honestly think of too many that i make. mine are more at the semantic level - things like iterator invalidation in c++, which are more tricky for the compiler to spot. out of interest, does D check for that kind of stuff?

D doesn't have iterators (it has ranges) so I don't really know what you mean.

Use proper fixed-width fonts! :P

l'd th0ught you wou1d say that!

The third one must be satire and if not your support for it must be

It's not hard to check, the guidelines are posted online:

https://www.stroustrup.com/JSF-AV-rules.pdf#page17

AV Rule 14 is the one in question. Uppercase suffixes are fine, lowercase is not, and the rationale is "Readability."

thank you for the link, I was too lazy to do the work myself

Reply on news.ycombinator.com