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.

Same as in Lisp, one of the most beloved of languages on HN.

Were Lisp's macros a mistake? Some will say yes, but overall the language is more praised for them than damned.

So highly regarded are Lisp macros that many languages will eagerly proclaim that they have macros too -- even if they're not homoiconic and so harder to work with than in Lisp. Few if any are the languages that proudly proclaim that they don't have macros because they thought Lisp macros were a big mistake.

C++ fans themselves often point out that C++ templates can be as powerful as Lisp macros.

So which is it? Is giving users the power to radically transform their language a bug or a feature?

For example:

https://lispcookbook.github.io/cl-cookbook/iteration.html

https://docs.racket-lang.org/reference/for.html

BTW, in C++ every call is resolved at compile time, and the compiler could tell you what you are exactly doing at each line, including whether your examples are function calls or casts. If you dump the right table in GCC the information is there, although it's a pity there is no convenient way to access it. Cppexplorer helps a little bit, but I always find it difficult to understand. It's a problem of tooling, though, the language is well defined.

CLion, ctrl+B.

Or to make it easy to describe high-level behavior where you don't care about the details. In your example, foo and bar could be some complex vector or matrix types with custom allocation/deallocation logic.

So this line:

  int x = foo(2) + bar(3);

  foo tmp_foo;
  bar tmp_bar;
  construct_foo_from_int(&tmp_foo, 2);
  construct_bar_from_int(&tmp_bar, 3);
  int x = add_foo_and_bar(&tmp_foo, &tmp_bar);
  free_foo(&tmp_foo);
  free_bar(&tmp_bar);

BTW, (foo)2 syntax is preserved for backward compatibility with C and is deprecated in favor of static/dynamic/reinterpret_cast<>() (that many people don't use due to clunkiness) and foo(2) is unavoidable if foo's constructor has more than 1 argument.

That being said, it can certainly be ugly. A lot of the ugliness comes from trying to maintain itself as a mostly superset of C. Technically it no longer is strictly that, but most C code will compile fine in a C++ source file.

I don't understand your point. What's exactly the problem of knowing what are foo and bar? Even if you struggle with C++, any half decent IDE allows you to check the symbol and see what's being called with a single mouse click.

So what's exactly the problem?

> As another example consider implicit type conversions:

Again, what's exactly the problem? If you write down "c+3" it's your responsibility to know what you are doing and that "c+3" does make sense. And your example can only start to become a possibility if you explicitly and quite intentionally define your constructors to allow implicit type conversions, which is a direct violation of basic C++ best practices.

Adding to that, your convoluted example is no where near the mess that's javascript or Python and somehow people manage to not screw that up even without any type checking.

So why single out C++ although it does provide all sorts of guardrails and sanity checks?

> Many of these craziness

You failed to show any semblance of "craziness" in any of the convoluted examples you presented. In fact, you only showed you struggle with a language you barely have any experience with, let alone a grasp on rudimentary best practices such as requiring explicit constructors. Thus, why pin the blame on the language instead of where it really belongs: your lack of knowledge and experience using the language?

The casting style can be enforced via linting. There are also C++ cast operators, that in my opinion should be preferred to the C style casts: static_cast, dynamic_cast, reinterpret_cast, const_cast, static_pointer, dynamic_pointer_cast, const_pointer_cast... and you can enforce that those are preferred rather than C style casts.