This is a general discussion which applies to all computer languages and also under several decades. What I have observed is that language designers see programmers misuse the language and introduce possible bugs and therefore remove features in languages. An analogy would limit the functionality of cars because people sometimes are involved in accidents, like automatic speed limiter (soon to be law in several countries).

Language designers seem to have a big brother attitude towards programmers and think they will save the world by introducing limitations.

Examples.

Array indexes should be signed instead of unsigned because somehow programmers mess up loops among other things. Bjarne Stroustrup considered his unsigned index to be a historic mistake. While unsigned array indexes make perfectly sense, the bias towards signed seems to be that programmers are stupid. The question is, if can't make a for loop with unsigned math, shouldn't you look for another job?

Somewhat related. when Java was designed, the designer (James Gosling I believe) claimed that programmers were too stupid to understand the difference between signed and unsigned math (despite often several years of university education) and removed signed math entirely from the language. The impact is that when unsigned math is required, you are forced to conversions and library solutions. Not ideal when an HW APIs deals with unsigned numbers for example.

You are welcome to add any other examples that you find significant for the discussion.

This partially applies to D in some extent but can often be found in other languages and mentality of several language designers.

The question is, do you think language designers go to far when trying to "save" programmers from misuse or not?
Do you think there can be approaches that both prevent bugs at the same time do not limit the language?

On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:

I think that a tool should not prevent unrecommended uses completely, but it should make them harder so it won't be done by mistake or because it's easier than the right way. Well, that's my standard philosophy to this issue anyway, but perhaps there are cases where that approach is too idealistic. But IMO it's what D usually does. Examples:

String mixins. They can be used to do anything the C preprocessor can do (and more!), but the syntax is ugly so it's nicer to use normal templates, manifest constants, aliases or at least template mixins when they can do the job.

version declarations. They do not allow expressions in them, but if one really needs expressions, static if will work around the problem.

Default initialization. The shortest syntax will not introduce heisenbugs, but if performance is really that important there's still =void.

Floats default initialized to NaN instead of 0. One can still initialize them to anything, but this forces to think about it.

It's hard to appreciate how good that Java decision was without maintaining large C++ codebases.
Unsigned/signed math and the implicit conversions between them absolutely DO cause bugs in real-world code, the most prominent of which must be:

#include <vector>
#include <iostream>

bool isArrayOrdered(std::vector<int>& vec)
{
    for (size_t n = 0; n < vec.size() - 1; ++n)
    {
        if (vec[n] > vec[n+1])
            return false;
    }
    return true;
}

int main(int argc, char** argv)
{
    std::vector<int> v;
    // works if the array isn't empty
    // v.push_back(4);
    std::cout << isArrayOrdered(v);
}

See the bug in isArrayOrdered?

It will fail with an empty array since:

1. vec.size() yields size_t
2. vec.size() - 1 stays unsigned, if the size was zero it is now the maximum possible size
3. and we have an unsigned comparison, with a very long loop which in this case will cause out of bounds

(Solution: use + 1 on the other side of the comparison)

Similar problems happen when people store image size with unsigned, or widget positions in unsigned, or dates in unsigned integers.

All of these problems disappear:

• if only signed integers are available.
• if container length return a signed integer (and that's what D could have done...)
• if comparison or arithmetic with mixed signedness is forbidden (but: lots of casts)

Programmers do not actually learn about integer promotion except when forced by such bugs.
It has nothing to with programmers being dumb or low-skilled, and everything to do with an economy of information: it's better if the problem doesn't exist in the first place.

So I believe Java made a decision that saves up mental space.

On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:

"In programming language design, one of the standard problems is that the language grows so complex that nobody can understand it. One of the little experiments I tried was asking people about the rules for unsigned arithmetic in C. It turns out nobody understands how unsigned arithmetic in C works. There are a few obvious things that people understand, but many people don't understand it."

https://www.artima.com/articles/james-gosling-on-java-may-2001

Turns out not everyone has an university degree for programming, and many known less than they actually are able to deliver, specifically when under stress and deadlines.

By the way, Java supports unsigned math since Java 8 via unsigned math methods, if only people would actually bother to update, we are on version 16 now.

On Saturday, 7 August 2021 at 14:21:52 UTC, Guillaume Piolat wrote:

Gotchas like that are harmful but well-known, and the knowledge in our days spreads fast thanks to the internets. I believe an average C++ programmer today is less likely to make that mistake. On the other hand, we don't know how much harm the lack of unsigned types has caused. To claim that it is less harmful would be a case of survivorship bias.

On Saturday, 7 August 2021 at 14:21:52 UTC, Guillaume Piolat wrote:

#include <vector>
#include <iostream>

bool isArrayOrdered(std::vector<int>& vec)
{
    for (size_t n = 0; n < vec.size() - 1; ++n)
    {
        if (vec[n] > vec[n+1])
            return false;
    }
    return true;
}

int main(int argc, char** argv)
{
    std::vector<int> v;
    // works if the array isn't empty
    // v.push_back(4);
    std::cout << isArrayOrdered(v);
}

Your example is a valid argument as well as you provide the solution for unsigned math. The most interesting with the example is that your example provide a one comparison solution for signed/unsigned. This type of error would quickly be found as it would generate an exception in both C++ and D. Then perhaps the lazy programmer would just do an extra check when the size is zero. For example

 bool isArrayOrdered(std::vector<int>& vec)
 {
     if (vec.empty())
     {
          return true;
     }

     for (size_t n = 0; n < vec.size() - 1; ++n)
     {
         if (vec[n] > vec[n+1])
             return false;
     }
     return true;
 }

This would be better but requires an extra check, two comparisons. I think you provide an excellent example that the problem isn't signed/unsigned math but how you can use the arithmetics to your advantage regardless signed/unsigned. There are often solutions when using unsigned math and that is what I think the programmer should learn instead of limiting the language.

On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:

Zig does stuff like this and it's why I can't take that language seriously. At all. To paraphrase what I was told by Zig's community and BDFL: "if there's multiple ways to do something then obviously dumb dumb programmer will get it completely wrong".

I like programming languages that help me catch bugs (D or Rust), not languages that treat me like a 3 year old.

On Sunday, 8 August 2021 at 08:59:16 UTC, Walter Bright wrote:
[...]

indeed