overuse of auto is dangerous

[jacobnavia]

Consider:

auto f = foo();

What is "f"?

Ahhh you have to figure out the return type of foo() of course. Great,
there you go to your favorite IDE and try to jump to the correct
definition of the foo() method in the correct class with the correct
overload resolution...

Even worst... when you change the return type of foo() from type A to
type Z, all the "auto" constructs will continue to compile AUTOmatically
of course. Problem is, the type of "f" will have changed and that can
provoke incomprehensible compile time errors further down or even run
time errors in the form of access violation or whatever!

Wouldn't it be better to write:

TYPE_A F = foo();

????

If the return type of foo() changes, an easy to catch compile time error
will inform us that a change happened and that we have to revise the
code according to the new interface of foo().

Besides, the maintenance programmer doesn't need to figure out anything:
the type of "f" is there, for all to see.

WATCH THAT AUTO!

[Jorgen Grahn]

On Thu, 2020-03-12, jacobnavia wrote:
> Consider:
>
> auto f = foo();

...

> Wouldn't it be better to write:
>
> TYPE_A F = foo();
>
> ????

Yes, sometimes. "How often should we use auto?" is a question that
has been discussed here several times. (By people who actually use
C++, want to use C++, and want to do it well.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Ian Collins]

On 13/03/2020 12:27, jacobnavia wrote:

Overuse of ice cream is dangerous but we still use it...

WATCH THAT ICE CREAM!

--
Ian.

[Cholo Lennon]

On 3/12/20 8:27 PM, jacobnavia wrote:
> Consider:
>
> auto f = foo();
>
> What is "f"?
>
> Ahhh you have to figure out the return type of foo() of course. Great,
> there you go to your favorite IDE and try to jump to the correct
> definition of the foo() method in the correct class with the correct
> overload resolution...
>
> Even worst... when you change the return type of foo() from type A to

I am completely agree with you. In my previous job I had the opportunity
to work with a very large C++14/17 project (EOS/WAX blockchains). The
temptation to use "auto" everywhere was big: easy to start using it, by
later I discovered that it was very awful to read and use the code,
especially when you don't have a good IDE (but surprise surprise, even
the good IDEs have serious problems with auto).

--
Cholo Lennon
Bs.As.
ARG

[Daniel]

On Thursday, March 12, 2020 at 8:57:31 PM UTC-4, Ian Collins wrote:
> On 13/03/2020 12:27, jacobnavia wrote:
>
> Overuse of ice cream is dangerous but we still use it...
>

Indeed, but it would be nice if it _could_ be used safely everywhere,
irrespective of whether we chose to use it. But it can't, it doesn't work when
functions return proxies.

Daniel

[Bo Persson]

On 2020-03-13 at 00:27, jacobnavia wrote:
> Consider:
>
> auto f = foo();
>
> What is "f"?

Easy, "f" is the return value of foo(). Probably some kind of iterator
that you are just going to pass to one or more std::algorithm, so you
don't really care to spell out its name.

>
> Ahhh you have to figure out the return type of foo() of course. Great,
> there you go to your favorite IDE and try to jump to the correct
> definition of the foo() method in the correct class with the correct
> overload resolution...
>
> Even worst... when you change the return type of foo() from type A to
> type Z, all the "auto" constructs will continue to compile AUTOmatically
> of course. Problem is, the type of "f" will have changed and that can
> provoke incomprehensible compile time errors further down or even run
> time errors in the form of access violation or whatever!
>
> Wouldn't it be better to write:
>
> TYPE_A F = foo();

You mean like

typename std::unordered_map<key, data, std::hash<key>,
std::equal_to<key>, special_allocator<std::pair<const key,
data>>>::const_iterator F = foo();


Bo Persson

[Ian Collins]

Ice cream always works!

--
Ian.

[Daniel]

On Thursday, March 12, 2020 at 11:17:55 PM UTC-4, Ian Collins wrote:
>
> Ice cream always works!
>
Just so.

[jacobnavia]

Well, I know that C++ can be very unreadable. Maintaining C++ can be a
nightmare, but yes, I would prefer that long declaration since I know
that at the end f should be a const_iterator (if I parsed that correctly
from the template forest there).

[Öö Tiib]

That seems to be one of main annoyances with C++. Compiler diagnostics,
debuggers and smart code editors will talk something like that about
generically constructed types used.

So I usually suggest to be helpful by using typedefs when constructing
such types:

using KeyData = std::pair<const Key, Data>;
using KeyDataAlloc = special_allocator<KeyData>;
using MapKeyToData = std::unordered_map<Key, Data, std::hash<Key>
, std::equal_to<Key>, KeyDataAlloc>;

Same way MapKeyToData::const_iterator can be declared if it is
type of important citizens in code. Then that "poo" can be declared as;

MapKeyToData::const_iterator poo();

Going "auto poo();" here feels already deliberate waste of readers time
even when the usual "poo" has more descriptive name.
Now that voids your example since the question becomes between:

auto p = poo();

MapKeyToData::const_iterator p = poo();

It can be clear enough with auto and also lot of code viewing tools
let to one-click navigate to declaration of that "poo" when unsure.

[David Brown]

What is the point you are trying to make with these posts? That
features which are useful can also be misused? Welcome to reality -
this is nothing new, either in programming languages or any other aspect
of life.

Drinking a glass of water is a good idea. Sticking your head in a
bucket of water is a really bad idea. Appropriate use of something is
good, excessive use or abuse is bad. The same applies to using auto,
structured bindings, C macros, "if" statements, or Usenet.

If you don't like C++, don't use it. If you don't want to support it in
your tools, that's fine (and understandable - it would be a massive
effort). If you don't understand C++ or the purpose of its features
(this is apparent from your posts), either ask about it or drop it. But
please stop whining.

[Bart]

