From Newsgroup: comp.lang.ada

Boltar@caprica.Universe wrote: |-------------------------------------------------------------------------------|
|"On Sat, 9 May 2026 07:31:02 -0400 |
|Chris Ahlstrom <OFeem1987@teleworm.us> gabbled: |

Lynn McGuire wrote this screed in ALL-CAPS: |

Hat tip to: |
http://herbsutter.com/2026/04/29/london-meetup/ |

|
Heh, I only recently started using C++17 features. |
|
Herb talks about C++20 issues with: |
|
- Modules. (They don't work.) |
- Coroutines. (They're not actually coroutines.) |

| |
|Quite how they managed to come up with such an utter abortion of an |
|implementation is anyones guess. They should have taken a look at how |
|Python does it - the function returns an iterator and you call "yield <result>"|
|inside it. Done. |
| |

- Concepts. (Cool, but most of you won't ever write one.) |

| |
|But morons conducting job interviews will still ask about them even though |
|their company code doesn't contain them either. |
| |

Apparently GCC will be getting contracts and reflection "soon". |

| |
|I can't wait for contracts and reflection in C++! |
| |
|Said no one , ever." |
|-------------------------------------------------------------------------------|

How about contracts in Eiffel or Ada?

Message-ID: <9c75e0f1-d977-40a3-b8c4-64751c6e0a39n@googlegroups.com>
says since
Date: Sat, 8 Apr 2023 10:27:16 -0700 (PDT)
-
|-------------------------------------------------------------------------| |"On Saturday, April 8, 2023 at 6:48:14 PM UTC+2, Simon Wright wrote: |

GCC 12.2.0 accepts this code with -gnat2022. |

| | |True! Cool... In my opinion, contracts are among the coolest (and maybe| |more exclusive) features of Ada" | |-------------------------------------------------------------------------|

(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

Boltar@caprica.Universe wrote:
|---------------------------------------------|
|"You ever had to program in Ada? Its a PITA."| |---------------------------------------------|

I disagree.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On 5/10/26 16:24, Nioclás Pól Caileán de Ghloucester wrote:

Boltar@caprica.Universe wrote: |---------------------------------------------|
|"You ever had to program in Ada? Its a PITA."| |---------------------------------------------|

I disagree.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)

Its a PITA because you have to have it correct before it compiles, as
opposed to C++ where you don't.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

In comp.lang.c++ geodandw <geodandw@gmail.com> wrote:

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

I have heard that Ada is being used in situations where correctness
is of utmost importance. One such field is aviation, I suppose.

br,
KK
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

Correctness is a good thing.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On Sun, 10 May 2026 17:52:30 -0400
geodandw <geodandw@gmail.com> gabbled:

On 5/10/26 16:24, Nioclás Pól Caileán de Ghloucester wrote:

Boltar@caprica.Universe wrote:
|---------------------------------------------|
|"You ever had to program in Ada? Its a PITA."|
|---------------------------------------------|

I disagree.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)

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

Its a PITA because its long winded like Java, has the god awful pascal
style syntax, and far too many basic operations throw exceptions instead of simply returning success/failure values.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On 11/05/2026 09:22, boltar@caprica.universe wrote:

Its a PITA because its long winded like Java, has the god awful pascal
style syntax, and far too many basic operations throw exceptions instead
of simply returning success/failure values.

so, you're admitting that you've never seen Ada, Pascal has a horrible
syntax mainly because of it's semicolon as a separator mess. Semicolon's
end statements in Ada, also looks nothing like Pascal apart from begin
blocks, which aren't in block statements unlike Pascal.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

Le 11/05/2026 à 10:22, boltar@caprica.universe a écrit :

Its a PITA because its long winded like Java, has the god awful pascal
style syntax, and far too many basic operations throw exceptions instead
of simply returning success/failure values.

Exceptions are much better for safety, since an exception cannot be ignored, while it is too easy to forget to check a success/failure return value.

"There is only one thing worse than a program that crashes: a program that produces wrong, but apparently correct results"
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On Mon, 11 May 2026 12:20:59 +0100
"Luke A. Guest" <laguest@archeia.com> gabbled:

On 11/05/2026 09:22, boltar@caprica.universe wrote:

Its a PITA because its long winded like Java, has the god awful pascal
style syntax, and far too many basic operations throw exceptions instead
of simply returning success/failure values.

so, you're admitting that you've never seen Ada, Pascal has a horrible

No, I never saw it while I was working on it, did everything blindfold.

syntax mainly because of it's semicolon as a separator mess. Semicolon's
end statements in Ada, also looks nothing like Pascal apart from begin >blocks, which aren't in block statements unlike Pascal.

The syntax is derived from pascal, stop pretending otherwise.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On 2026-05-10 18:07, Kalevi Kolttonen wrote:

In comp.lang.c++ geodandw <geodandw@gmail.com> wrote:

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

I have heard that Ada is being used in situations where correctness
is of utmost importance. One such field is aviation, I suppose.

br,
KK

Some years ago, I attended an introductory course on CMM. Two
classmates worked in military avionics. They told me that there was a
trend to move from ADA to C++ because "it was becoming standard". That
was one of the most depressing and frightening things I have heard in a
while.

However, I understand that Airbus uses both ADA and C++ in critical systems.

OF
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

boltar@caprica.universe wrote:

Its a PITA because its long winded like Java,

So Ada isn't optimal for code golf and obfuscation contests. Feel free
to choose another language for those purposes.
Each line or fragment of source code is written once and read many
times. Thus clarity is more important than saving keystrokes. Typing
speed isn't the bottleneck anyway. I spend more time thinking about the
correct solution than I do typing.

has the god awful pascal style syntax,

You mean a syntax that doesn't let you write "if(x = 0)" bugs? A syntax
that makes sense when read left-to-right, unlike C where the best way
to make sense of a declaration is to read it from the middle towards
both ends?
A syntax where instead of this:
}
}
}
}
you'll see this:
end if;
end loop;
end if;
end Foo;
If a closing brace is missing, a C/C++ compiler will spout lots of
misleading error messages, and then report the missing brace at the end
of the file – or even at the end of another file. An Ada compiler can
say "hey, an "end loop" is missing before this "end if" right here".
Yeah, how awful!

