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

Groups > comp.lang.ada > #59710 > unrolled thread

Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for

Back to article view | Back to comp.lang.ada

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-05-10 20:24 +0000
    Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for geodandw <geodandw@gmail.com> - 2026-05-10 17:52 -0400
      Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-10 22:07 +0000
        Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for OrangeFish <OrangeFish@invalid.invalid> - 2026-05-11 12:27 -0400
      Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-05-11 08:00 +0000
      Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-11 08:22 +0000
        Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for "Luke A. Guest" <laguest@archeia.com> - 2026-05-11 12:20 +0100
          Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-11 15:08 +0000
            Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for "Luke A. Guest" <laguest@archeia.com> - 2026-05-12 15:21 +0100
              Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-12 15:06 +0000
                Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for "Luke A. Guest" <laguest@archeia.com> - 2026-05-12 17:27 +0100
                  Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-13 07:49 +0000
        Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for "J-P. Rosen" <rosen@adalog.fr> - 2026-05-11 16:16 +0200
          Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-12 02:21 +0000
            Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-12 08:42 +0000
              Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-12 20:37 +0000
                Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-13 07:52 +0000
        Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Björn Persson <Bjorn@xn--rombobjrn-67a.se> - 2026-05-11 19:44 +0200
          Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-12 08:30 +0000
        Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-11 22:33 +0000
          Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-12 08:38 +0000
            Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-12 20:38 +0000
              Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-13 07:55 +0000
                Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for David Brown <david.brown@hesbynett.no> - 2026-05-13 10:17 +0200
                  Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-14 08:01 +0000
                    Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for David Brown <david.brown@hesbynett.no> - 2026-05-14 11:22 +0200
                      Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for boltar@caprica.universe - 2026-05-14 15:00 +0000
                Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-13 21:33 +0000
      Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Kevin Chadwick <kc-usenet@chadwicks.me.uk> - 2026-11-01 01:34 +0000
        Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-01 05:49 +0000
          Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Paul Rubin <no.email@nospam.invalid> - 2026-10-31 22:57 -0700
          Re: "Herb Sutter: Why C++ Is Growing and What C++26 Means for Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-11-02 11:32 -0500

Page 2 of 2 — ← Prev page 1 [2]

#59723

On Mon, 11 May 2026 22:33:09 -0000 (UTC)
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> gabbled:
>On Mon, 11 May 2026 08:22:55 -0000 (UTC), boltar wrote:
>
>> Its a PITA because its long winded like Java, has the god awful
>> pascal style syntax ...
>
>Even C++ is now discovering why it can be preferable to have the
>function return type specified after the arguments, rather than
>before.

Really? The ONLY reason for the -> operator being overloaded for return
values is because thats how it was decided to implement lambda syntax
back in 2011 for reasons best known to themselves. Using it in normal
function definitions is frankly assinine.