On 13/03/2020 10:07, David Brown wrote:
> On 13/03/2020 00:27, jacobnavia wrote:
>> Consider:
>>
>> auto f = foo();
>>
>> What is "f"?
>>
>> Ahhh you have to figure out the return type of foo() of course. Great,
>> there you go to your favorite IDE and try to jump to the correct
>> definition of the foo() method in the correct class with the correct
>> overload resolution...
>>
>> Even worst... when you change the return type of foo() from type A to
>> type Z, all the "auto" constructs will continue to compile AUTOmatically
>> of course. Problem is, the type of "f" will have changed and that can
>> provoke incomprehensible compile time errors further down or even run
>> time errors in the form of access violation or whatever!
>>
>> Wouldn't it be better to write:
>>
>> TYPE_A F = foo();
>>
>> ????
>>
>> If the return type of foo() changes, an easy to catch compile time error
>> will inform us that a change happened and that we have to revise the
>> code according to the new interface of foo().
>>
>> Besides, the maintenance programmer doesn't need to figure out anything:
>> the type of "f" is there, for all to see.
>>
>> WATCH THAT AUTO!
>>
>
> What is the point you are trying to make with these posts?

Frustration with the way this spectacularly complex language is going?

> If you don't like C++, don't use it. If you don't want to support it in
> your tools, that's fine (and understandable - it would be a massive
> effort). If you don't understand C++ or the purpose of its features
> (this is apparent from your posts), either ask about it or drop it. But
> please stop whining.

The consequences can perculate through even if you don't use the language.

I've experienced that extensively with C. Much less so with C++ but
largely because I don't even bother trying to use libraries with C++
interfaces, or trying to port or understand bits of software written in
C++, or attempting to build any open source code that uses C++.

Even using C, if someone wants to make use of VS for example, that IDE
is heavily C++-centric.

However it is fascinating seeing how the language is developing, how it
is totally incapable of taking a simple, straightforward approach to
anything. Rule number one: every new feature must be arcane.

[Paavo Helde]

On 13.03.2020 1:27, jacobnavia wrote:
> Consider:
>
> auto f = foo();
>
> What is "f"?

Right, with a non-informative name like 'foo' auto should probably not
be used. Auto should be used only if it increases readability:

for (auto& ref: mycontainer) {/*...*/}

auto myThread = std::make_unique<std::thread>(MyThreadFunc, par1, par2);

etc.

[David Brown]

If you don't like a language, don't use it. If you don't know a
language, either learn about it or keep quite about it - it is pointless
to come to a language forum and complain about it.

I know only a little Ruby - but from what I have seen, it is an
unusually ugly and unclear language. I have three choices. First, I
could just ignore it and use other languages. Second, I could put the
effort into studying it, learning it, writing code in it, and see if it
has advantages that outweigh my initial bad impression - after all, a
great many other people choose to use it. Or third, I could go to a
Ruby Usenet group and grumble about how terrible I think it is. Which
do you think is the smart choice?

With C, there is at least the vague excuse that as the lingua franca of
the software world, you often can't get entirely away from it even if
you don't like it. That does not apply to C++.

>
>> If you don't like C++, don't use it.  If you don't want to support it in
>> your tools, that's fine (and understandable - it would be a massive
>> effort).  If you don't understand C++ or the purpose of its features
>> (this is apparent from your posts), either ask about it or drop it.  But
>> please stop whining.
>
> The consequences can perculate through even if you don't use the language.
>
> I've experienced that extensively with C. Much less so with C++ but
> largely because I don't even bother trying to use libraries with C++
> interfaces, or trying to port or understand bits of software written in
> C++, or attempting to build any open source code that uses C++.
>
> Even using C, if someone wants to make use of VS for example, that IDE
> is heavily C++-centric.
>
> However it is fascinating seeing how the language is developing, how it
> is totally incapable of taking a simple, straightforward approach to
> anything. Rule number one: every new feature must be arcane.
>

Some things in C++ are hard to understand. But it is orders of
magnitude harder to understand how some people have such a hatred for
things they are basically clueless about as a result of determined
wilful ignorance.

[Daniel]

On Friday, March 13, 2020 at 6:07:33 AM UTC-4, David Brown wrote:
> On 13/03/2020 00:27, jacobnavia wrote:
> >
>
> If you don't like C++, don't use it.

On the contrary, jacobnavia has no reason to leave C++. jacobnavia is happy
with legacy C++, their unhappiness is related to an ISO standards committee
that is not limiting itself to standardizing existing practice, but seemingly
trying to morph it into a new language. But jacobnavia will always have
backwards compatible legacy C++.

It's those of us that _want_ C++ to become a modern language, and have
reservations where that's going, that have to also think about leaving. But
where to?

Daniel

[Mr Flibble]

auto is great: use almost everywhere .. with concepts it will be even better:

iterator i = foo();

/Flibble

--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."

[Alf P. Steinbach]

What's wrong with bacon?

- Alf

[Bonita Montero]

> typename std::unordered_map<key, data, std::hash<key>,
> std::equal_to<key>, special_allocator<std::pair<const key,
> data>>>::const_iterator F = foo();

Takes 20s to read, but auto is even more unreadable.

[Daniel]

Could be a proxy, vegan bacon, same interface, but ...

Daniel

[Jorgen Grahn]

On Fri, 2020-03-13, Daniel wrote:
> On Friday, March 13, 2020 at 6:07:33 AM UTC-4, David Brown wrote:
>> On 13/03/2020 00:27, jacobnavia wrote:
>> >
>>
>> If you don't like C++, don't use it.
>
> On the contrary, jacobnavia has no reason to leave C++. jacobnavia is happy
> with legacy C++,

That's not my impression at all.

> their unhappiness is related to an ISO standards committee
> that is not limiting itself to standardizing existing practice, but seemingly
> trying to morph it into a new language. But jacobnavia will always have
> backwards compatible legacy C++.
>
> It's those of us that _want_ C++ to become a modern language, and have
> reservations where that's going, that have to also think about leaving. But
> where to?

Stick to C++11, with the idioms you believe in. Cherry-pick the good
features from later standards. Don't join teams which value novelty
higher than getting things done.

[Sam]

jacobnavia writes:

> Consider:
>
> auto f = foo();
>
> What is "f"?

Who cares.

[Melzzzzz]

Rust.
>
> Daniel


--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[Bonita Montero]

Is there any IDE that can expand an auto to the usual declarations ?

[jacobnavia]

Le 13/03/2020 à 14:26, David Brown a écrit :
> If you don't like a language, don't use it. If you don't know a
> language, either learn about it or keep quite about it - it is pointless
> to come to a language forum and complain about it.

Well, as a user of comp.lang.c I have been reading about the problems
with C by C++ heads since YEARS. They come to comp.lang.c to tell us how
bad C is and how good C++ is with various arguments. We listen politely
and answer them how do you do that in C, for instance when they say "C
is lacking xxx"