and far too many basic operations throw exceptions instead of simply returning success/failure values.

Here's an example from last year of how returning success/failure
values leads to bugs:
https://www.qualys.com/2025/02/18/openssh-mitm-dos.txt
Security researchers found several errors in the handling of error codes
in OpenSSH. One of them could be used to impersonate an SSH server. A
quote from their security advisory:
| - in verify_host_key() (when VerifyHostKeyDNS is enabled, at line 1538),
| if sshkey_from_private() returns any non-zero error code (at line
| 1543), then this error code is immediately returned to
| verify_host_key()'s caller (at line 1580);
|
| - unfortunately, in verify_host_key_callback() (verify_host_key()'s
| caller), only the return value -1 is treated as an error (at lines
| 101-103);
|
| - any other return value (for example, -2) is ignored, and zero
| (success) is mistakenly returned to verify_host_key_callback()'s
| caller (at line 104), as if no error had occurred, and without
| checking the server's host key at all.
With exceptions it's not so easy to get confused about what's success
and what's a failure.
Of course, code of lower quality than OpenSSH often neglects to check
for error codes at all. Forgetting to check for an exception doesn't
cause it to be silently treated as a success.
Björn Persson
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On Mon, 11 May 2026 16:16:04 +0200, J-P. Rosen wrote:

Le 11/05/2026 à 10:22, boltar@caprica.universe a écrit :

Its a PITA because its long winded like Java, has the god awful
pascal style syntax, and far too many basic operations throw
exceptions instead of simply returning success/failure values.

Exceptions are much better for safety, since an exception cannot be
ignored, while it is too easy to forget to check a success/failure
return value.

