[tialaramex]

Type inference is actually very useful you just need to have the right amount, too little and most of your time is spent on bureaucracy, too much and the software is incomprehensible.

In both Rust and C++ we need this because we have unnameable types, so if their type can't be inferred (in C++ deduced) we can't use these types at all.

In both languages all the lambdas are unnameable and in Rust all the functions are too (C++ doesn't have a type for functions themselves only for function pointers and we can name a function pointer type in either language)

[0xcafecafe]

Another place where auto can be useful is to handle cases where the function signature changes without making changes at the calling site. An explicitly typed var would need changing or worse, can work with some potential hidden bugs due to implicit type conversion.

[1718627440]

This is one of the things static typing is supposed to prevent in the first place. It seems like a lot of people actually want a dynamically typed language, but try to change a static language instead.

[1718627440]

> C++ doesn't have a type for functions themselves only for function pointers

C has this, so I think C++ has as well. You can use a typedef'ed function to declare a function, not just for the function pointer.

[gpderetta]

Same in C++. You can't do much with the function type itself as there are no objects with that type, but you can create references and pointers to it.

[1718627440]

But

    typedef void * (type) (void * args);

    type foo;

    a = foo (b);

works?

[meindnoch]

Those are function pointers. Your parent was referring to the function type. Per ISO/IEC 9899:TC3:

A function type describes a function with specified return type. A function type is characterized by its return type and the number and types of its parameters. A function type is said to be derived from its return type, and if its return type is T , the function type is sometimes called ‘‘function returning T’’. The construction of a function type from a return type is called ‘‘function type derivation’’.

[1718627440]

Not necessarily, foo can also just be an ordinary function. That was my point.

> Per ISO/IEC 9899:TC3:

What is it supposed to tell me?

[tialaramex]

ISO/IEC 9899 is the name of the ISO document describing the C programming language. The current edition is, I think the 2023 document aka C23.

You can read a "draft" of that document here: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf

[If you've ever been under the impression that "real" people use the actual ISO text, disabuse yourself of that notion, ISO takes ages to turn the same exact words into an official branded document, then charges $$$ for a PDF, ain't nobody got time or money for that]

I can't tell you what they intended by TC3. It might be a typo or it might be some way to refer to a specific draft or a section within that draft. I doubt this particular section changes frequently so I wouldn't worry about it.

[gpderetta]

This is true, in both C++ and C, you can use a function type to declare (but not define) a function! This pretty much never comes up and I forgot.

edit: you literally said this in your original comment. I failed at reading comprehension.

[1718627440]

> This pretty much never comes up

I regularly use that in C, to make sure a function matches an abstract interface. Sure, that often ends up in a function pointer, but not always and when I declare the type signature, it isn't yet a function pointer.

> but not define

I think that is because the type signature only contains the types, but no parameter names, which are required for a definition. This is arbitrary, since for data types, the member names are part of the type. It sounds totally fixable, but then you either have two types of function types, one where all parameter names are qualified and one where they aren't and only could use the former for function definitions. Or you would make names also mandatory for function declarations.

[gpderetta]

Interesting use case.

> It sounds totally fixable, but then you either have two types of function types, one where all parameter names are qualified and one where they aren't and only could use the former for function definitions

Making the names part of the type would be a bit weird, although we have seen stranger things. The biggest problem is that it would be a breaking change at least in C++.