I haven't seen answers like "If you do not like C do not use it and go
away".

In this particular thread I am asking about your awareness about "auto"
misfeatures and we seemed to agree that are problems with it.

I am not saying that C++ is a pile of shit or even that this construct
should be taken away... I am pointing to the problems with it in the
following context:

Many of the new features added to C++ aren't well THOUGHT OUT and
provoke more problems than the ones they try to solve!

This is precisely why I think that continuing to add features each 3
years to an already highly complex language is a recipe for DISASTER!

I singled out two of them: structured binding and auto but there are
many more. Is it still possible to change the way the committee is working?

Instead of cheap polemic could you (maybe) reflect about that and
express your opinion about that?

[Öö Tiib]

On Saturday, 14 March 2020 06:53:39 UTC+2, Melzzzzz wrote:
> On 2020-03-13, Daniel <daniel...@gmail.com> wrote:
> > On Friday, March 13, 2020 at 6:07:33 AM UTC-4, David Brown wrote:
> >> On 13/03/2020 00:27, jacobnavia wrote:
> >> >
> >>
> >> If you don't like C++, don't use it.
> >
> > On the contrary, jacobnavia has no reason to leave C++. jacobnavia is happy
> > with legacy C++, their unhappiness is related to an ISO standards committee
> > that is not limiting itself to standardizing existing practice, but seemingly
> > trying to morph it into a new language. But jacobnavia will always have
> > backwards compatible legacy C++.
> >
> > It's those of us that _want_ C++ to become a modern language, and have
> > reservations where that's going, that have to also think about leaving. But
> > where to?
>
> Rust.

What is the chance that when Rust ever gets out of kindergarten it won't
be spoiled by "contributors" from monster companies as well? These
companies have plenty of money to sabotage anything.

[Melzzzzz]

On 2020-03-14, Bonita Montero <Bonita....@gmail.com> wrote:
> Is there any IDE that can expand an auto to the usual declarations ?

VS?

[Melzzzzz]

So far, Rust eliminated lot of things from original language. From qutie
to monster. But it is ok so far. ML features are what is great about it
and they got right with error handling. Also proper `move` built into
language (destructors not get called after move and compiler errors if
one try to access them)

[Sam]

jacobnavia writes:

> Many of the new features added to C++ aren't well THOUGHT OUT and provoke
> more problems than the ones they try to solve!

There are some like that, I do believe. But they're none of the ones you're
having a cow about.

[David Brown]

On 14/03/2020 09:20, jacobnavia wrote:
> Le 13/03/2020 à 14:26, David Brown a écrit :
>> If you don't like a language, don't use it.  If you don't know a
>> language, either learn about it or keep quite about it - it is pointless
>> to come to a language forum and complain about it.
>
> Well, as a user of comp.lang.c I have been reading about the problems
> with C by C++ heads since YEARS. They come to comp.lang.c to tell us how
> bad C is and how good C++ is with various arguments. We listen politely
> and answer them how do you do that in C, for instance when they say "C
> is lacking xxx"

So you think two wrongs makes a right? There are a few people who post
regularly in c.l.c. about how bad or pointless C is, and why C++ or
their own made-up language is vastly better. These kinds of posts are
as annoying as posts in c.l.c++ about how bad C++ is. (It's one thing
to discuss particular features, or to question the wisdom of current
language directions - that's different from wide-ranging rants about how
impossibly complicated the language is and other such posts.)

No, you don't have to listen politely to people complaining about C in
c.l.c. You can ignore them, point out their mistakes, or ask them to
stop pointless posts. (Again, there is nothing wrong with discussing a
language or its features pros and cons.)

>
> I haven't seen answers like "If you do not like C do not use it and go
> away".

Such answers are not uncommon - I don't know how you missed them.

For most people, in most circumstances, there are choices about the
tools and languages they use. Occasionally as professional programmers,
we have to work with languages we don't like, but if it is a long term
issue, it would be better to try to change jobs (or change things at
your current job) than to complain to innocent bystanders in a newsgroup.

>
> In this particular thread I am asking about your awareness about "auto"
> misfeatures and we seemed to agree that are problems with it.

I think everyone can see that it is a feature with advantages and
disadvantages. Use it appropriately, and don't use it inappropriately.
The same could be said of pretty much every feature of every language.

>
> I am not saying that C++ is a pile of shit or even that this construct
> should be taken away... I am pointing to the problems with it in the
> following context:
>
> Many of the new features added to C++ aren't well THOUGHT OUT and
> provoke more problems than the ones they try to solve!

I think you are wrong. Some features have, in hindsight, had unexpected
and unforeseen issues. But that is not common, and not from lack of
thought or effort. More directly, however, I think you are not in a
position to make a reasonable judgement - much less make the kind of
absolute condemnations you write. Instead of emotive posts full of
capitals, exclamation marks, and accusations of incompetence in the C++
committee, perhaps you could ask other people where the find it useful,
and where they see it as counter productive.

In fact, /asking/ people and listening to them, rather than making
declarations from a position of ignorance or prejudice, is generally a
good idea.

>
> This is precisely why I think that continuing to add features each 3
> years to an already highly complex language is a recipe for DISASTER!
>
> I singled out two of them: structured binding and auto but there are
> many more. Is it still possible to change the way the committee is working?
>
> Instead of cheap polemic could you (maybe) reflect about that and
> express your opinion about that?

I haven't made use of structured bindings as yet. I see it as a
somewhat convenient way to get multiple return values from functions.
However, it is not ideal for me - I would prefer a method that named the
parts, as it is too easy to get the order wrong. (For the same reason,
I am disappointed that C++ still has not got named parameters in
function calls.)

auto foo(int x, int y) {
struct { int sum; int prod; } r;

r.sum = x + y;
r.prod = x * y;

return r;
}

int bar(int x, int y) {
auto r = foo(x, y);
return r.prod / r.sum;
}

int bar2(int x, int y) {
auto [prod, sum] = foo(x, y);
return prod / sum;
}

The "auto" in "foo" and "bar" makes the code a lot simpler and shorter,
and saves providing a name for the multi-value return type. This is a
good thing, and a good use of "auto" (IMHO, of course). "bar2" uses
structured bindings, and shows the kind of subtle mistake that is easily
made here. (Unlike some of the mistakes you discussed about structured
bindings, this mistake compiles fine so you get no help from the tools.)