"There is only one thing worse than a program that crashes: a
program that produces wrong, but apparently correct results"

Worth also pointing out that Ada doesn’t require you to declare all
the exceptions a routine can return up front, unlike Java, where this
just adds to the clutter.

Also, Ada has typedefs, Java doesn’t. Ada has unsigned integers, Java doesn’t. Ada had generics from the start, Java had to tack them on afterwards, with some interesting consequences for backward
compatibiliy.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On Mon, 11 May 2026 19:44:31 +0200
=?UTF-8?B?QmrDtnJu?= Persson <Bjorn@xn--rombobjrn-67a.se> gabbled: >boltar@caprica.universe wrote:

Its a PITA because its long winded like Java,

So Ada isn't optimal for code golf and obfuscation contests. Feel free
to choose another language for those purposes.

Each line or fragment of source code is written once and read many
times. Thus clarity is more important than saving keystrokes. Typing

I'm not going to defend the clarity of C++, frankly the syntax is a mess.
But overdone long windedness doesn't aid clarity any more than adding ever
more punctuation to the syntax does. As in all things there's a happy medium.

has the god awful pascal style syntax,

You mean a syntax that doesn't let you write "if(x =3D 0)" bugs? A syntax

Set and test is not always a bug depending on what construct its used in. Besides which, most (all?) modern C/C++ compilers will throw a warning anyway.

that makes sense when read left-to-right, unlike C where the best way
to make sense of a declaration is to read it from the middle towards
both ends?

Huh?

A syntax where instead of this:

}
}
}
}

Clean and tidy.

you'll see this:

end if;
end loop;
end if;
end Foo;

Yuck. Its visual noise.

If a closing brace is missing, a C/C++ compiler will spout lots of
misleading error messages, and then report the missing brace at the end
of the file =E2=80=93 or even at the end of another file. An Ada compiler c= >an
say "hey, an "end loop" is missing before this "end if" right here".
Yeah, how awful!

I'll give you that one.

and far too many basic operations throw exceptions instead of simply retu= >rning success/failure values.

Here's an example from last year of how returning success/failure
values leads to bugs:

https://www.qualys.com/2025/02/18/openssh-mitm-dos.txt

I'm sure they do, but sometimes checking return values is simpler and tidier than having to remember and check for everything that might end up in a
handler down the bottom of the code or even worse having begin-exception
blocks around every damn bit of code that might cause them if you don't
want a catch-all handler.

Security researchers found several errors in the handling of error codes
in OpenSSH. One of them could be used to impersonate an SSH server. A
quote from their security advisory:

There are many reasons for security holes in software. I imagine poor
checking of return codes is in the statistical noise compared to the more common ones.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On Tue, 12 May 2026 02:21:51 -0000 (UTC)
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> gabbled:

On Mon, 11 May 2026 16:16:04 +0200, J-P. Rosen wrote:

"There is only one thing worse than a program that crashes: a
program that produces wrong, but apparently correct results"

Worth also pointing out that Ada doesn’t require you to declare all
the exceptions a routine can return up front, unlike Java, where this
just adds to the clutter.

Also, Ada has typedefs, Java doesn’t. Ada has unsigned integers, Java >doesn’t. Ada had generics from the start, Java had to tack them on >afterwards, with some interesting consequences for backward
compatibiliy.

Java generics are half arsed anyway making them utterly pointless. Template types can only be types derived from Object - ie not basic types such as
int or char - meaning their bring nothing to the table given all classes
are derived from Object anyway. Java generics are just syntactic sugar added
to keep some loudmouths happy.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On 11/05/2026 16:08, boltar@caprica.universe wrote:

No, I never saw it while I was working on it, did everything blindfold.

So, you just came here to be an idiot troll, go back to your ancient and insecure c then.

syntax mainly because of it's semicolon as a separator mess.
Semicolon's end statements in Ada, also looks nothing like Pascal
apart from begin blocks, which aren't in block statements unlike Pascal.

The syntax is derived from pascal, stop pretending otherwise.