auto main(int argc, char **argv) -> int
{

etc is just poncy coding style in order to make the author seem smart plus
the syntax is idiotic because in this case "auto" is overloaded simply to be
a function start placeholder. If the semantics were sane it wouldn't be needed
but I imagine that would make the lexical analysis even more complicated.

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

#59729

On Tue, 12 May 2026 08:38:32 -0000 (UTC), boltar wrote:

> On Mon, 11 May 2026 22:33:09 -0000 (UTC), Lawrence D’Oliveiro wrote:
>>
>> On Mon, 11 May 2026 08:22:55 -0000 (UTC), boltar wrote:
>>
>>> Its a PITA because its long winded like Java, has the god awful
>>> pascal style syntax ...
>>
>> Even C++ is now discovering why it can be preferable to have the
>> function return type specified after the arguments, rather than
>> before.
>
> Really? The ONLY reason for the -> operator being overloaded for
> return values is because thats how it was decided to implement
> lambda syntax back in 2011 for reasons best known to themselves.

There is another reason: a result type that depends on the argument
types.

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

#59734

On Tue, 12 May 2026 20:38:59 -0000 (UTC)
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> gabbled:
>On Tue, 12 May 2026 08:38:32 -0000 (UTC), boltar wrote:
>
>> On Mon, 11 May 2026 22:33:09 -0000 (UTC), Lawrence D’Oliveiro wrote:
>>>
>>> On Mon, 11 May 2026 08:22:55 -0000 (UTC), boltar wrote:
>>>
>>>> Its a PITA because its long winded like Java, has the god awful
>>>> pascal style syntax ...
>>>
>>> Even C++ is now discovering why it can be preferable to have the
>>> function return type specified after the arguments, rather than
>>> before.
>>
>> Really? The ONLY reason for the -> operator being overloaded for
>> return values is because thats how it was decided to implement
>> lambda syntax back in 2011 for reasons best known to themselves.
>
>There is another reason: a result type that depends on the argument
>types.

Huh? You can't change the result type once you've defined it. If you want
an auto return type you don't add "-> <type>" on the end.

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

#59735

On 13/05/2026 09:55, boltar@caprica.universe wrote:
> On Tue, 12 May 2026 20:38:59 -0000 (UTC)
> Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> gabbled:
>> On Tue, 12 May 2026 08:38:32 -0000 (UTC), boltar wrote:
>>
>>> On Mon, 11 May 2026 22:33:09 -0000 (UTC), Lawrence D’Oliveiro wrote:
>>>>
>>>> On Mon, 11 May 2026 08:22:55 -0000 (UTC), boltar wrote:
>>>>
>>>>> Its a PITA because its long winded like Java, has the god awful
>>>>> pascal style syntax ...
>>>>
>>>> Even C++ is now discovering why it can be preferable to have the
>>>> function return type specified after the arguments, rather than
>>>> before.
>>>
>>> Really? The ONLY reason for the -> operator being overloaded for
>>> return values is because thats how it was decided to implement
>>> lambda syntax back in 2011 for reasons best known to themselves.
>>
>> There is another reason: a result type that depends on the argument
>> types.
> 
> Huh? You can't change the result type once you've defined it. If you want
> an auto return type you don't add "-> <type>" on the end.
> 

Yes, you do /exactly/ that if your return type depends on the argument 
types.

template<typename T1, typename T2>
X add(T1 a, T2 b)
{
	return a + b;
}

What type should X be?  It depends on the types of "a" and "b" (which 
might be class types here).  So you can write:

template<typename T1, typename T2>
auto add(T1 a, T2 b) -> decltype(a + b)
{
	return a + b;
}

It is fair to say that this form is less needed after C++14 return type 
deduction meant that you could often use "auto" without specifying the 
return type like this.  But of course for stand-alone function 
declarations in a header without their implementation, you can't do 
return type deduction - thus trailing return type can be useful.


You might also use it for complicated types, such as returning a 
function pointer, where it is clearer:

int (*get_function_pointer(int x))(int);

auto get_func_pointer(int x) -> int(*)(int);

Many people find the second form easier to read (it's much like the 
difference between typedef and using for type declarations).


<https://cppreference.com/cpp/language/function>

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

#59737

On Wed, 13 May 2026 10:17:32 +0200
David Brown <david.brown@hesbynett.no> gabbled:
>On 13/05/2026 09:55, boltar@caprica.universe wrote:
>template<typename T1, typename T2>
>X add(T1 a, T2 b)
>{
>	return a + b;
>}
>
>What type should X be?  It depends on the types of "a" and "b" (which 
>might be class types here).  So you can write:
>
>template<typename T1, typename T2>
>auto add(T1 a, T2 b) -> decltype(a + b)
>{
>	return a + b;
>}

A sane syntax would have been

template<typename T1, typename T2>
(T1 + T2) add(T1 a, T2 b)
{
:
}

But this is C++ so not a chance, lets make it as verbose as possible.

>You might also use it for complicated types, such as returning a 
>function pointer, where it is clearer:
>
>int (*get_function_pointer(int x))(int);
>
>auto get_func_pointer(int x) -> int(*)(int);

I'll give you that, but the C function pointer syntax was unnecessarily
messy and there's no reason C++ couldn't have tidied it up even before
std::function came along. Something like:

int (*(int))get_func_pointer(x)
{
:
}

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

#59738

On 14/05/2026 10:01, boltar@caprica.universe wrote:
> On Wed, 13 May 2026 10:17:32 +0200
> David Brown <david.brown@hesbynett.no> gabbled:
>> On 13/05/2026 09:55, boltar@caprica.universe wrote:
>> template<typename T1, typename T2>
>> X add(T1 a, T2 b)
>> {
>>     return a + b;
>> }
>>
>> What type should X be?  It depends on the types of "a" and "b" (which 
>> might be class types here).  So you can write:
>>
>> template<typename T1, typename T2>
>> auto add(T1 a, T2 b) -> decltype(a + b)
>> {
>>     return a + b;
>> }
> 
> A sane syntax would have been
> 
> template<typename T1, typename T2>
> (T1 + T2) add(T1 a, T2 b)
> {
> :
> }
> 
> But this is C++ so not a chance, lets make it as verbose as possible.
> 
>> You might also use it for complicated types, such as returning a 
>> function pointer, where it is clearer:
>>
>> int (*get_function_pointer(int x))(int);
>>
>> auto get_func_pointer(int x) -> int(*)(int);
> 
> I'll give you that, but the C function pointer syntax was unnecessarily
> messy and there's no reason C++ couldn't have tidied it up even before
> std::function came along. Something like:
> 
> int (*(int))get_func_pointer(x)
> {
> :
> }
> 

I don't think anyone sees the C or C++ type syntaxes as being the nicest 
conceivable for a programming language.  But the languages are what they 
are, stretching back to a time when the syntax choices were made as good 
design decisions.  Modern C++ cannot start from scratch - new features 
have to fit with the existing language, existing tools, existing 
programmers, and existing code.  Sometimes things can be "tidied up" a 
bit - that's exactly the case for trailing return types.  (It might have 
been nicer if a new keyword - say, "func" - had been introduced to mean 
exactly the same as "auto" but only available for function declarations. 
  But new keywords are not free in an established language.)

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