However, AFAIK C++ currently gives no way to use such anonymous struct
return types in functions with separate definitions and declarations.

[Öö Tiib]

On Saturday, 14 March 2020 15:20:46 UTC+2, Melzzzzz wrote:
> On 2020-03-14, Öö Tiib <oot...@hot.ee> wrote:
> > On Saturday, 14 March 2020 06:53:39 UTC+2, Melzzzzz wrote:
> >> On 2020-03-13, Daniel <daniel...@gmail.com> wrote:
> >> > On Friday, March 13, 2020 at 6:07:33 AM UTC-4, David Brown wrote:
> >> >> On 13/03/2020 00:27, jacobnavia wrote:
> >> >> >
> >> >>
> >> >> If you don't like C++, don't use it.
> >> >
> >> > On the contrary, jacobnavia has no reason to leave C++. jacobnavia is happy
> >> > with legacy C++, their unhappiness is related to an ISO standards committee
> >> > that is not limiting itself to standardizing existing practice, but seemingly
> >> > trying to morph it into a new language. But jacobnavia will always have
> >> > backwards compatible legacy C++.
> >> >
> >> > It's those of us that _want_ C++ to become a modern language, and have
> >> > reservations where that's going, that have to also think about leaving. But
> >> > where to?
> >>
> >> Rust.
> >
> > What is the chance that when Rust ever gets out of kindergarten it won't
> > be spoiled by "contributors" from monster companies as well? These
> > companies have plenty of money to sabotage anything.
>
> So far, Rust eliminated lot of things from original language. From qutie
> to monster. But it is ok so far. ML features are what is great about it
> and they got right with error handling. Also proper `move` built into
> language (destructors not get called after move and compiler errors if
> one try to access them)

You misunderstood my question. Lets say Rust becomes mature enough
to be useful enough so some shops start to write real software in it.
What stops all those googles, amazons, microsofts, ibms, oracles and
apples to form intermonsternational standardization committee of
wormtongues and to screw it into oblivion within a decade like
with C++?

[Bart]

Does C++ still need declarations of such functions when the definition
itself is not visible? If so, what would they look like?

What I'm getting at is that such a return type will need to be known at
the call-site, at least the number and types of the multiple values.

Also I can't see that 'auto' helps that much here, since you will still
need to know the number of return values, if not their types.

(Your proposal also seems to allow multiple, nested return values, which
IMO is not useful and complicates matters. That would be better as a
single compound type.)

  This is a
> good thing, and a good use of "auto" (IMHO, of course).  "bar2" uses
> structured bindings, and shows the kind of subtle mistake that is easily
> made here.  (Unlike some of the mistakes you discussed about structured
> bindings, this mistake compiles fine so you get no help from the tools.)

C, and I assume C++, allows this:

void fn(int sum, int prod);
void fn(int prod, int sum) {....}

If only the declaration is visible at the call-site, it will be misleading.

> However, AFAIK C++ currently gives no way to use such anonymous struct
> return types in functions with separate definitions and declarations.

OK, you seem to have answered my point above...

>
> So you think two wrongs makes a right? There are a few people who post
> regularly in c.l.c. about how bad or pointless C is, and why C++ or
> their own made-up language is vastly better.

It might worth listening to such people when their made-up (but actual,
not imaginary) language has long had features such as multiple return
types, default parameter values and keyword arguments. And that sum/prod
mixup is not possible.

Example after sig.

--
function foo(int x,y)int,int =
return (x+y, x*y)
end

Call using (sum, prod) := foo(a,b). foo can be in a different module; no
declaration needed, only an 'import' statement in call-module.

Based on your proposal, I might allow the multiple return parts to be
named (currently only possible for single return values):

function foo(int x,y)int sum, prod =
sum := x+y
prod := x*y
return (sum, prod)
end

'sum' and 'prod' will be regular local variables.

[David Brown]

There is no way to declare such functions. (Unless it can be done with
modules - I am not familiar enough with them yet.) So you'd need to
declare the return type, with a name, then use that to declare the
function - just as you would with C.

C++ makes it easier to have such declarations in header files, however,
and ensures that if the function is generated separately rather than
being expanded inline, you only have one copy in the final linked program.

(Yes, having the definitions of functions in headers makes compilation
slower, and yes, speed of compilation of C++ files /is/ a big issue,
unlike for C. On the other hand, you can often distribute C libraries
as just header files rather than header + implementation pairs. And
modules will improve build times significantly.)

>
> What I'm getting at is that such a return type will need to be known at
> the call-site, at least the number and types of the multiple values.
>

Yes, exactly.

> Also I can't see that 'auto' helps that much here, since you will still
> need to know the number of return values, if not their types.

Functions with "auto" return type (and no trailing return type) have
their real return types inferred by the compiler when it sees their
definition. So you can't declare them in advance. But for a lot of
functions, there is only one "return" statement and you let the compiler
do the work for you.

Use of inferred types is, if you like, a higher level feature. It is
not always the right choice, and it is not always possible. You use
inferred types when you are most interested in features of the type,
rather than details of the implementation, or when you only want to
assign it once.

For example, if you write "auto x = foo();", then you know "x" is of a
type that can hold any value that foo() might return. But if you then
go on to write "x += 1;", you might not know if that is valid - perhaps
the type of "x" is "int" and this overflows, and you really wanted to
write "unsigned int x = foo();".

"auto" really comes in handy when dealing with generic functions
(templated functions or concept functions), or when you have complicated
types that you don't want to have to write out manually.

"auto" makes it easier to write some kinds of code error-free, and also
makes it easier to make other kinds of errors. It is a helpful feature
but not a magic feature.

>
> (Your proposal also seems to allow multiple, nested return values, which
> IMO is not useful and complicates matters. That would be better as a
> single compound type.)

My example above (foo and bar) is giving a single compound return. You
can do that in C too, but you have to be more verbose and explicit.
That can be a good thing and a bad thing - there are no absolutes here.
(I can't stress that enough.)

>
>   This is a
>> good thing, and a good use of "auto" (IMHO, of course).  "bar2" uses
>> structured bindings, and shows the kind of subtle mistake that is
>> easily made here.  (Unlike some of the mistakes you discussed about
>> structured bindings, this mistake compiles fine so you get no help
>> from the tools.)
>
> C, and I assume C++, allows this:
>
>    void fn(int sum, int prod);
>    void fn(int prod, int sum) {....}
>
> If only the declaration is visible at the call-site, it will be misleading.

Yes. That is one thing I strongly dislike about the languages, and it
is a big hinder to having a simple system of named parameters. However,
it is also clear that there are some /good/ reasons for allowing
different names for parameters.

>
>> However, AFAIK C++ currently gives no way to use such anonymous struct
>> return types in functions with separate definitions and declarations.
>
> OK, you seem to have answered my point above...

With luck, someone will answer it differently, and I'll learn something
useful!

>
> >
> > So you think two wrongs makes a right?  There are a few people who post
> > regularly in c.l.c. about how bad or pointless C is, and why C++ or
> > their own made-up language is vastly better.
>
> It might worth listening to such people when their made-up (but actual,
> not imaginary) language has long had features such as multiple return
> types, default parameter values and keyword arguments. And that sum/prod
> mixup is not possible.

Sometimes comparisons between languages are useful, yes. Endless "/my/
language is so much better" posts are not. There is a difference.

>
> Example after sig.
>

Put things before the signature if they are useful (even if they are not
in the language of the group) - otherwise they get snipped.

[Bonita Montero]

> If you don't like a language, don't use it.

You can use the language not only in one way. And auto can make the
code less readable for those who've not written the code. I use it
only if absolutely necessary.

[Keith Thompson]

David Brown <david...@hesbynett.no> writes:
> On 14/03/2020 18:23, Bart wrote:

[...]

>> C, and I assume C++, allows this:
>>
>>    void fn(int sum, int prod);
>>    void fn(int prod, int sum) {....}
>>
>> If only the declaration is visible at the call-site, it will be misleading.
>
> Yes. That is one thing I strongly dislike about the languages, and it
> is a big hinder to having a simple system of named parameters.
> However, it is also clear that there are some /good/ reasons for
> allowing different names for parameters.

[...]

Good reasons for using a different name for the same parameter in a
declaration and definition of a function? I can't think of any.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Ian Collins]

On 16/03/2020 11:41, Keith Thompson wrote:
> David Brown <david...@hesbynett.no> writes:
>> On 14/03/2020 18:23, Bart wrote:
> [...]
>>> C, and I assume C++, allows this:
>>>
>>>    void fn(int sum, int prod);
>>>    void fn(int prod, int sum) {....}
>>>
>>> If only the declaration is visible at the call-site, it will be misleading.
>>
>> Yes. That is one thing I strongly dislike about the languages, and it
>> is a big hinder to having a simple system of named parameters.
>> However, it is also clear that there are some /good/ reasons for
>> allowing different names for parameters.
> [...]
>
> Good reasons for using a different name for the same parameter in a
> declaration and definition of a function? I can't think of any.

I was thinking along the same lines. As C++ gets more Python like,
there are some really useful Python features that get left out..

--
Ian.

[Jorgen Grahn]

Stroustrup wrote about that in "Design and Evolution ..." -- named
parameters had been requested more than 25 years ago. I don't
remember his arguments for not having them, but he had them. Of
course things may have changed since then.

[David Brown]

On 15/03/2020 23:41, Keith Thompson wrote:
> David Brown <david...@hesbynett.no> writes:
>> On 14/03/2020 18:23, Bart wrote:
> [...]
>>> C, and I assume C++, allows this:
>>>
>>>    void fn(int sum, int prod);
>>>    void fn(int prod, int sum) {....}
>>>
>>> If only the declaration is visible at the call-site, it will be misleading.
>>
>> Yes. That is one thing I strongly dislike about the languages, and it
>> is a big hinder to having a simple system of named parameters.
>> However, it is also clear that there are some /good/ reasons for
>> allowing different names for parameters.
> [...]
>
> Good reasons for using a different name for the same parameter in a
> declaration and definition of a function? I can't think of any.
>

First, let me note that I personally would prefer that parameters in
declarations and definitions had to match, and that the benefits (even
excluding the ease with which named parameters could be added to the
language) outweigh the cases where a difference is perhaps useful. And
I am careful to be consistent in my own code. So these are reasons
other people have.

Parameter names can come in conflict with macros. In particular, system
headers will often have parameter names that use implementation
namespace to avoid conflict:

extern void *memset(void *__s, int __c, size_t __n)

It is perfectly allowed to write:

#define s 1234
#define c 5678;
#define n Humpty Dumpty
#include <string.h>

So the declaration in <string.h> can't use "s, c, n" as the parameters.
However, it is reasonable that the person implementing the function
would want more normal parameter names, and that is what you find in
library implementations.


Sometimes you have a more generic function type, with generic names, but
want specific names in specific implementations:

typedef int (*callback_f)(int id, void * params);

int got_new_name(int id, void * name) { ... }

Sometimes you want to leave a parameter without a name, to indicate that
it is not used - but you need to name it in a C definition of the function.


There are easy ways to get around all of these, such as:

int got_new_name(int id, void * params) {
const char * name = params;

...
}

I have read other reasons, but can't recall them at the moment - there
have been a number of proposals for adding named parameters to C++ that
all come up against these issues.

Certainly there are plenty of cases in real world code where parameter
names don't match between definitions and declarations, and that always
makes it hard to change.

[Sam]

I think you can get pretty close to named arguments (even if you don't
really want to) as long as you have flexible fingers that don't mind a lot
of practice.

Start with a helper template:

template<typename name_t, value_t> struct arg : public value_t {

typedef value_t value_type;

using value_t::value_t;
};

And then define your placeholder classes.

struct name;
struct age;

Your argument names are:

arg<name, std::string>, arg<age, int>

All your functions are now variadic templates that construct a helper class
and then invoke the real function (or method):

void to_you(function_args<arg<name>, arg<age>>);

template<typename ...Args> void happy_birthday(Args && ...args)
{
to_you({std::forward<Args>(args)...});
}

The calling sequence would be:

happy_birthday( name{"Frodo"}, age{120} );

function_args seems to be straightforward (on the C++ scale): a template
whose parameters must all be specializations of arg<>, and with a variadic
constructor that walks through each one of its parameters, one by one, and
constructs them, and provide a structured binding-compatible interface so
that to_you() can simply:

void to_you(function_args<arg<name>, arg<age>> my_args);
{
auto &[name, age} = my_args;
}

Probably the most nastiest aspect of this would be to have each individual
template not participate in overload resolution, unless its parameters are
constructible for the function_args. I heard that something like "concepts"
might help with that…

[Jorgen Grahn]

I got bored so I dug it out -- section 6.5.1. There was a working
proposal for keyword arguments, by Roland Hartinger, in the
1980s. Stroustrup presents a number of problems (one relating to
the one above) but for himself the main objection seemed to be:

"Would it be sensible to introduce a new feature that primarily
supported programming styles that we would prefer to see decline?"

Meaning functions with tons of parameters, instead of one or two more
refined parameters.

Perhaps the current proposal addresses this; I haven't read it.

[David Brown]

Without going into detail of this method, it is certainly fair to say
there are a variety of different ways to get sort-of named parameters.
These include such template solutions (which concepts can improve),
having a struct for the the parameters, having partial functions with
chains "happy_birthday().name("Frodo").age(120);", and various other
solutions. None are good - they are all ugly and wordy compared to an
obvious "happy_birthday(name : "Frodo", age : 120);" or similar. None
allow you to have a function that can be used with named parameters or
placement parameters, none play well with optional or default
parameters. Many will have lower efficiency or hinder optimisations.

[Bart]

On 16/03/2020 08:11, David Brown wrote:
> On 15/03/2020 23:41, Keith Thompson wrote:

>> Good reasons for using a different name for the same parameter in a
>> declaration and definition of a function?  I can't think of any.

> Parameter names can come in conflict with macros.  In particular, system
> headers will often have parameter names that use implementation
> namespace to avoid conflict:
>
>     extern void *memset(void *__s, int __c, size_t __n)
>
> It is perfectly allowed to write:
>
>     #define s 1234
>     #define c 5678;
>     #define n Humpty Dumpty
>     #include <string.h>
>
> So the declaration in <string.h> can't use "s, c, n" as the parameters.

There's something very wrong then.

Parameter names are supposed to live in their own scope, which in a
function definition extends to the body of the function.

It also makes it impossible to use ANY identifier, since someone could
have used it for some macro. Or even any keyword, as someone could write
'#define if 1234'.

It would anyway make keyword parameters look very ugly if all those
double underlines are going to end up in user code.

> It is perfectly allowed to write:
>
> #define s 1234
> #define c 5678;
> #define n Humpty Dumpty

So whose job is it to say DON'T DO THIS - language, compiler or
guidelines? And aren't macro names supposed to be in capitals?

> Sometimes you have a more generic function type, with generic names, but
> want specific names in specific implementations:
>
>     typedef int (*callback_f)(int id, void * params);
>
>     int got_new_name(int id, void * name) { ... }
>
> Sometimes you want to leave a parameter without a name, to indicate that
> it is not used - but you need to name it in a C definition of the function.
>
>
> There are easy ways to get around all of these, such as:
>
>     int got_new_name(int id, void * params) {
>         const char * name = params;
>
>         ...
>     }
>
> I have read other reasons, but can't recall them at the moment - there
> have been a number of proposals for adding named parameters to C++ that
> all come up against these issues.
>
> Certainly there are plenty of cases in real world code where parameter
> names don't match between definitions and declarations, and that always
> makes it hard to change.
>

This an example from a script language of mine from the 1990s (this at
the time also needed separate function declarations and definitions). It
allows a choice of names for certain parameters, when they can be used
in different ways.

All parameters are variant (dynamic), and ? means all are optional.
These functions are intended to be used primarily with keyword arguments:

function gxwindow (?var pos, dim, caption, style$options, owner,
handlers$handler)var

function gxbutton (?var pos, dim, data$caption, style, id, linkvar,
onvalue)var

The '$' separates alternatives. (I no longer use such a feature, and
names now allow $ anyway.) Default values here are assigned inside the
function as missing parameters have value 'void'.

When I use C libraries, I need to write my own sets of bindings, and
then I take the opportunity to use my own names anyway. Here's an
example of defining a C function from WinAPI:

windows proc "MessageBoxA" (int hwnd=0, ichar message,
caption="Caption", int flags=0)

The names used in the official API are hWnd, lpText, lpCaption, uType.

With my approach, I can use this function with both default and keyword
parameters, features that don't exist in the implementation language. I
don't even need to use the exact case:

messageboxa(message:"Hello World")

(Here I would sometimes create an alias 'messagebox', without the final
'a'.)

[Sam]

David Brown writes:

> Without going into detail of this method, it is certainly fair to say there
> are a variety of different ways to get sort-of named parameters. These
> include such template solutions (which concepts can improve), having a
> struct for the the parameters, having partial functions with chains
> "happy_birthday().name("Frodo").age(120);", and various other solutions.
> None are good - they are all ugly and wordy compared to an obvious
> "happy_birthday(name : "Frodo", age : 120);" or similar. None allow you to
> have a function that can be used with named parameters or placement
> parameters, none play well with optional or default parameters. Many will
> have lower efficiency or hinder optimisations.

Keep in mind that range iteration itself is just a shorthand for canned
boilerplate. With the basic implementation in the core C++ library already,
some syntactic sugar will square that away.

[David Brown]

On 16/03/2020 12:44, Bart wrote:
> On 16/03/2020 08:11, David Brown wrote:
>> On 15/03/2020 23:41, Keith Thompson wrote:
>
>>> Good reasons for using a different name for the same parameter in a
>>> declaration and definition of a function?  I can't think of any.
>
>> Parameter names can come in conflict with macros.  In particular,
>> system headers will often have parameter names that use implementation
>> namespace to avoid conflict:
>>
>>      extern void *memset(void *__s, int __c, size_t __n)
>>
>> It is perfectly allowed to write:
>>
>>      #define s 1234
>>      #define c 5678;
>>      #define n Humpty Dumpty
>>      #include <string.h>
>>
>> So the declaration in <string.h> can't use "s, c, n" as the parameters.
>
> There's something very wrong then.
>
> Parameter names are supposed to live in their own scope, which in a
> function definition extends to the body of the function.

Macros are not scoped.

>
> It also makes it impossible to use ANY identifier, since someone could
> have used it for some macro. Or even any keyword, as someone could write
> '#define if 1234'.

Defining macro identifiers that are keywords, or any reserved
identifier, is undefined behaviour in C and C++ (i.e., it's likely that
things will go wrong, and the standards can't guarantee anything).

Like it or not (and I know you don't like it!) that's the way macros in
the preprocessor work in C and C++. It is a reason why more modern
languages don't have a preprocessor of the same kind C and C++ do, and
why modern C and C++ programmers usually avoid macros and the
preprocessor if there are better alternatives.

>
> It would anyway make keyword parameters look very ugly if all those
> double underlines are going to end up in user code.
>
> > It is perfectly allowed to write:
> >
> >      #define s 1234
> >      #define c 5678;
> >      #define n Humpty Dumpty
>
> So whose job is it to say DON'T DO THIS - language, compiler or
> guidelines? And aren't macro names supposed to be in capitals?

Guidelines. (No, macro names are /not/ "supposed to be in capitals".
It is a common guideline, which is often useful - but often used as an
alternative to thinking properly and using good names.)

Every language has ways to write bad code. Does your compiler for your
language complain if you call every function "f1", "f2", "f3", etc., and
name your variables "O", "OO", "OOO", etc. ? I assume not - but if you
were to write a set of guidelines for your language you would ban these
(under a general "use sensible names" rule).


(I'm saying how things are, not how I think they should be. C macros
are extremely useful, and you need to understand them to write good C
and to avoid some kinds of mistakes. It would be nicer if more mistakes
were impossible to make in the language, but C is the way it is.)

[Öö Tiib]

Implementation can name its crap as "_Reasonable_name" not "__r".

And the whole reason that there are macros and so some code is broken
is pointless. Macros are junky feature and so everybody have to keep
their macros at bay and period.

Most attempts to remove or even reduce usage of macros feel to
be sabotaged. Great ideas like ... constexpr, if constexpr or
modules are added in watered down, confusing, limited and full of
unneeded undefined behaviors manner. Plus if there was accidentally
a way to make a feature less useless (even if with using macros!)
then they block that way couple redactions later.

> Sometimes you have a more generic function type, with generic names, but
> want specific names in specific implementations:
>
> typedef int (*callback_f)(int id, void * params);
>
> int got_new_name(int id, void * name) { ... }
>
> Sometimes you want to leave a parameter without a name, to indicate that
> it is not used - but you need to name it in a C definition of the function.

These are weak reasons, use comments or attributes like [[maybe_unused]].

.
> There are easy ways to get around all of these, such as:
>
> int got_new_name(int id, void * params) {
> const char * name = params;
>
> ...
> }
>
> I have read other reasons, but can't recall them at the moment - there
> have been a number of proposals for adding named parameters to C++ that
> all come up against these issues.
>
> Certainly there are plenty of cases in real world code where parameter
> names don't match between definitions and declarations, and that always
> makes it hard to change.

Similar reasoning is that some legacy code may have used something as
name and so there are no way to add keywords into language unless
these are in ugliest dark speech of wormtongues. Huh? Maintain your
legacy code or if you don't have budget then do not upgrade tool-sets.

I still remember how I did decade ago hate those "ovrdecl", "finaldecl",
"hidedecl" and "strictdecl" from n3151. Fortunately there were more
such people so result was half-solution that "override" and "final"
were added with watered down effect, "base_check" and "hiding"
were not added at all and proposed safety usage of "explicit" about
class wasn't also added.
From where comes that dark speech? Logical would be to add "_Hiding"
when oh so afraid to add keyword "hiding". How that "hidedecl" was
reached?

[James Kuyper]

On 3/16/20 4:11 AM, David Brown wrote:
...

> First, let me note that I personally would prefer that parameters in
> declarations and definitions had to match, and that the benefits (even
> excluding the ease with which named parameters could be added to the
> language) outweigh the cases where a difference is perhaps useful. And
> I am careful to be consistent in my own code. So these are reasons
> other people have.
>
> Parameter names can come in conflict with macros. In particular, system
> headers will often have parameter names that use implementation
> namespace to avoid conflict:
>
> extern void *memset(void *__s, int __c, size_t __n)
>
> It is perfectly allowed to write:
>
> #define s 1234
> #define c 5678;
> #define n Humpty Dumpty
> #include <string.h>
>
> So the declaration in <string.h> can't use "s, c, n" as the parameters.

Yes, and that's a problem with a simpler and better solution - in
particular, it can be used by user-defined libraries that can't fall use
identifiers with names reserved to the implementation:

extern void *memset(void *, int, size_t);

There is no mismatch between parameter names in the declaration and in
the definition, for the simple reason that the declaration doesn't have
any parameter names.
You can insert comments rather than parameter names, if you want to
document the meaning of each parameter.

[Bonita Montero]

>> Is there any IDE that can expand an auto to the usual declarations ?

> VS?

VS only supports these tooltips when you fly over an auto. But
it shows the internal types to which the containers are mapped
and not the types you used in the definition / declaration.

[Vir Campestris]

On 13/03/2020 08:14, Öö Tiib wrote:
<snip>
> So I usually suggest to be helpful by using typedefs when constructing
> such types:
>
> using KeyData = std::pair<const Key, Data>;
> using KeyDataAlloc = special_allocator<KeyData>;
> using MapKeyToData = std::unordered_map<Key, Data, std::hash<Key>
> , std::equal_to<Key>, KeyDataAlloc>;
>
> Same way MapKeyToData::const_iterator can be declared if it is
> type of important citizens in code. Then that "poo" can be declared as;
>
> MapKeyToData::const_iterator poo();

</snip>

This is the kind of thing I like. I use auto when I have to:

auto l = []() etc - lambdas have an unknown type

and when the meaning is obvious

auto p = std::make_unique< ...

Otherwise I avoid it. A lot of the time auto simplifies writing code,
but makes reading it harder. And I expect to read it more often than I
write it.

Andy

[Ian Collins]

Those are excellent use cases, the first would be really messy to write
without auto and the second would be needless repetition. As a
guideline, this is pretty much what we follow. Another good use is for
the return value from the likes of std::find.

--
Ian.

[Tim Rentsch]

Keith Thompson <Keith.S.T...@gmail.com> writes:

> David Brown <david...@hesbynett.no> writes:
>
>> On 14/03/2020 18:23, Bart wrote:
>
> [...]
>
>>> C, and I assume C++, allows this:
>>>
>>> void fn(int sum, int prod);
>>> void fn(int prod, int sum) {....}
>>>
>>> If only the declaration is visible at the call-site, it will be misleading.
>>
>> Yes. That is one thing I strongly dislike about the languages, and it
>> is a big hinder to having a simple system of named parameters.
>> However, it is also clear that there are some /good/ reasons for
>> allowing different names for parameters.
>
> [...]
>
> Good reasons for using a different name for the same parameter in a
> declaration and definition of a function? I can't think of any.

Do you think it's possible that, for reasons of their own,
someone would deliberately choose to use a different name for
some function parameter where the function is declared, as
compared to where the function is defined, even though you
can't think of any good reason to do so?

[James Kuyper]

On Thursday, April 2, 2020 at 10:13:17 AM UTC-4, Tim Rentsch wrote:

> Keith Thompson <Keith.S.T...@gmail.com> writes:
...
> > Good reasons for using a different name for the same parameter in a
> > declaration and definition of a function? I can't think of any.
>
> Do you think it's possible that, for reasons of their own,
> someone would deliberately choose to use a different name for
> some function parameter where the function is declared, as
> compared to where the function is defined, even though you
> can't think of any good reason to do so?

There's no inconsistency between that possibility and what Keith said;
people often do things without having a good reason for doing them.

He also only said that he couldn't think of any good reasons - that
wording explicitly allows for the possibility of reasons he couldn't
think of. In fact, his comment could even be interpreted as an
invitation to enlighten him about what such reasons might be. Can
you so enlighten him? If not, there was really no point in
responding.

[Paavo Helde]

On 2.04.2020 17:13, Tim Rentsch wrote:
> Keith Thompson <Keith.S.T...@gmail.com> writes:

>> Good reasons for using a different name for the same parameter in a
>> declaration and definition of a function? I can't think of any.
>
> Do you think it's possible that, for reasons of their own,
> someone would deliberately choose to use a different name for
> some function parameter where the function is declared, as
> compared to where the function is defined, even though you
> can't think of any good reason to do so?

One possible reason would be to clarify a bad parameter name in the
implementation, but to keep the header file unchanged to avoid
"recompiling the world". Not sure if this is a good reason.

[Keith Thompson]

The answer to this deeply uninteresting question is yes.

[Keith Thompson]

James Kuyper <james...@alumni.caltech.edu> writes:
> On Thursday, April 2, 2020 at 10:13:17 AM UTC-4, Tim Rentsch wrote:
>> Keith Thompson <Keith.S.T...@gmail.com> writes:
> ...
>> > Good reasons for using a different name for the same parameter in a
>> > declaration and definition of a function? I can't think of any.
>>
>> Do you think it's possible that, for reasons of their own,
>> someone would deliberately choose to use a different name for
>> some function parameter where the function is declared, as
>> compared to where the function is defined, even though you
>> can't think of any good reason to do so?
>
> There's no inconsistency between that possibility and what Keith said;
> people often do things without having a good reason for doing them.

Or for good reasons that I'm not aware of.

> He also only said that he couldn't think of any good reasons - that
> wording explicitly allows for the possibility of reasons he couldn't
> think of. In fact, his comment could even be interpreted as an
> invitation to enlighten him about what such reasons might be. Can
> you so enlighten him? If not, there was really no point in
> responding.

A bit of background. Much of my programming experience is in Ada,
which allows separate declarations and definitions of functions and
procedures in a manner similar to C and C++. Ada does not allow
parameter names to differ between the declaration and definition
(nor does it allow them to be omitted). I never found that the
least bit inconvenient.

[Tim Rentsch]

James Kuyper <james...@alumni.caltech.edu> writes:

> On Thursday, April 2, 2020 at 10:13:17 AM UTC-4, Tim Rentsch wrote:
>
>> Keith Thompson <Keith.S.T...@gmail.com> writes:
>
> ...
>
>>> Good reasons for using a different name for the same parameter in a
>>> declaration and definition of a function? I can't think of any.
>>
>> Do you think it's possible that, for reasons of their own,
>> someone would deliberately choose to use a different name for
>> some function parameter where the function is declared, as
>> compared to where the function is defined, even though you
>> can't think of any good reason to do so?
>
> There's no inconsistency between that possibility and what Keith said;

That is a true statement.

> people often do things without having a good reason for doing them.

That also is a true statement.

> He also only said that he couldn't think of any good reasons

Not exactly correct, but we can let that slide.

> - that
> wording explicitly allows for the possibility of reasons he couldn't
> think of.

Not correct. It implicitly allows for such a possibility, but
not explicitly.

> In fact, his comment could even be interpreted as an
> invitation to enlighten him about what such reasons might be.

Yes it could. His comment also could be interpreted as
hinting that he thinks there are no good reasons.

> Can you so enlighten him?

AFAIK he isn't seeking enlightenment, and I wouldn't presume
to suppose otherwise.

> If not, there was really no point in responding.

Your purposes are not my purposes.

[David Brown]

He wrote "I can't think of any" - that is explicit in stating the
limitations of his first sentence. Implicit/explicit is not a binary
choice, but a sliding scale, and I personally would judge Keith's
wording to be towards the explicit end here.

>
>> In fact, his comment could even be interpreted as an invitation to
>> enlighten him about what such reasons might be.
>
> Yes it could. His comment also could be interpreted as hinting that
> he thinks there are no good reasons.

I think it was obvious to most people from Keith's wording that he
thought there could at least be reasons (for having different parameter
names) that other people consider "good", even though he may be
sceptical as to whether /he/ would consider them "good".

>
>> Can you so enlighten him?
>
> AFAIK he isn't seeking enlightenment, and I wouldn't presume to
> suppose otherwise.

I am not sure I believe you have this interpretation of what he wrote.
I am wary of accusing you of lying here - that would be a step too far.
But I think you are being deliberately misrepresentative. If you tell
me I am incorrect here, I will accept that.

I think it is obvious to most people that he /was/ looking for
enlightenment - he was inviting anyone with knowledge or examples
contrary to his experience, to share them.

From past experience of your posts, it is likely that you will have
knowledge of situations where people use different parameter names for
reasons that they think are good. And it will many posts, dragged out
over months, before you are persuaded to reveal any.

>
>> If not, there was really no point in responding.
>
> Your purposes are not my purposes.
>

James' purposes appear to me to be mainly about learning and spreading
knowledge, discussing topics he finds interesting and enlightening,
trying to improve the knowledge and understanding of C++ and programming
amongst the followers of this group, and perhaps providing interest and
entertainment for himself and others.

What are your purposes here?