Yes, it was ORIGINALLY, it was changed, so it barely resembles it now.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On Tue, 12 May 2026 15:21:07 +0100
"Luke A. Guest" <laguest@archeia.com> gabbled:

On 11/05/2026 16:08, boltar@caprica.universe wrote:

No, I never saw it while I was working on it, did everything blindfold.

So, you just came here to be an idiot troll, go back to your ancient and >insecure c then.

Do you understand sarcasm or are you just too far along the spectrum? And
I'm posting to a c++ group. Presumably some idiot x-posted.

The syntax is derived from pascal, stop pretending otherwise.

Yes, it was ORIGINALLY, it was changed, so it barely resembles it now.

Looks exactly like it to me.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On 12/05/2026 16:06, boltar@caprica.universe wrote:

On Tue, 12 May 2026 15:21:07 +0100
"Luke A. Guest" <laguest@archeia.com> gabbled:

On 11/05/2026 16:08, boltar@caprica.universe wrote:

No, I never saw it while I was working on it, did everything blindfold.

So, you just came here to be an idiot troll, go back to your ancient
and insecure c then.

Do you understand sarcasm or are you just too far along the spectrum? And
I'm posting to a c++ group. Presumably some idiot x-posted.

Have you not noticed you're also posting to the ada group?

The syntax is derived from pascal, stop pretending otherwise.

Yes, it was ORIGINALLY, it was changed, so it barely resembles it now.

Looks exactly like it to me.

Then you haven't looked deeply enough.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On Tue, 12 May 2026 08:42:46 -0000 (UTC), boltar wrote:

Java generics are half arsed anyway making them utterly pointless.
Template types can only be types derived from Object - ie not basic
types such as int or char - meaning their bring nothing to the table
given all classes are derived from Object anyway. Java generics are
just syntactic sugar added to keep some loudmouths happy.

Java preserves the C++ distinction between “PODs” (I think it calls
them “primitive types”) and classes/structs. I think the limitations
you point to apply to C++ as well. And possibly even Ada.

There are languages where “every value is an object”. Python is
probably the most popular one right now -- and justifiably so.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On Tue, 12 May 2026 17:27:36 +0100
"Luke A. Guest" <laguest@archeia.com> gabbled:

On 12/05/2026 16:06, boltar@caprica.universe wrote:

On Tue, 12 May 2026 15:21:07 +0100
"Luke A. Guest" <laguest@archeia.com> gabbled:

On 11/05/2026 16:08, boltar@caprica.universe wrote:

No, I never saw it while I was working on it, did everything blindfold. >>>

So, you just came here to be an idiot troll, go back to your ancient
and insecure c then.

Do you understand sarcasm or are you just too far along the spectrum? And
I'm posting to a c++ group. Presumably some idiot x-posted.

Have you not noticed you're also posting to the ada group?

Oddly enough I don't always read the header field lines when going through dozens of posts, no.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On Tue, 12 May 2026 20:37:01 -0000 (UTC)
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> gabbled:

On Tue, 12 May 2026 08:42:46 -0000 (UTC), boltar wrote:

Java generics are half arsed anyway making them utterly pointless.
Template types can only be types derived from Object - ie not basic
types such as int or char - meaning their bring nothing to the table
given all classes are derived from Object anyway. Java generics are
just syntactic sugar added to keep some loudmouths happy.

Java preserves the C++ distinction between “PODs” (I think it calls
them “primitive types”) and classes/structs. I think the limitations
you point to apply to C++ as well. And possibly even Ada.

Not to C++. Template types can be anything including basic types such as int.

There are languages where “every value is an object”. Python is
probably the most popular one right now -- and justifiably so.

Yes, I rather like Python though not for that reason. It Just Works, slowly, but IME it solves 90% of problems that in the past would have been written
in C++ or Java that don't require massive compute.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

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>

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

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>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

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)
{
:
}

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

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


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

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.

--- Synchronet 3.22a-Linux NewsLink 1.2