"cppfront: Spring update" by Herb Sutter
https://herbsutter.com/2023/04/30/cppfront-spring-update/

"Since the year-end mini-update, progress has continued on cppfront. (If
you don’t know what this personal project is, please see the CppCon 2022
talk on YouTube.)"
https://herbsutter.com/2022/12/31/cpp2-and-cppfront-year-end-mini-update/
https://github.com/hsutter/cppfront
https://www.youtube.com/watch?v=ELeZAKCN4tY

"This update covers Acknowledgments, and highlights of what’s new in the
compiler and language since last time, including:"
* simple, mathematically safe, and efficient chained comparisons
* named break and continue
* “simple and safe” starts with . . . main
* user-defined type, including unifying all special member functions
as operator=
* type/namespace/function/object aliases
* header reflect.h with the start of the reflection API and the
first 10 working compile-time metafunctions from P0707 unifying
functions and blocks, including removing : and = from the for loop syntax"

Lynn

[Please do not mail me a copy of your followup]

Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code
<u2p9iv$bk4v$1@dont-email.me> thusly:

>"cppfront: Spring update" by Herb Sutter
> https://herbsutter.com/2023/04/30/cppfront-spring-update/

I like the direction this is headed, but sometimes they just get a
little goofy:

> auto interface(meta::type_declaration& t)
> -> void

The obsession with trailing return type here is pointless.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

On 5/2/2023 5:18 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code
> <u2p9iv$bk4v$1@dont-email.me> thusly:
>
>> "cppfront: Spring update" by Herb Sutter
>> https://herbsutter.com/2023/04/30/cppfront-spring-update/
>
> I like the direction this is headed, but sometimes they just get a
> little goofy:
>
>> auto interface(meta::type_declaration& t)
>> -> void
>
> The obsession with trailing return type here is pointless.

You are going to have to explain trailing return type for me, I don't
get it.

Thanks,
Lynn

On Saturday, May 6, 2023 at 3:19:01 PM UTC-4, Lynn McGuire wrote:
> On 5/2/2023 5:18 PM, Richard wrote:
> > [Please do not mail me a copy of your followup]
> >
> > Lynn McGuire <lynnmcnmc..@gmail.com> spake the secret code
....
> >> auto interface(meta::type_declaration& t)
> >> -> void
> >
> > The obsession with trailing return type here is pointless.
> You are going to have to explain trailing return type for me, I don't
> get it.

See the Wikipedia article titled "Trailing Return Type" for an explanation. Allowing trailing return types solves a particular problem, but some people have decided to always use a trailing return type, even when (as in this case), The traditional way of declaring the return type would be unproblematic.

Am 06.05.2023 um 21:46 schrieb james...@alumni.caltech.edu:
> On Saturday, May 6, 2023 at 3:19:01 PM UTC-4, Lynn McGuire wrote:
>> On 5/2/2023 5:18 PM, Richard wrote:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Lynn McGuire <lynnmcnmc..@gmail.com> spake the secret code
> ...
>>>> auto interface(meta::type_declaration& t)
>>>> -> void
>>>
>>> The obsession with trailing return type here is pointless.
>> You are going to have to explain trailing return type for me, I don't
>> get it.
>
> See the Wikipedia article titled "Trailing Return Type" for an explanation. Allowing trailing return types solves a particular problem, but some people have decided to always use a trailing return type, even when (as in this case), The traditional way of declaring the return type would be unproblematic.

Where's the problem ?

On 2023-05-07 at 09:19, Bonita Montero wrote:
> Am 06.05.2023 um 21:46 schrieb james...@alumni.caltech.edu:
>> On Saturday, May 6, 2023 at 3:19:01 PM UTC-4, Lynn McGuire wrote:
>>> On 5/2/2023 5:18 PM, Richard wrote:
>>>> [Please do not mail me a copy of your followup]
>>>>
>>>> Lynn McGuire <lynnmcnmc..@gmail.com> spake the secret code
>> ...
>>>>> auto interface(meta::type_declaration& t)
>>>>> -> void
>>>>
>>>> The obsession with trailing return type here is pointless.
>>> You are going to have to explain trailing return type for me, I don't
>>> get it.
>>
>> See the Wikipedia article titled "Trailing Return Type" for an
>> explanation. Allowing trailing return types solves a particular
>> problem, but some people have decided to always use a trailing return
>> type, even when (as in this case), The traditional way of declaring
>> the return type would be unproblematic.
>
> Where's the problem ?

It's not a problem, it is just a bit silly.

Instead of trying a one-size-fits-all rule of always using a trailing
return types, you *could* say 'void' up front for functions that doesn't
have a return type. It wouldn't hurt, would it?