#59739

On Thu, 14 May 2026 11:22:47 +0200
David Brown <david.brown@hesbynett.no> gabbled:
>I don't think anyone sees the C or C++ type syntaxes as being the nicest 
>conceivable for a programming language.  But the languages are what they 
>are, stretching back to a time when the syntax choices were made as good 
>design decisions.  Modern C++ cannot start from scratch - new features 
>have to fit with the existing language, existing tools, existing 
>programmers, and existing code.  Sometimes things can be "tidied up" a 
>bit - that's exactly the case for trailing return types.  (It might have 
>been nicer if a new keyword - say, "func" - had been introduced to mean 
>exactly the same as "auto" but only available for function declarations. 
>  But new keywords are not free in an established language.)

True, but sometimes the bullet has to be bitten and they just need to
be introduced. If they cause backwards compat problems with older software
thats just tough luck. Eg new, delete, virtual, try, throw etc were all new 
keywords that are not in C.

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

#59736

On Wed, 13 May 2026 07:55:05 -0000 (UTC), boltar wrote:

> On Tue, 12 May 2026 20:38:59 -0000 (UTC), Lawrence D’Oliveiro wrote:
>>
>> On Tue, 12 May 2026 08:38:32 -0000 (UTC), boltar wrote:
>>
>>> On Mon, 11 May 2026 22:33:09 -0000 (UTC), Lawrence D’Oliveiro wrote:
>>>>
>>>> On Mon, 11 May 2026 08:22:55 -0000 (UTC), boltar wrote:
>>>>
>>>>> Its a PITA because its long winded like Java, has the god awful
>>>>> pascal style syntax ...
>>>>
>>>> Even C++ is now discovering why it can be preferable to have the
>>>> function return type specified after the arguments, rather than
>>>> before.
>>>
>>> Really? The ONLY reason for the -> operator being overloaded for
>>> return values is because thats how it was decided to implement
>>> lambda syntax back in 2011 for reasons best known to themselves.
>>
>> There is another reason: a result type that depends on the argument
>> types.
>
> Huh? You can't change the result type once you've defined it. If you
> want an auto return type you don't add "-> <type>" on the end.

You don’t really know much about C++, do you?

<https://cppreference.com/cpp/language/function>

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

#59812

>Its a PITA because you have to have it correct before it compiles, as 
>opposed to C++ where you don't.

SO much fun troubleshooting at runtime instead.

-- 
Regards, Kc

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

#59813

On Sun, 1 Nov 2026 01:34:01 -0000 (UTC), Kevin Chadwick wrote:

>> Its a PITA because you have to have it correct before it compiles,
>> as opposed to C++ where you don't.
>
> SO much fun troubleshooting at runtime instead.

Kidding, right?

It’s been a while since I did some C++ code, but I remember wading
through *massive* screeds of error messages every time there was a
type mismatch on some function argument, and the GNU C++ compiler
would list *every single possible overload candidate*, so you got
dozens, possibly even hundreds, of lines of messages just for one
error. And you had to check them *all* to be sure which one you meant,
and to figure out what to fix to get the compiler to agree.

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

#59814

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> It’s been a while since I did some C++ code, but I remember wading
> through *massive* screeds of error messages

Haskell is like that too, but the trick for both Haskell and C++ is that
the diagnostics are usually accurate about what line number has the
error.  So you can often look at the code at that location and figure
out what is wrong, without having to examine the error message too
carefully.

C++ Concepts are supposed to decrease the message spew by a lot as well.

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

#59816

Lawrence D’Oliveiro wrote this screed in ALL-CAPS (fixed):

> On Sun, 1 Nov 2026 01:34:01 -0000 (UTC), Kevin Chadwick wrote:
>
>>> Its a PITA because you have to have it correct before it compiles,
>>> as opposed to C++ where you don't.
>>
>> SO much fun troubleshooting at runtime instead.
>
> Kidding, right?
>
> It’s been a while since I did some C++ code, but I remember wading
> through *massive* screeds of error messages every time there was a
> type mismatch on some function argument, and the GNU C++ compiler
> would list *every single possible overload candidate*, so you got
> dozens, possibly even hundreds, of lines of messages just for one
> error. And you had to check them *all* to be sure which one you meant,
> and to figure out what to fix to get the compiler to agree.

I see those a lot, but in almost all cases I can ignore all the
follow-on information and go to the offending line of code and
then *doh* slap my forehead.

I'll admit it's a pain when you forget the closing "}" of a
universal initializer.

-- 
	"But I don't want to go on the cart..."
	"Oh, don't be such a baby!"
	"But I'm feeling much better..."
	"No you're not... in a moment you'll be stone dead!"
		-- Monty Python, "The Holy Grail"

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.ada

csiph-web