It is true that C language has some very limited implicit type conversions. For example you can say:

   long n = 3;

  unsigned n;
  n = 2.99;      // n = 2
  n = -1;        // n = 2^M-1;
  n = 1.0E33;    // undefined but not catched

  auto n = a + b;

I disagree. I think ever since it’s inception from C, C++ has tried to increase type safety and continuously move more of the work to the compiler (latest example is concepts). It does empower the programmer to do what they want: OOP, FP, GP...

The philosophy of the language is mostly about abstractions. Abstracting objects, types, resource management etc And using modern C++ features and a recent compiler makes it harder to make mistakes. Using some generally accepted guidelines and static analysis tools helps even further.

Though the syntax is at times ugly due to the age of the language and it has a lot of inertia that makes it hard to get rid of some bad design decisions like some of the defaults, unless someone recreates c++ with the same flexibility and power, and the same powerful compilers/tools but with better syntax and defaults I don’t see the language going anywhere. And I am not holding my breath for another language to quickly be able to reproduce the C++ echo system that have taken decades to develop.

What? C will happily compile this:

    void g() {
        float f = 3.14;
        int* ip = &f;
    }

    complex c = 3i;
    ... = c + 4;

The issue with C++ is that implicit is the default, not that it exists.

With that said, C programmers also seem to love their implicit behavior so it's pretty clear where this kind of thinking comes from.

Only if you ignore your compiler output: Even TinyCC will warn about that one on default settings. With the flags I use, the code would in fact fail to compile.

Also, I agree that implicit conversions in general should be avoided, but this complex number example feels like the perfect use case.

    complex c = 4;

The issue with C++ is that implicit is the default, not that it exists.

If your data type implements the Num typeclass, you can use literals like 4. (A typeclass in Haskell is similar to what they call an interface in Java.)

There's no automatic conversion happening at all. It's done via overloading literals at compile time. (You can do the same for strings.)

What it doesn't solve that by default the compiler tries to find an appropriate implicit conversion. Sometimes it's convenient, sometimes it's harder to see what the code actually does.

Yes, the implicit conversion for all values is part of the problem. The Haskell approach only gives you magic for literals.