On Sunday, 7 May 2023 at 11:33:02 UTC+3, Bo Persson wrote:
> On 2023-05-07 at 09:19, Bonita Montero wrote:
> > Am 06.05.2023 um 21:46 schrieb james...@alumni.caltech.edu:
> >> On Saturday, May 6, 2023 at 3:19:01 PM UTC-4, Lynn McGuire wrote:
> >>> On 5/2/2023 5:18 PM, Richard wrote:
> >>>> [Please do not mail me a copy of your followup]
> >>>>
> >>>> Lynn McGuire <lynnmcnmc..@gmail.com> spake the secret code
> >> ...
> >>>>> auto interface(meta::type_declaration& t)
> >>>>> -> void
> >>>>
> >>>> The obsession with trailing return type here is pointless.
> >>> You are going to have to explain trailing return type for me, I don't
> >>> get it.
> >>
> >> See the Wikipedia article titled "Trailing Return Type" for an
> >> explanation. Allowing trailing return types solves a particular
> >> problem, but some people have decided to always use a trailing return
> >> type, even when (as in this case), The traditional way of declaring
> >> the return type would be unproblematic.
> >
> > Where's the problem ?
> It's not a problem, it is just a bit silly.
>
> Instead of trying a one-size-fits-all rule of always using a trailing
> return types, you *could* say 'void' up front for functions that doesn't
> have a return type. It wouldn't hurt, would it?

It is about equivalent syntax for saying same thing so one could
perhaps configure some mechanical code formatting tool to
round-trip format between ...

void blah(type param) { /* etc. */ }

... and ...

auto blah(type param) -> void { /* etc. */ }

.... without any issues.

I personally like trailing type of Go, Rust, Kotlin and Swift but for
C, C++, Java, C#, D etc. that ship has IMHO sailed and trying to mix it
in just results with more to type and to read and more obfuscation.
Especially in language where auto is overused in various meanings
adding it to blather more about lack of return (void) is strange.

On Sunday, May 7, 2023 at 3:20:02 AM UTC-4, Bonita Montero wrote:
> Am 06.05.2023 um 21:46 schrieb james...@alumni.caltech.edu:
....
> > See the Wikipedia article titled "Trailing Return Type" for an explanation.
> > Allowing trailing return types solves a particular problem, but some
> > people have decided to always use a trailing return type, even when (as
> > in this case), The traditional way of declaring the return type would be
> > unproblematic.
> Where's the problem ?

The problem it solves is descried in that article, but if you can't be bothered
to read it, I can summarize: on occasion, the return type of a function can
be described in terms of the types of it's parameters, but those parameters
are not in scope at the point where a conventional return type is declared.
However, they are in scope in the place where the trailing return type is
declared. The example given in that article is

template<typename TL, typename TR>
auto Add(const TL& lhs, const TR& rhs) -> decltype(lhs + rhs) {
return lhs + rhs;
}

This is not a major problem, or it's solution would not have waited so long
to be included in the language - but it is a convenience.

On 08/05/2023 06:11, james...@alumni.caltech.edu wrote:
> On Sunday, May 7, 2023 at 3:20:02 AM UTC-4, Bonita Montero wrote:
>> Am 06.05.2023 um 21:46 schrieb james...@alumni.caltech.edu:
> ...
>>> See the Wikipedia article titled "Trailing Return Type" for an explanation.
>>> Allowing trailing return types solves a particular problem, but some
>>> people have decided to always use a trailing return type, even when (as
>>> in this case), The traditional way of declaring the return type would be
>>> unproblematic.
>> Where's the problem ?
>
> The problem it solves is descried in that article, but if you can't be bothered
> to read it, I can summarize: on occasion, the return type of a function can
> be described in terms of the types of it's parameters, but those parameters
> are not in scope at the point where a conventional return type is declared.
> However, they are in scope in the place where the trailing return type is
> declared. The example given in that article is
>
> template<typename TL, typename TR>
> auto Add(const TL& lhs, const TR& rhs) -> decltype(lhs + rhs) {
> return lhs + rhs;
> }
>
> This is not a major problem, or it's solution would not have waited so long
> to be included in the language - but it is a convenience.

One option would be to write :

#define function auto

Then people could write :

function foo(int x, int y) -> int;

(No, I do /not/ recommend that!)

A not uncommon complaint about the syntax of C and C++ is that there is
no keyword that says this is the start of a function definition, as
there is in most languages - this would let you pretend there is one.

I sometimes use "auto" for functions, but then I do not have a trailing
return type - return type deduction is simpler and clearer:

template<typename TL, typename TR>
auto Add(const TL& lhs, const TR& rhs) {
return lhs + rhs;
}

I think it is rare that a decltype trailing return type actually makes
anything clearer in the code - it just adds more scope for error. And I
see no purpose at all in putting "auto" at the start of the function
declaration and an explicit type at the end. Putting "auto", or a
concept, as the return type is a clear indication that you do not have
(or want to give) an explicit return type here but want the compiler to
figure it out. That's what "auto" means in C++. It seems
counter-productive to me to say "the compiler will figure this out" at
the start of the declaration, then do the compiler's job at the end of
the declaration.

You know, that in the best case each human has one lookaline in the world ?

When You ask me, then I have not seen my lookalike, but my brother saw one day somewhere(Tallinn) my lookalike.

You've seen Rando Tomson somewhere before ?