Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Now I haven't touched C++ in probably 15 years but the definition of main() looks confused:

> auto main() -> int

Isn't that declaring the return type twice, once as auto and the other as int?



No. The auto there is doing some lifting so that you can declare the type afterwards. The return type is only defined once.

There is, however, a return type auto-deduction in recent standards iirc, which is especially useful for lambdas.

https://en.cppreference.com/w/cpp/language/auto.html

auto f() -> int; // OK: f returns int

auto g() { return 0.0; } // OK since C++14: g returns double

auto h(); // OK since C++14: h’s return type will be deduced when it is defined


What about

auto g() -> auto { return 0.0; }


0.0 is a double, so I would assume the return type of g is deduced to be double, if that is what you're asking.


I was more pointing out that the syntax was dumb for that particular example!


I really wish they had used func instead, it would have saved this confusion and allowed for “auto type deduction” to be a smaller more self contained feature


the standard c++ committee is extremely resistant to introducing new keywords such as "func", so as not to break reams of existing code.


Indeed. I am a frequent critic of the c++ committee’s direction and decisions. There’s no direction other than “new stuff” and that new stuff pretty much has to be in the library otherwise it will require changes that may break existing code. That’s fine.

But on the flip side, there’s a theme of ignoring the actual state of the world to achieve the theoretical goals of the proposal when it suits. Modules are a perfect example of this - when I started programming professionally modules were the solution to compile times and to symbol visibility. Now that they’re here they are neither. But we got modules on part. The version that was standardised refused to accept the existence of the toolchain and build tools that exist, and as such refused to place any constraints that may make implementation viable or easier.

St the same time we can’t standardise Pragma once because some compiler may treat network shares or symlinks differently.

There’s a clear indication that the committee don’t want to address this, epochs are a solution that has been rejected. It’s clear the only real plan is shove awkward functional features into libraries using operator overloads - just like we all gave out to QT for doing 30 years ago. But at least it’s standardised this time?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: