Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #72244 > unrolled thread

overuse of auto is dangerous

Back to article view | Back to comp.lang.c++

Contents

  overuse of auto is dangerous jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-13 00:27 +0100
    Re: overuse of auto is dangerous Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-13 00:27 +0000
    Re: overuse of auto is dangerous Ian Collins <ian-news@hotmail.com> - 2020-03-13 13:57 +1300
      Re: overuse of auto is dangerous Daniel <danielaparker@gmail.com> - 2020-03-12 18:16 -0700
        Re: overuse of auto is dangerous Ian Collins <ian-news@hotmail.com> - 2020-03-13 16:17 +1300
          Re: overuse of auto is dangerous Daniel <danielaparker@gmail.com> - 2020-03-12 20:48 -0700
            Re: overuse of auto is dangerous "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-03-13 21:27 +0100
              Re: overuse of auto is dangerous Daniel <danielaparker@gmail.com> - 2020-03-13 13:35 -0700
    Re: overuse of auto is dangerous Cholo Lennon <chololennon@hotmail.com> - 2020-03-12 22:06 -0300
    Re: overuse of auto is dangerous Bo Persson <bo@bo-persson.se> - 2020-03-13 03:17 +0100
      Re: overuse of auto is dangerous jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-13 08:51 +0100
      Re: overuse of auto is dangerous Öö Tiib <ootiib@hot.ee> - 2020-03-13 01:14 -0700
        Re: overuse of auto is dangerous Vir Campestris <vir.campestris@invalid.invalid> - 2020-03-16 21:35 +0000
          Re: overuse of auto is dangerous Ian Collins <ian-news@hotmail.com> - 2020-03-17 11:49 +1300
      Re: overuse of auto is dangerous Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-13 21:27 +0100
    Re: overuse of auto is dangerous David Brown <david.brown@hesbynett.no> - 2020-03-13 11:07 +0100
      Re: overuse of auto is dangerous Bart <bc@freeuk.com> - 2020-03-13 10:39 +0000
        Re: overuse of auto is dangerous David Brown <david.brown@hesbynett.no> - 2020-03-13 14:26 +0100
          Re: overuse of auto is dangerous jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-14 09:20 +0100
            Re: overuse of auto is dangerous Sam <sam@email-scan.com> - 2020-03-14 10:12 -0400
            Re: overuse of auto is dangerous David Brown <david.brown@hesbynett.no> - 2020-03-14 16:12 +0100
              Re: overuse of auto is dangerous Bart <bc@freeuk.com> - 2020-03-14 17:23 +0000
                Re: overuse of auto is dangerous David Brown <david.brown@hesbynett.no> - 2020-03-15 12:27 +0100
                  Re: overuse of auto is dangerous Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-15 15:41 -0700
                    Re: overuse of auto is dangerous Ian Collins <ian-news@hotmail.com> - 2020-03-16 13:37 +1300
                      Re: overuse of auto is dangerous Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-16 07:26 +0000
                        Re: overuse of auto is dangerous Sam <sam@email-scan.com> - 2020-03-16 07:05 -0400
                          Re: overuse of auto is dangerous David Brown <david.brown@hesbynett.no> - 2020-03-16 12:32 +0100
                            Re: overuse of auto is dangerous Sam <sam@email-scan.com> - 2020-03-16 08:21 -0400
                        Re: overuse of auto is dangerous Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-16 11:27 +0000
                    Re: overuse of auto is dangerous David Brown <david.brown@hesbynett.no> - 2020-03-16 09:11 +0100
                      Re: overuse of auto is dangerous Bart <bc@freeuk.com> - 2020-03-16 11:44 +0000
                        Re: overuse of auto is dangerous David Brown <david.brown@hesbynett.no> - 2020-03-16 13:29 +0100
                      Re: overuse of auto is dangerous Öö Tiib <ootiib@hot.ee> - 2020-03-16 05:35 -0700
                      Re: overuse of auto is dangerous James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-16 09:16 -0400
                    Re: overuse of auto is dangerous Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:13 -0700
                      Re: overuse of auto is dangerous James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-02 07:45 -0700
                        Re: overuse of auto is dangerous Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-02 10:25 -0700
                        Re: overuse of auto is dangerous Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 12:49 -0700
                          Re: overuse of auto is dangerous David Brown <david.brown@hesbynett.no> - 2020-04-05 14:15 +0200
                      Re: overuse of auto is dangerous Paavo Helde <myfirstname@osa.pri.ee> - 2020-04-02 19:20 +0300
                      Re: overuse of auto is dangerous Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-02 10:19 -0700
          Re: overuse of auto is dangerous Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-15 16:26 +0100
      Re: overuse of auto is dangerous Daniel <danielaparker@gmail.com> - 2020-03-13 07:27 -0700
        Re: overuse of auto is dangerous Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-13 21:22 +0000
        Re: overuse of auto is dangerous Melzzzzz <Melzzzzz@zzzzz.com> - 2020-03-14 04:53 +0000
          Re: overuse of auto is dangerous Öö Tiib <ootiib@hot.ee> - 2020-03-14 03:23 -0700
            Re: overuse of auto is dangerous Melzzzzz <Melzzzzz@zzzzz.com> - 2020-03-14 13:20 +0000
              Re: overuse of auto is dangerous Öö Tiib <ootiib@hot.ee> - 2020-03-14 09:20 -0700
    Re: overuse of auto is dangerous Paavo Helde <myfirstname@osa.pri.ee> - 2020-03-13 13:53 +0200
    Re: overuse of auto is dangerous Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-03-13 15:46 +0000
    Re: overuse of auto is dangerous Sam <sam@email-scan.com> - 2020-03-13 23:09 -0400
    Re: overuse of auto is dangerous Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-14 08:06 +0100
      Re: overuse of auto is dangerous Melzzzzz <Melzzzzz@zzzzz.com> - 2020-03-14 13:16 +0000
        Re: overuse of auto is dangerous Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-16 15:31 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#72291

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.

[toc] | [prev] | [next] | [standalone]

#72294

On 14/03/2020 15:12, David Brown wrote:
> On 14/03/2020 09:20, jacobnavia wrote:
>> Le 13/03/2020 à 14:26, David Brown a écrit :

>> 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.

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.

[toc] | [prev] | [next] | [standalone]

#72302

On 14/03/2020 18:23, Bart wrote:
> On 14/03/2020 15:12, David Brown wrote:
>> On 14/03/2020 09:20, jacobnavia wrote:
>>> Le 13/03/2020 à 14:26, David Brown a écrit :
> 
>>> 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.
> 
> Does C++ still need declarations of such functions when the definition 
> itself is not visible? If so, what would they look like?

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.

[toc] | [prev] | [next] | [standalone]

#72308

David Brown <david.brown@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.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#72310

On 16/03/2020 11:41, Keith Thompson wrote:
> David Brown <david.brown@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.

[toc] | [prev] | [next] | [standalone]

#72315

On Mon, 2020-03-16, Ian Collins wrote:
> On 16/03/2020 11:41, Keith Thompson wrote:
>> David Brown <david.brown@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..

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.

/Jorgen

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

[toc] | [prev] | [next] | [standalone]

#72318

[Multipart message — attachments visible in raw view] — view raw

Jorgen Grahn writes:

> On Mon, 2020-03-16, Ian Collins wrote:
> > On 16/03/2020 11:41, Keith Thompson wrote:
> >> David Brown <david.brown@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..
>
> 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.

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…

[toc] | [prev] | [next] | [standalone]

#72320

On 16/03/2020 12:05, Sam wrote:
> Jorgen Grahn writes:
> 
>> On Mon, 2020-03-16, Ian Collins wrote:
>> > On 16/03/2020 11:41, Keith Thompson wrote:
>> >> David Brown <david.brown@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..
>>
>> 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.
> 
> 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…
> 

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.

[toc] | [prev] | [next] | [standalone]

#72323

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#72319

On Mon, 2020-03-16, Jorgen Grahn wrote:
> On Mon, 2020-03-16, Ian Collins wrote:
>> On 16/03/2020 11:41, Keith Thompson wrote:
>>> David Brown <david.brown@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..
>
> 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.

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.

/Jorgen

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

[toc] | [prev] | [next] | [standalone]

#72316

On 15/03/2020 23:41, Keith Thompson wrote:
> David Brown <david.brown@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.

[toc] | [prev] | [next] | [standalone]

#72321

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'.)

[toc] | [prev] | [next] | [standalone]

#72324

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.)

[toc] | [prev] | [next] | [standalone]

#72326

On Monday, 16 March 2020 10:12:09 UTC+2, David Brown  wrote:
> On 15/03/2020 23:41, Keith Thompson wrote:
> > David Brown <david.brown@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.

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?

[toc] | [prev] | [next] | [standalone]

#72328

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.

[toc] | [prev] | [next] | [standalone]

#72752

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> David Brown <david.brown@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?

[toc] | [prev] | [next] | [standalone]

#72754

On Thursday, April 2, 2020 at 10:13:17 AM UTC-4, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@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.

[toc] | [prev] | [next] | [standalone]

#72759

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On Thursday, April 2, 2020 at 10:13:17 AM UTC-4, Tim Rentsch wrote:
>> Keith Thompson <Keith.S.Thompson+u@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.

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

[toc] | [prev] | [next] | [standalone]

#72814

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

> On Thursday, April 2, 2020 at 10:13:17 AM UTC-4, Tim Rentsch wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@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.

[toc] | [prev] | [next] | [standalone]

#72826

On 04/04/2020 21:49, Tim Rentsch wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> 
>> On Thursday, April 2, 2020 at 10:13:17 AM UTC-4, Tim Rentsch
>> wrote:
>> 
>>> Keith Thompson <Keith.S.Thompson+u@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.

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?

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web