Terser function syntax?

[hsutter]

A Reddit discussion made me think of the following, and I thought I'd try it out .Currently Cpp2 allows defaulting this:

f:(in i: _) -> _ = { return i+1; }

to this, omitting the parts not being customized:

f:(i) -> _ = i+1;

Note that the in and : _ on parameters can be defaulted away, so a function parameter list f: (in x: _) is the same as f: (x). So my question is, what would you think if the same was done for the return type too, so the above could be spelled as just this, again omitting the parts not being customized:

f:(i) -> i+1;

That would make lambdas, which have the identical syntax just without the introducing name, even simpler, for example this:

std::transform(in1, in2, out1, :(x) -> _ = x+1;)

could be written as this:

std::transform(in1, in2, out1, :(x) -> x+1;)

WDYT?

Here's an example that works with the latest checkin:

main: () = {
    x: std::vector<int> = (1, 2, 3);
    y: std::vector<int> = (0, 0, 0);
    std::transform(x.begin(), x.end(), y.begin(), :(x) -> x+1;);
    for y do (i) std::cout << i;
}

Notes:

• The equivalent in today's C++ is: std::transform(in1, in2, out1, [](auto x){return x+1;})

• This isn't motivated by C# envy, but it's now awfully close to C#'s convenient x => x+1; just by defaulting things.

• Things I don't like: Having to not support top-level =/== to avoid ambiguity.

• Things I like: My initial reaction to -> expr; is that just reads nicely as "returns expr".

But I'm definitely open to disconfirming opinions and experience, hence a Discussion... I would especially welcome examples that are badly surprising/misleading or would be actual pitfalls in this syntax. The spirit of science is "experiments are good, disconfirmation is good." Thanks in advance for your feedback, pro or con.

[JohelEGP]

In case someone might suggest doing away with the arrow ->,
I agree with this extract from #618 (comment):

I realized that the -> is grammatically redundant in the declaration syntax -- for a while I omitted it. But it felt like the -> had readability value (and follows Cpp1 and most languages). In particular, separating the parameter list and the return value list was visually important.

[JohelEGP]

• Things I don't like: Having to not support top-level =/== to avoid ambiguity.

• Things I like: My initial reaction to -> expr; is that just reads nicely as "returns expr".

The first is due to not making the second's -> also optional.
:(x) x==0; could be equivalent to
:(in x: _) -> _ = x==0;.

[AbhinavK00]

So,
: (x) x == 0; is a deduced return type but
f : (x) {x == 0; } is a void return type.
I don't think correctly understand your suggestion, but that's what I got from it. Please correct me

[JohelEGP]

f: (x) = { x == 0; } is an error if == returns non-void.

[filipsajdak]

My only concern was about symmetry between named and unnamed functions. #257

If the syntax will be the same for both I will be happy not to write additional characters 🙂

[hsutter]

The first is due to not making the second's -> also optional.

💡💡 👍

And so the -> still serves a major purpose as a marker, but now more than just visual: Its absence is a signpost. Nice, let me try that...

[hsutter]

OK, that hits the sweet spot, thanks @JohelEGP ... as soon as I did it without the -> (in the defaulted syntax only), I could rip out most of the code I'd just added because the special cases all went away, and as a bonus it passed all regression tests the very first time which is a good sign it's a more stable change. And this would not have been possible (or at least not as easy) if the -> wasn't there in the general case grammar.

Thanks for the feedback, everyone! This is an experiment worth trying...

[msadeqhe]

Also : can be dropped:

: (a) -> a
(a) -> a;

In this way, the meaning of -> depends on if it comes after : or not.

// -> is after : so it's a return type.
: (a) -> int = a

// -> is not after : so it's a return value.
(a) -> a

For example:

call(param, (a) -> a);
x: = (a) -> a;

[hsutter]

Data point: I decided to add test cases by simply searching for -> _ in the test cases, and it turns out that I could eliminate all of the -> _ because they were all -> _ = expr; one-liners. That won't always be true, of course, but I think it's indicative that this will be a useful way to reduce ceremony.

A good sign is that when I changed the test code, they all worked perfectly on the first try. So that's some data point that it's easy to spell correctly.

The very first one was kind of fun because it actually had two such nested one-liners(!) plus a capture, and I felt a little anxious as I hit Compile for it, but it Just Worked on the first try:

//  Previously, most of the ceremony was required
less_than: (value:_) -> _ =
    :(x:_) -> _ = x < value$;

//  Now allowed as equivalent, by allowing accepting defaults
//  via omitting unused parts of the syntax
less_than:(value)  :(x) x < value$;

It's a little terse, but I don't think it's too much less readable than the "previously" version. And now that I see code like :(x) x < value$;, I love it visually because it looks like, and really is, just a general parameterized expression. That is, :(x:_) -> _ = x < value$; looks like it's primarily a function (that feels like the visually dominant part of the syntax) that happens to have a terse body, but :(x) x < value$; really looks to me like it's primarily an expression (that's most of the syntax) that happens to be parameterized and callable. And of course both views are true, but I like that the latter one is an emergent "feel" to the language. To me that resonates well with how we have general parameterized statements already.

[hsutter]

Also : can be dropped:

That's true, but I'm trying very hard to stick with ": is used always and only to declare a new thing" as a cornerstone. Its position up front makes it clear "something is being declared here" especially at expression scope when there's no name before the colon. Let's see if there turn out to be problems with the experiment of just omitting the -> _ = sequence which is a nice local default, and if there are issues that emerge down that path we can backtrack and revisit.

Thanks for this and all the input!

[ljleb]

I am a bit late here, however here's my intuition about this (which I concede could be totally wrong):

• -> ... is punctuation for return type
• = ... is punctuation for function body

Has this terser form been considered? (with or without the nested semicolon)

std::transform(in1, in2, out1, :(x) = x+1;)`

I'm not very familiar with the parsing priority of existing punctuation nor the potential ambiguities this could create. I have not seen anyone mention this here, so I wanted to see how much this is worth. Maybe it's been considered in a different thread, I might have missed it in this case.

[JohelEGP]

This looks like a good time to talk about constexpr.

If we had to backtrack defaulting ->, maybe we could instead not default =.
Then we could write == instead of = for constexpr.

In fact, it'd be convenient if we could do that with the tersest syntax.
As it stands,
less_than:(value) :(x) x < value$; would be have to be written as
less_than: (value) -> _ == :(x) x < value$; to support constexpr.
If we could instead write it as
less_than:(value) == :(x) x < value$; then it might be better.
But perhaps there would not be enough symmetry between == and the lack of it.
So we could instead always require the =:

• less_than:(value) = :(x) = x < value$; returns a constexpr callable, but isn't constexpr itself.
• less_than:(value) == :(x) = x < value$; returns a constexpr callable, and is constexpr itself.

What do you think?
I think that's OK, because constexpr should be opt-in.

[hsutter]

• :(x) = x < value$;

This is what I originally had. The push-back I got on this in issues/comments here was that it required making the default return for a function be -> _ when the function has no name, vs. -> void when it has a name. People here argued (persuasively) that it was undesirable to have different defaults in different places for the same syntax.

I don't think that it's bad for a default to default to exactly one common case. You can always write the general case out longhand. For example, the terse syntax also doesn't allow writing contracts, which is fine... to write contracts just use those additional parts of the syntax where the contracts go.

For completeness: I'm aware of the counterargument that a default that defaults to exactly one common case can be considered undesirable. Notably, Bjarne has long opposed a terse lambda parameter syntax where (x) means Cpp1 (auto x) on the grounds that auto is unconstrained, and making it the easy default encourages programmers not to write concepts constraints (e.g., (iterable x)). I understand that position, and it's a cost/benefit tradeoff: clearly terse syntax is good for usability, and clearly concepts constraints are good for diagnostics. I just come down on the other side: In this case I think usability for the common case is more important. So in Cpp2 I'm trying out what was proposed in a number of ISO C++ proposals, to make the parameter list (x) legal and an unconstrained generic parameter.

In this case, I think a default that defaults to not-constexpr, especially at expression scope, is reasonable. It's a good tradeoff to keep in mind though, and be ready to reevaluate if we find disconfirming usage experience!

Thanks!

[JohelEGP]

The current default is -> void (in non-terse syntax).
Making -> _ the default is a new, interesting one.

[JohelEGP]

#257 (comment) explains why -> void is the default:

• Named functions default to -> void, not a deduced type, because named functions want to be order-independent, deduced return types inhibit full order-independence, and so we don't want that to be the default for most functions.

[ntrel]

it required making the default return for a function be -> _ when the function has no name, vs. -> void when it has a name

How about requiring braces :() = { expression; } when return type inference is not wanted? I.e. don't have an = statement form. Only = expression which infers return type if not given, and = blockStatement. Like C#, D and probably other C-like syntax languages. So -> T, { return and ; } can all be omitted together from the general block-statement form. It would mean we no longer need to write = expression; with a trailing semi-colon, which looks strange when the literal is a function argument rather than variable initializer.

[hsutter]

Quick ack: Making -> _ deduced return types the default for namespace- and type-scope functions (as it is today for auto-declared trailing return syntax functions) feels problematic because it requires callers to be aware of the implementation details. And that's fine and useful, but it's more work at compile time and occasionally more brittle to changes in the function body, so it should be opt-in I think. The reason I made it the default for local anonymous functions (lambdas) at first was because they're inherently local and inline anyway so don't really hit the composable-at-scale issues.

[JohelEGP]

In this case, I think a default that defaults to not-constexpr, especially at expression scope, is reasonable.

By the semantics of a lambda, those are always constexpr at function scope.

[JohelEGP]

Here's some feedback on https://github.com/hsutter/cppfront/wiki/Design-note%3A-Defaults-are-one-way-to-say-the-same-thing.

Resolved

f:(x: int = init) = { ... }     // x is a parameter to the function
f:(x: int = init) = statement;  // same, { } is implicit

 :(x: int = init) = { ... }     // x is a parameter to the lambda
 :(x: int = init) = statement;  // same, { } is implicit

  (x: int = init)   { ... }     // x is a parameter to the block
  (x: int = init)   statement;  // same, { } is implicit

                    { ... }     // x is a parameter to the block
                    statement;  // same, { } is implicit

Only the third one currently permits a default argument.
The last one has no x parameter (the comment).

(copy x:int = f()) for x>1 next x--    // K&R C: for (int x = f(); x>1; --x)

That doesn't work: https://cpp2.godbolt.org/z/Ye5znPaYf.
IIRC, the loop has to be written as while x>1 next x-- (i.e., just replace for with while).

Resolved

Lastly, s/like like/be like/.

[JohelEGP]

It might also be worth mentioning the this. default from #274 (comment).

[JohelEGP]

(copy x:int = f()) for x>1 next x--    // K&R C: for (int x = f(); x>1; --x)

That doesn't work: https://cpp2.godbolt.org/z/Ye5znPaYf.
IIRC, the loop has to be written as while x>1 next x-- (i.e., just replace for with while).

Only this remains.

[AbhinavK00]

This could be one unpopular opinion but one experiment could be to have a consistent, verbose as needed syntax for functions and an another very terse syntax. Like from this paper P0573 or this blogpost.
Regarding the paper, you can also refer to this blogpost.
This way there'll be two very different syntaxes (which is undesirable I know) but I think it's better than omitting tokens from current syntax and having seemingly different defaults but that's just me.

[JohelEGP]

and having seemingly different defaults but that's just me

I suppose you're referring to the fact that
omitting the return-type results in a -> void default,
whereas it's -> _ for the terse syntax.

https://github.com/hsutter/cppfront/wiki/Design-note%3A-Defaults-are-one-way-to-say-the-same-thing#more-design-rationale
explains that the terse syntax is for a generic function with -> _.

[AbhinavK00]

Yes, but I still don't get it. Maybe removing the = helps but most languages seem to have completely different syntax for lambdas and functions and it works fine. Here's an excerpt from P2672

Expression   Language
|e| e < 0	Rust
e -> e < 0	Java
e => e < 0	C# 3, JavaScript, Scala
\e -> e < 0	Haskell
{ |e| e < 0 }	Ruby
{ e in e < 0 }	Swift
{ e -> e < 0 }	Kotlin
fun e -> e < 0	F#, OCaml
lambda e: e < 0	Python
fn e -> e < 0 end	Elixir
[](int e){ return e < 0; }	C++
func(e int) bool { return e < 0 }	Go
delegate (int e) { return e < 0; }	C# 2

-------------------------------with placeholders
_ < 0  Scala (and Boost.HOF)
_1 < 0  Boost.Lambda (and other Boost libraries)
#(< % 0)  Clojure
&(&1 < 0)  Elixir
{ $0 < 0 }  Swift
{ it < 0 }  Kotlin

All i'm saying is that different things should look different. Maybe they look different enough when after removing -> _ = but this suggestion can also be considered.

[gregmarr]

From a CppCon ranges talk.
C++20

auto after = ranges::views::drop_while(v,  [](int i) { return i % 2 == 0; });

Cpp2 with this compact syntax, I think:

:after = ranges::views::drop_while(v, :(i) i % 2 == 0);

Looks good.

[JohelEGP]

// Somewhere, `using namespace std::ranges::views;`.
after := v.drop_while(:(i) i % 2 == 0);

looks better,
after := v.drop_while(is_even);
looks best.

[gregmarr]

// Somewhere, using namespace std::ranges::views;.

The speaker did have rng as a namespace alias for std::ranges, and may have had a views alias on another slide, not sure.

I am not sure why I was thinking :after =. Definitely after :=. Comes from not writing Cpp2 yet I guess. Maybe once the docs work starts (number one request in a poll in the open content session today), I'll remember the syntax options better.

Also, I'm not sure which I prefer:

after := v.drop_while(:(i) i % 2 == 0);

or this one:

is_even := :(i) i % 2 == 0;
after := v.drop_while(is_even);

I'm leaning towards the first one, given that it's only used once, and unnecessarily leaves around a name if you declare it separately.

[gregmarr]

regression-tests/pure2-more-wildcards.cpp2

Okay, I'm writing down how I am working out how I parse this as a human. Am I understanding this correctly?

less_than: (value)  :(x) x < value$;

Going back to the previous form for some help:

less_than: (value:_) -> _ =
    :(x:_) -> _ = x < value$;

less_than is a named function that takes a single parameter of any type. It returns a lambda that takes a single parameter of any type. That lambda returns whether or not that value is less than the argument passed to less_than, which was captured by value.

So in the original, with fewer clues due to the lack of -> _ = , less_than: (value) introduces a function that takes a single parameter, because [<name>]: ( can only introduce a function. The value) closes the parameter list without a type, so it's implicitly any. Since it's not followed by ->, it's a function returning any. What follows next must be a single statement, and the result of that statement is returned.

Following the above, the statement begins with : ( so it's an unnamed function. The x) then says it has a single any parameter. Since it's not followed by ->, it's a function returning any. What follows next must be a single statement, and the result of that statement is returned. That statement is x < value$ where value$ is the captured value from the original call to less_than(). The ; closes both the statement defining the lambda, and the statement returning the lambda, finishing the named function definition.

[JohelEGP]

Except that it's not any, but deduced types.

[gregmarr]

I was thinking that any was short for deduced type or wildcard or something like that.

[msadeqhe]

Another option is to make the default return type dependent to the right-side of = (the function difinition). If the function is defined with statement, its default return type would be void, but if the function is defined with expression, its default return type would be _.

So in these cases, the return type would be void, because the function and the lambda are defined with ststement:

a: (x) = { print(x); } // -> void
call(: (x) = { print(x); }); // -> void

But in these cases, the return type would be _, because the function and the lambda are defined with expression:

a: (x) = x; // -> _
call(: (x) = x); // -> _

It's natural that the programmer expect to return something from the function when it's defined with expression. On the other hand, naturally we expect to explicitly declare a return type for functions which are defined with statement, otherwise they are expected to return void.

Also the behavior and syntax would be the same for both functions and lambdas.

[JohelEGP]

Sounds fine to me,
specially considering that we can author namespace scope terse syntax functions
even thought they're not order-independent.

[msadeqhe]

@JohelEGP, I've to say that I like :(x) x (your suggestion) more than :(x) = x if we also have :(x) x syntax for namespace scope functions with the same rule of making the return type void for statement block and _ for expression:

// return type is _
function: (x) x;

// return type is void
say: (x) { print(x); }

// return type is void
alt: (x) {
    print(x);
}

So the syntax of function declarations would be changed.

In a nutshell within function/lambda declarations, the default return type for statements would be void, and the default return type for expressions would be _ (the type of expression).

With explicit return type:

// expression with explicit return type is ugly or virtually ambiguous
one: (x) -> _ x;

// statement block with explicit return type is nice too
exp: (x) -> void {
    print(x);
}

[SebastianTroy]

So how many ways do we have to spell a function now?

Functions

isEven: (in x: int) -> bool = { return x % 2; }
isEven: (x: int) -> bool = { return x % 2; }
isEven: (x: int) -> _ = { return x % 2; }
isEven: (x: int) -> x % 2;
isEven: (x: int) -> { x % 2; } // ???

Expressions

n: int = rand();
foo( :(in x: int) -> bool = { return x % 2; }(n)  );
foo( :(x: int) -> bool = { return x % 2; }(n)  );
foo( :(x: _) -> bool = { return x % 2; }(n)  );
foo( :(x) -> bool = { return x % 2; }(n)  );
foo( :(x) -> _ = { return x % 2; }(n)  );
foo( :(x) -> x % 2;(n)  ); // ???

Are there any more? (Or fewer because I've made mistakes?)

[YagaoDirac]

My basic idea about syntax designing:
1, what happen if you search something in google or bing. Imagine this is your 10th day in cpp2, and you see something like "next:(i) -> i+1;", and you google "next:(i) -> i+1; cpp2 cppfront", can you guaguntee the results contains anything about the function syntax.
2, It's always good to have as less way as possible to do the same thing. If we have 18 ways to init objects, we have to learn at least 5 of them so we can make sure we at least understand the code. But when it's function, every detail is so important, people really have to learn every detail. Learning is expensive. If you really want to omit something, add as less rules as possible.
3, I don't think we need a seperated syntax for inline function definition(lambda exp). 1 syntax is enough imo.
4, readability, also writability. -> is hard to type. Maybe === or >>> is better.
5, I'm about to write a new discussion on the type system(yeah, type system again) that idea helps with this discussion a bit. In every scope, there is always a fixed "by default set". If memory model is also part of the type system, and can be cout explicitely, it's easy to learn and all the convention relationship will be clear.

[DyXel]

Came back to this discussion after reading this:

cppfront/regression-tests/pure2-more-wildcards.cpp2

Line 2 in c9a007c

less_than: (value) :(x) x < value$;

Not a big fan of having a named declaration that seemingly looks forward declared, but actually has a "value" associated with it (the body of a function), I think the = has a very important meaning, every piece of code I've read or written in cpp2 so far always had the structure of x: T = v, functions seem to be the exception now. Fully agreed with #714 (comment) , how terse is too terse? do you really need to save the extra characters? specially when languages like Python do just fine with a whole keyword for it (lambda).

A little bit ranty but I hope I have never to teach that declaring a name like this, without the =, still yields a name with a value. I also hope I never have to review code like this; That one liner to me is more unreadable than reading the generated cpp1 code, which is not a good sign.

[DyXel]

This goes hand-in-hand with #857 (comment).
The check for error: unused literal or identifier is erroneously not being considered (a bug).

It's good to hear that f3 seems to be a bug, but I don't think it matters for t_f3; The original example from pure2-more-wildcards.cpp2 doesn't use the = at all, which is what my argument is mostly about.

The only similarity of a Cpp2 block and a Cpp1 initializer list are the characters {}.
I don't think it makes sense to expect Cpp2's f3 to have a block
because the lowered Cpp1 for v2 uses list-initialization.
This is an implementation detail of cppfront, which lowers Cpp2 to Cpp1.

Not sure if I understand, f3 doesn't have a block in my example. In any case, I would gladly accept keeping {} just for function bodies and () just for value-type initialization.

No, it's just that the default that allows omitting -> _ = { return ; } only applies to functions.

the only applies to functions. bit is exactly what I am arguing, why would it only apply to functions in this case? its a step in the opposite direction of generalization in my opinion, and if you take it Ad infinitum, then you'd end up with #714 (comment) .

[JohelEGP]

The syntax is already general.
It's name: signature = initializer or name: signature;.

Although the syntax is the same, they entities they declare aren't.
A function is still not the same as a variable.
You have already described some semantic differences
(it's not only the specific syntax, e.g., what signature can be for a specific entity).

Now we've gone in the other direction and specialized the syntax for functions.
That comes with great benefits (search the design note for "demand").

There's little to gain applying the same specialization to other entities.
At least, I can't recall for "demand" in that space.

[DyXel]

So, I believe this:

Although the syntax is the same, they entities they declare aren't.
A function is still not the same as a variable.

Is the feeling of discrepancy that I have; It comes from lack of considering the body of a function a value for a type, and more considering its body, parts of the type (if that makes sense?), at least according to function syntax + block statements design note, which doesn't mention initializing at all.

To me, a function body is merely the instantiated value we give a specific function signature (the type itself):

f: (x: int) -> int = { return x * 42; }

This reads to me as: a variable with name f of type (int) -> int is being assigned/initialized with the value of { return x * 42; }. Therefore, doing this instead should be equivalent (since lambdas with no captures are implicitly convertible to functions):

f: (int) -> int = :(x: int) -> int = { return x * 42; };

(today this doesn't compile in cppfront as limitation, but the equivalent cpp1 code should work).

This whole view makes a lot more sense when you think about function bodies as data, and their signature just as an interface, like any other type, really:

v := :std::string_view =  "Hello"     ;
f := :(x: int) -> int  = { return 0; };

Here a stringview's data is Hello, the function's data is { return 0; }. These 2 spell the same thing, its just that function need the braces today. But the tersest lambda syntax defies this notion, you are visually associating the body of the function to the signature of the function, which is misleading IMO (on top of not spelling = for initialization which I consider the most important part).

As for what's the benefit of having this mindset? Well, to me, it is merely the generalization that everything is data, for example, have you ever thought how jit-ting works? It is merely ASM code in memory that is marked as executable and jumped to. How is this jump done? You make sure you get the ABI right, cast the start of the buffer to the right function pointer, and call said function! (and beneath, functions are just that, a pointer to a specific point in memory where instructions live, which is just data).

[JohelEGP]

Therefore, doing this instead should be equivalent (since lambdas with no captures are implicitly convertible to functions):

f: (int) -> int = :(x: int) -> int = { return x * 42; };

(today this doesn't compile in cppfront as limitation, but the equivalent cpp1 code should work).

A non-capturing closure is convertible to a function pointer.
f is a function, not a function pointer.
See https://cpp2.godbolt.org/z/dWPG7zq3j for what this really does.

[DyXel]

Thanks for the link, weird, when I do the exact same syntax but inside a function (main in this case), I get a totally different error (which is why I assumed its not implemented):
main: () = { f: (_: int) -> int = :(x: int) -> int = { return x * 42; }; } gives me:

error: (temporary alpha limitation) local functions like 'f: (/params/) = {/body/}' are not currently supported - write a local variable initialized with an unnamed function like 'f := :(/params/) = {/body/};' instead (add '=' and ';')

But you are right, it should be a function pointer, in practice, it means little since all these work just fine (again this comes from usability perspective, not language-lawyer perspective):

#include <iostream>

using function_signature = void(int);

void my_func(int x) {
	std::cout << "other " << x << '\n';
}

int main() {
	function_signature* a = [](int x) -> void {
		std::cout << x << '\n';
	};
	a(42);
	(*a)(10);
	auto& b = *a;
	b(100);
	a = &my_func;
	a(150);
	a(200);
	my_func(300);
	(*(&my_func))(400);
	return 0;
}

Anyways, I have discussed the topic enough; I know that our mindsets might fundamentally differ on how we look and interpret the code, my hope is to make this data point visible to Herb and the rest to aid making the best possible design. To be honest I don't think the current tersest lambda syntax will grow on me, but also, since Cpp2 grammar is orders of magnitude simpler than Cpp1's, I guess writing a tool (akin to clang-tidy) that bans/auto-formats that specific syntax would not be unthinkable to do.

[YagaoDirac]

The only issue I can imagine is that, how does the IDE provide a hint with type info.
Let's say the "f:(i) -> i+1;". i can be any number, string, or anything that pluses with int32.
Or do we get "f:(i:)->" as the hint? Maybe it's a bit too loose.

[JohelEGP]

The return type starts with ->, so that's the hint.

[svew]

A wild suggestion I haven't seen in this thread yet: What if you combine them?

-> denotes "This function has this returned type"
= denotes "This function will execute this expression/block"
=> denotes "The returned type (and value) of this function is the result of this expression/block"

I don't imagine this will be a popular idea, but I thought it was kinda fun.

[MaxSagebaum]

I like the idea.

[svew]

Replying to what @SebastianTroy mentioned, I do worry about ambiguity one we start shaving off too many context markers. It's definitely a strength of cpp2 that we're able to shave away default markers when they aren't needed, but at a certain point you reach an ambiguous or confusing point.

If we say that the thing after -> can be an expression or a type, then you now have a place where you need context to resolve this function definition. If I say take_callback(:() -> x), is x a variable or a type? Your intellisense doesn't know if this function definition is complete unless it has already parsed everything else and determined whether x is a type, a local variable, or a global.

I have a different concern with minimizing to =. If = is followed by a block statement, then that is the body of a function. If = is followed by an expression, that expression is evaluated immediately, and its result is assigned to whatever is to the left of the =. So consider the following lambda function: :() = other_func(). Is other_func() being called immediately, like with all other expressions following =? Or is it deferred, because there's an invisible block statement around it and because we're defining a function?

[svew]

Actually, it's possible we could use => to help make some very clear distinctions:

=: The following code will be executed immediately
=>: The following code will be executed on demand (lazily, deferred, when called, etc.)

With this distinction, a fully expanded function would use => instead of =:

clamp: (x: int) -> int => { return x < 0 ? x : 0; }    Starting point
clamp: (x: int) -> int =>          x < 0 ? x : 0;      Replace block with expression
clamp: (x: int)        =>          x < 0 ? x : 0;      Remove `->`, return type inferred from expression following `=>`
                                                       A nice little simple function!

clamp: (x: int) -> int => { return x < 0 ? x : 0; }    Starting point
clamp: (x: int) -> int    { return x < 0 ? x : 0; }    Remove `=>`, inferred by function definition `:() ->` 
                                                       Still looks like a regular function definition!

Both simple lambdas and member functions will still look very normal:

list.sort(:(item) => item.value);

count := 0;
add_listener(:(event) => count$ += 1); // Anything following `=>` defined outside of its context should be captured

vec: type = {
    m_size: int = 0;

    size: () => m_size; // Could maybe reduce to `size :=> m_size` for deferred property access?
                        // For explicit return type, use `size: int64_t => m_size`
                        // Or maybe `size: -> int64_t => m_size`
    push: (item: X) {
        ...
    }
}

It also means in the future we can count on the distinction between = and => for new features, like if we wanted to add Zig's defer:

func: () {
    defer => if (error_occurred$) { unload_resource(); }
}

Or general lazy evaluation:

resource: std::call_once => load_resource(path$);    // std::call_once is a bit more complicated than this,
                                                     // but we can dream
if (do_load) {
    process(resource());
}

[DyXel]

That is more or less C#'s lambda syntax, except there sometimes you can skip parenthesis. My only concern with this is that it can potentially clash with operator=>, the implication operator in the future, but no idea if that will ever make it to C++. I guess it would be unambiguous in the sense that if you have : followed by a => it can only ever mean a function (if there are parenthesis) or "deferred evaluation" as you put it. It could work.

[SebastianTroy]

I like this as long as a function or lambda requires either one of -> or => for really clear signposting at a glance. Your idea also frees up "(x, y, z) = thing" for unambiguous structured binding/assignment. On another note, to keep banging my drum in this thread... You don't read code, you parse it, and the more signposts you have, the easier it is to parse at a glance. In my opinion, the overuse of () as signposts is already making cpp2 harder to parse mentally, as they are contextual, even if it doesn't take that long, it should still be something that could be achieved at a glance without thinking. I know that cpp2 has context free parsing, but there's a difference between knowing there is a way to figure it out, and being able to do that as a human at speed, repeatedly & reliably. On 29 January 2024 01:53:40 Walter ***@***.***> wrote: A wild suggestion I haven't seen in this thread yet: What if you combine them?? -> denotes "This function has this returned type" = denotes "This function will execute this expression/block" => denotes "The returned type (and value) of this function is the result of this expression/block" I don't imagine this will be a popular idea, but I thought it was kinda fun. — Reply to this email directly, view it on GitHub<#714 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQOS6MLIWSVORRN4PR3YQ36KDAVCNFSM6AAAAAA5N5GVZCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DENZVHE2TG>. You are receiving this because you commented.Message ID: ***@***.***>

[svew]

After the recent midsummer update, I've been thinking about the current terse syntax again, and I wanted to write down a few thoughts I have about the current format:

:(x, y) x > y

Please let me know if I'm off base

Having no = is a special case

Like mentioned before by @DyXel, the fact that this has no = at all is a deviation from the standard way of defining things. We talk about how cool it is that we can decompose type definitions and function definitions to omit parts that aren't necessary, such as this:

x: int = 5;
x: _ = 5;
x := 5; // Wow neat!

But the decomposition being proposed allows one to omit the assignment, when you have a type (function type) defined:

fn: (x, y) -> _ = x > y;
fn: (x, y) x > y;     // No assignment?

If we're able to omit the assignment, shouldn't we be able to write:

x: int 5;   // This?
x: 5;       // Or even this?
fn(:int 5, :int 7); // Bonus thought, should this be allowed?

The : and = combo seems very powerful to me. It makes sense that you should declare with :, and define with = in every case. Sometimes we redefine by only using =, and sometimes we declare prior to defining by only using :. But why have these special situations where it's possible to define without using =?

Why does adding = necessarily create a special case?

There was some discussion about the terse format of :(x, y) = x > y, and how it means that these two functions implicitly have different return types:

fn: (x) = std::cout << x; // Implicitly returns nothing, -> void
:(x) = std::cout << x; // Implicitly returns the stream, -> _

Which does create an undesired situation where the act of naming this function changes its return type. But I have to admit, I don't see the reason why we can't say that the { } block is part of the type deduction:

fn: (x) = { std::cout << x; } // Returns nothing, -> void
fn: (x) =   std::cout << x;   // Returns the stream, -> _
:(x) =    { std::cout << x; } // Returns nothing, -> void
:(x) =      std::cout << x;   // Returns the stream, -> _

Is there a reason this wouldn't make sense?

[DyXel]

I don't think this:
main: () = std::cout << "Hello, world!\n";
is very desirable syntactic sugar.

I beg to differ, check reflect.h2, it really improves readability by a ton imo, it makes authoring short member functions shorter and concise, I think its a big plus if you ask me.

I'm completely in favor of replacing this with any of the below, in the name of simplifying the language:
// then our lambdas can look like this:

The whole point of people who are currently against this tersest lambda syntax, is that it shouldn't need to exist, a lambda should just be a function minus the name. You should be able to use the same function syntax everywhere with no changes. What is simpler than 1 single unified function syntax that works the same everywhere? That is the big picture, keeping the = is just consistency with the rest of language's way of declaring any entities (types, aliases, variables, etc.).

[simeonKuran]

I don't think this:
main: () = std::cout << "Hello, world!\n";
is very desirable syntactic sugar.

I beg to differ, check reflect.h2, it really improves readability by a ton imo, it makes authoring short member functions shorter and concise, I think its a big plus if you ask me.

Can you elaborate more on this? Do you think, there are a lot of functions returning void, where readability would significantly suffer, if curly braces need to be added?
Or did you mean it differently?

I am glad, that the whole discussion is raised again. I totally agree, that the tersest syntax should be consistent to the other ways how to define a function (or a lambda). In my point of view, the equal sign should be mandatory also for the tersest syntax.
Because of both, consistency and readability.

[DyXel]

Can you elaborate more on this? Do you think, there are a lot of functions returning void, where readability would significantly suffer, if curly braces need to be added?
Or did you mean it differently?

I mean it literally, take this excerpt:

    index_of_parameter_named     : (this, s: std::string_view) -> int  = n*.index_of_parameter_named(s);
    has_parameter_named          : (this, s: std::string_view) -> bool = n*.has_parameter_named(s);
    has_in_parameter_named       : (this, s: std::string_view) -> bool = n*.has_in_parameter_named(s);
    has_copy_parameter_named     : (this, s: std::string_view) -> bool = n*.has_copy_parameter_named(s);
    has_inout_parameter_named    : (this, s: std::string_view) -> bool = n*.has_inout_parameter_named(s);
    has_out_parameter_named      : (this, s: std::string_view) -> bool = n*.has_out_parameter_named(s);
    has_move_parameter_named     : (this, s: std::string_view) -> bool = n*.has_move_parameter_named(s);
    has_forward_parameter_named  : (this, s: std::string_view) -> bool = n*.has_forward_parameter_named(s);
    first_parameter_name         : (this) -> std::string               = n*.first_parameter_name();

If we imagine that the whole "omitting braces" thing didn't exist, we would need to write this instead:

    index_of_parameter_named     : (this, s: std::string_view) -> int  = { return n*.index_of_parameter_named(s); }
    has_parameter_named          : (this, s: std::string_view) -> bool = { return n*.has_parameter_named(s); }
    has_in_parameter_named       : (this, s: std::string_view) -> bool = { return n*.has_in_parameter_named(s); }
    has_copy_parameter_named     : (this, s: std::string_view) -> bool = { return n*.has_copy_parameter_named(s); }
    has_inout_parameter_named    : (this, s: std::string_view) -> bool = { return n*.has_inout_parameter_named(s); }
    has_out_parameter_named      : (this, s: std::string_view) -> bool = { return n*.has_out_parameter_named(s); }
    has_move_parameter_named     : (this, s: std::string_view) -> bool = { return n*.has_move_parameter_named(s); }
    has_forward_parameter_named  : (this, s: std::string_view) -> bool = { return n*.has_forward_parameter_named(s); }
    first_parameter_name         : (this) -> std::string               = { return n*.first_parameter_name(); }

I wasn't a big fan of omitting the braces before but I have to admit I have a changed my mind after reading all of this code, and writing some more myself. I think that is a stroke of genius design from Herb, the second version just look unnecessarily busy in comparison.

[svew]

take this excerpt:

    index_of_parameter_named     : (this, s: std::string_view) -> int  = n*.index_of_parameter_named(s);
    has_parameter_named          : (this, s: std::string_view) -> bool = n*.has_parameter_named(s);
    has_in_parameter_named       : (this, s: std::string_view) -> bool = n*.has_in_parameter_named(s);
    has_copy_parameter_named     : (this, s: std::string_view) -> bool = n*.has_copy_parameter_named(s);
    has_inout_parameter_named    : (this, s: std::string_view) -> bool = n*.has_inout_parameter_named(s);
    has_out_parameter_named      : (this, s: std::string_view) -> bool = n*.has_out_parameter_named(s);
    has_move_parameter_named     : (this, s: std::string_view) -> bool = n*.has_move_parameter_named(s);
    has_forward_parameter_named  : (this, s: std::string_view) -> bool = n*.has_forward_parameter_named(s);
    first_parameter_name         : (this) -> std::string               = n*.first_parameter_name();

Actually, with what I'm proposing, this all works perfectly fine. My point is that if you're going to remove the braces, then what follows is now an expression, and should be interpreted as an expression, not as a statement within an invisible block.

My problem is that if you took one of the above lines, and removed the return type specifier:

index_of_parameter_named: (this, s: std::string_view) -> int = n*.index_of_parameter_named(s);
index_of_parameter_named: (this, s: std::string_view)        = n*.index_of_parameter_named(s);

That by (my understanding of) the current rules of cpp2's syntax, n*.index_of_parameter_named(s); is no longer recognized as an expression, but as a statement within an invisible block, and therefore index_of_parameter_named now has return type void instead of int. I don't think that is desirable. The example you posted is absolutely something I like

[DyXel]

That by (my understanding of) the current rules of cpp2's syntax, n*.index_of_parameter_named(s); is no longer recognized as an expression, but as a statement within an invisible block, and therefore index_of_parameter_named now has return type void instead of int. I don't think that is desirable. The example you posted is absolutely something I like

Ah, I get you now. Yeah, if you write a single expression while omitting -> void, the expression after the = will not lower to the expected { return expression; }. but if you do explicitly say -> void instead, it does add the return, that means that these 2 programs are not equivalent when they ought to be (in my opinion):
main: () = std::cout << "Hello, world!\n";
main: () -> void = std::cout << "Hello, world!\n";
(former compiles, latter doesn't)

[SebastianTroy]

All good points IMO On 1 August 2024 05:51:13 Walter ***@***.***> wrote: After the recent midsummer update, I've been thinking about the current terse syntax again, and I wanted to write down a few thoughts I have about the current format: :(x, y) x > y Please let me know if I'm off base Having no = is a special case Like mentioned before by @DyXel<https://github.com/DyXel>, the fact that this has no = at all is a deviation from the standard way of defining things. We talk about how cool it is that we can decompose type definitions and function definitions to omit parts that aren't necessary, such as this: x: int = 5; x: _ = 5; x := 5; // Wow neat! But the decomposition being proposed allows one to omit the assignment, when you have a type (function type) defined: fn: (x, y) -> _ = x > y; fn: (x, y) x > y; // No assignment? If we're able to omit the assignment, shouldn't we be able to write: x: int 5; // This? x: 5; // Or even this? fn(:int 5, :int 7); // Bonus thought, should this be allowed? The : and = combo seems very powerful to me. It makes sense that you should declare with :, and define with = in every case. Sometimes we redefine by only using =, and sometimes we declare prior to defining by only using :. But why have these special situations where it's possible to define without using =? Why does adding = necessarily create a special case? There was some discussion<#257> about the terse format of :(x, y) = x > y, and how it means that these two functions implicitly have different return types: fn: (x) = std::cout << x; // Implicitly returns nothing, -> void :(x) = std::cout << x; // Implicitly returns the stream, -> _ Which does create an undesired situation where the act of naming this function changes its return type. But I have to admit, I don't see the reason why we can't say that the { } block is part of the type deduction: fn: (x) = { std::cout << x; } // Returns nothing, -> void fn: (x) = std::cout << x; // Returns the stream, -> _ :(x) = { std::cout << x; } // Returns nothing, -> void :(x) = std::cout << x; // Returns the stream, -> _ Is there a reason this wouldn't make sense? — Reply to this email directly, view it on GitHub<#714 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQPD62KU3CFPBWSIXOLZPG5D3AVCNFSM6AAAAAA5N5GVZCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMRQG44TKMA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[hsutter]

Here and on Reddit and other places I keep seeing resistance especially to the lack of = in :(x,y) y<x.

At some point (which I think is now), that amounts to a reason to reconsider.

Here's a VERY DRAFT table of major cases, what they mean today, and a possible alternative that mirrors some of the suggestions. Disclaimer: It's late at night and I've been rereading all the cells enough times to see what I expect to see, so there may be errors (please point them out!), but I think it's pretty close.

Notes:

• The Cpp1-spelling -> decltype(auto) means deducing -> T or -> forward T based on whether the expression is a value or is a Cpp1 reference / Cpp2 forward-return. Until now there's been no deduction/default for -> forward T, which in this table occurs only in "Reference return" case 5.
• Case 7 (omitting =) wouldn't be allowed in the new column.
• Yellow highlight means a benign change that doesn't really change meaning (I think).
• Green highlight means a semantics change, but a good one (I think).

What do you think?

[hsutter]

Can we just use the same rule here as for cpp1 lambdas? Is there something broken there that you're trying to fix?

If you mean that lambdas return -> auto by default: IIRC that's where I started, having unnamed functions return -> _ by default, and named functions return -> void by default. I can't remember the whole history now, but there was some push-back or problem with that as an inconsistency, and IIRC to treat functions the same whether they had names or not. That said, new information can make us reconsider that.

[DyXel]

I remember that conversation from #257, but what we are asking is to simply switch the default for both named and unnamed functions to -> auto or -> decltype(auto).

[hsutter]

Also: If I understand your point right, this is one of the reasons I had in mind to suggest "omitting -> means -> void if there are braces, else -> decltype(auto)"... then whether it's a 'lambda' or a named function isn't the issue (all functions consistency work the same way), it's whether it's a single-expression body or not that is the determining factor (which happens to be very popular for lambdas).

[DyXel]

Btw, I am aware of what you wrote here #714 (reply in thread), but if we are considering making it the default in certain cases, could it be a good experiment to go all the way and see if it works?

[DyXel]

it's whether it's a single-expression body or not that is the determining factor (which happens to be very popular for lambdas).

Yeah, and this is what I say is "unnecessarily complex", because if we defaulted to -> _ then this wouldn't need to be considered, as that works out of the box with no-return/void-return deducing to void.

[gregmarr]

@hsutter It took me a while to nail down what was bugging me about your image. There is an error in reference return row 3. The table says auto, return ref => ERROR, but it's actually valid, and it will continue to be valid with the syntax meaning decltype(auto).

funcvoid: (x) -> _ = std::cout << x;

[[nodiscard]] auto funcvoid(auto const& x) -> auto { return std::cout << x;  }

[gregmarr]

if you add a call site like funcvoid("xyzzy"); it will error (in the Cpp1 compiler).

The error is that the copy constructor is deleted. This one doesn't error.

str : std::string = ("");

funcref: (x) -> _ = str.append(x);

main: () = {
    std::cout << funcref("xyzzy");
}

Program returned: 0
xyzzy

Here are a cpp2 CE link with the current behavior and a regular CE link with the generated code and decltype(auto) instead of auto.
https://cpp2.godbolt.org/z/3eYKj6eb3
https://www.godbolt.org/z/G4j7zq6nv

Is there a difference between std::cout << x and str.append(x)? They both produce a reference to the original object.

[hsutter]

The error is that the copy constructor is deleted [for std::cout].
...
Is there a difference between std::cout << x and str.append(x)? They both produce a reference to the original object.

Exactly, that's the difference. -> _ means to return a value. So funcref: (x) -> _ = str.append(x); deduces -> char and that works because we can copy a value from the returned reference. But that doesn't work for the std::cout version because it's asking to return something by value that can't be returned by value because it can't be copied.

[gregmarr]

Ah, it wasn't clear to me that the "reference return" section was solely referring to "things that aren't copyable". I thought it was about returning a reference.

[gregmarr]

So funcref: (x) -> _ = str.append(x); deduces -> char

How exactly does it deduce char from std::string&?

gcc disagrees:

[[nodiscard]] auto funcref(auto const& x) -> auto { return str.append(x);  }

auto main() -> int{
    std::cout << funcref("xyzzy");
}

The std::cout << line compiles to this: (template parameters removed for clarity)

call    std::basic_ostream<>& std::operator<< <>(std::basic_ostream<>&, std::__cxx11::basic_string<> const&)

[hsutter]

Ah, it wasn't clear to me that the "reference return" section was solely referring to "things that aren't copyable". I thought it was about returning a reference.

Thanks for pointing out this is unclear, I need to write that more clearly in the table.

So funcref: (x) -> _ = str.append(x); deduces -> char

How exactly does it deduce char from std::string&?

You're right, mea culpa... I should have said -> std::string, sorry!

[hsutter]

Thanks for the comments. Here is an updated table with (I think?) improvements:

[hsutter]

There is a fourth category though, a type that can both be copied (line 3) and also returned by reference (line 5 and 7).

I don't yet understand: Isn't that covered by "copyable type"?

If you lump that fourth category into the copyable one, then you get a failure to return by reference in line 5

Right, line 5 for "copyable type" is this (with the same error result in the current and proposed rules):

(x) -> forward _ = x > 0;  // -> auto&&, return value => ERROR

and you can't implement T& vector::operator[](size_t index).

I don't understand, this works now?

operator[]: (      this, idx) -> forward _ = _data[idx];
operator[]: (inout this, idx) -> forward _ = _data[idx];

Under the proposed rules, you could additionally omit the -> forward _ and write:

operator[]: (      this, idx: std::size_t) = data[idx];
operator[]: (inout this, idx: std::size_t) = data[idx];

I would expect that when combined with deducing this, that function could be as simple as

    operator[]: (forward this, index) = this._data[index];

I think so, it would let you write one function instead of the in/inout (const/non-const) overloads.

[gregmarr]

Right, line 5 for "copyable type" is this (with the same error result in the current and proposed rules):

(x) -> forward _ = x > 0; // -> auto&&, return value => ERROR

That's exactly the issue I'm looking at. Maybe the issue is that I'm thinking that you are intending that the table is complete and covering all cases, but you are considering that there are other cases such as this one that aren't covered by the table.

and you can't implement T& vector::operator[](size_t index).

I don't understand, this works now?

operator[]: (      this, idx) -> forward _ = _data[idx];
operator[]: (inout this, idx) -> forward _ = _data[idx];

Yes, it works in reality, but according to the table, this is an error for a copyable type, and only works for a noncopyable type. So the table doesn't match reality.

[hsutter]

Quick ack: OK, thanks. Yes, the table is not exhaustive. I think the table does need some better wording then, because the intent is for the table's example to be an error (it's returning a reference to a temporary) and the subscript to continue working (it's returning a reference to a non-local).

[gregmarr]

Yes, the table is not exhaustive.

Okay. I assumed it was because you wanted to evaluate the effect of the rule changes, and thus needed to look at all cases. I think the fourth category would make it exhaustive. Are there any other cases that you know of that aren't covered by the table?

[hsutter]

Well, there are also multi-statement bodies, with and without explicit return.

I was trying to focus on the single-expression/statement cases just because those were the key ones the rule change was trying to address. The multi-statement body cases ought to stay the same as they are now (I hope?).

[hsutter]

Merging replies... based on the feedback (thanks!), I think that the two new rules I suggested are best combined into one: "omitting braces implies a default body of { return expr ; } and a default return type the same as what expr evaluates to: -> forward _ (Cpp1 reference type), -> _, or -> void (i.e., like Cpp1 ->decltype(auto))."

This states things more clearly to show that those are the defaults you get when omitting { }, and that only rows 7 and 9 are affected by the proposed change... basically, row 7 becomes the syntax for (slightly improved) row 9 syntax today.

And then the summary just comes down to saying: "Changed the tersest syntax to add =, plus made it work when the expression yields a reference to a noncopyable object."

I think we may have a winner... here's the updated table:

[DyXel]

FWIW I agree with your rambling, in the future these things should be hopefully not an issue. I am just not sure if it would be completely bulletproof for more complex cases, like, is this "dependency solver" possible in theory? For sure a topic for a different thread, but good food for thought.

[hsutter]

Whereas for unnamed local functions (that stay unnamed and aren't assigned to a local variable or std::function or something to give them a name), these problems disappear: There is no concern about ordering because the point of definition and point of use are the same, they're inline anyway, and there's no worry about stable interfaces (there are no distant call sites because by definition it's written at point of use).

So is "unnamed functions" the proper switch here for decltype(auto) vs void?

That's an interesting observation! Let me think about this.

The only concern I could see right away is that it might make more sense for the presence of { } to change the meaning of a signature, vs. the presence or absence of a name... do you think it would be confusing for language users that the function type and whether/what it returns changes materially if they give it a name, and it's otherwise syntactically identical?

Since we don't have forward declarations yet in Cpp2, I was thinking only about functions where the body is present.

Yes and no: Cpp2 plans to never to have explicit forward declarations, but that's because the generated Cpp1 code always has forward declarations (without bodies) because they're all generated for you, before all the actual function definitions (with bodies).

The inherent problem is that you can write the forward declaration of a function with a deduced return type, but you can't call it until you know the definition because you don't even know what the types are.

The examples above show the problems that remain even after all the forward declarations are written, because in those examples all the forward declarations are generated in the Cpp1 file. So what Cpp2 does today is [edit] comparable to exactly Cpp1 with all the forward declarations laboriously written out manually by hand. (Which is still a much better place with fewer order dependencies than ordinary Cpp1 code without forward decls though. For example, classes can easily refer to each other without a forward decl.)

In fact, here's something cool to note: You know the one place in Cpp1 where you can write functions in an order-independent way? Class scope! A member function can totally call another member function that isn't declared or defined until later in the same class scope. But it too has limitations for deduced return types, and... drum roll... the cool thing is that if you put the above functions into a single class scope in Cpp1 code (without forward declarations), you get exactly the same result as in Cpp2 (outside class scope) for the examples above: Godbolt link

struct Example1 {
    auto f(int i)  { return /*g(i)*/+1; } // ERROR, can't use g, which has a deduced return type, before g is defined
    auto g(int j)  { return j+2; }
    void main_()   { std::cout << f(42); }
};

struct Example2 {
    auto g(int j)  { return j+2; }
    auto f(int i)  { return g(i)+1; } // ok
    void main_()   { std::cout << f(42); }
};

struct Example3 { // *** Clang rejects the call to g, but I think it's a bug
    auto f(auto i) { return g(i)+1; } // ok -- because it's a template! ...
    auto g(int  j) { return j+2; }
    void main_()   { std::cout << f(42); } // ... and we don't instantiate it until g is defined
};

struct Example4 {
    auto f(auto i) { return g(i)+1; } // ERROR -- because it's a template! ...
    void main_()   { std::cout << f(42); } // ... but we instantiate it before g is defined
    auto g(int  j) { return j+2; }
};

That's because Cpp2 is basically extending to the entire source file the order-independence that Cpp1 supports only limited to within an individual class scope.

[edit to add] And, in both the Cpp1 in-class-scope examples here and the Cpp2 generalized versions of the examples above, all of the order-dependence problems disappear, and all examples work fine, if the return types are explicitly written rather than deduced.

Cpp2 already makes these examples better than in Cpp1, because Cpp1 generates all the forward declarations

In case this comments gets linked from somewhere later, the second Cpp1 here should be Cpp2.

Fixed, thanks.

[hsutter]

I am just not sure if it would be completely bulletproof for more complex cases, like, is this "dependency solver" possible in theory?

As @ZWORX52 mentioned, it would magically make some cases work, but could not handle all cases because a human couldn't either, such as mutually recursive functions with deduced types, or in general when there are cycles in the dependency graph; deduction can't bottom out when there's a cycle. Even for the cases that would "work," it would likely lead to strange brittleness, at least sometimes: For example, say you had a dependency chain that isn't a cycle, but where later adding a new library to the project changes overload resolution for one of the calls in the chain (or, one of the calls in the chain introduces a deduced return type) and the result is that now the chain becomes a cycle. The code would (mysteriously?) stop working and even with good diagnostics it would probably be difficult to figure out what went wrong.

So I sympathize with the problem, but I think the right answer is that the current state of Cpp2 is very order-independent (entirely order-independent by default), potentially order-dependent features do work order-independently a lot of the time, and when you do use order-dependent features (such as deduced return types) in a way that creates an ordering problem that would already exist inside a Cpp1 class, the diagnostic is quite readable(*) so you can see what the problem is, and the simple solution is to make the return type explicit or to reorder the functions.

(*) For example, here's what I get for Example 4 using MSVC:

f: (i) g(i)+1;  // line 1: ERROR -- because it's a template, but...

main: () = {
    std::cout << f(42); // line 4: ... but we instantiate it before g is defined
}

g: (j) j+2;  // line 7

The first lines of output are clear and directly tell you the problem:

demo.cpp2(1): error C3779: 'g': a function that returns 'auto' cannot be used before it is defined
demo.cpp2(7): note: see declaration of 'g'
demo.cpp2(1): note: the template instantiation context (the oldest one first) is
demo.cpp2(4): note: see reference to function template instantiation 'auto f<int>(const _T0 &)' being compiled
        with
        [
            _T0=int
        ]

... and this is then followed by several screenfuls of template spew but that's okay because the first lines tell you what the actual problem is.

So I don't think I want to pursue a dependency solver (and agree with not suggesting it! :)) because the problem is narrow and the diagnostics and solutions are good already, but I understand the motivation for one as well as the inherent limitations (again, in any language).

[ZWORX52]

do you think it would be confusing for language users that the function type and whether/what it returns changes materially if they give it a name, and it's otherwise syntactically identical?

I think it's actually rather understandable that removing braces means the function returns the value of its expression: you could differentiate it with the something like the following: "a function may be initialized (set = to) with either a block of statements or an expression." Then it's clear that these are different "value types" a function can have and therefore behave differently. Names are significantly harder to make that connection with, and I think that's more important than what we're sacrificing (intended-to-return-void functions that actually return something else because of std::cout or similar).

Re: order independence wrt. class scope: That's a great way to introduce the language's rules to users coming from Cpp1! Just say "order independence, as if everything was written in a Cpp1 class, but without the being-in-a-class part- it's not Java, don't worry." Because it has exactly the same limitations, as demonstrated above, there's no need to explain the rules.

I think the worst problem facing the order solver is still the issue that just adding a function call can make a new link in the chain and make a cycle. I can't imagine anything worse than that, unless it's even more subtle (e.g. chain of function calls through a template library leading back to a callback to your own code, somehow all through templates >_<).

g++ doesn't do a great job of handling this last example of template order dependence, but does make an interesting mistake along the way: when the original source mentioned by #line is available, it just uses that! Which leads to it taking the column value of g(i) in the Cpp1 code and going to that exact location in the Cpp2 file, leading to humorous results:

order_independence.cpp2... ok (all Cpp2, passes safety checks)

order_independence.cpp2: In instantiation of ‘auto f(const auto:257&) [with auto:257 = int]’:
order_independence.cpp2:4:19:   required from here
    4 |     std::cout << f(42); // line 4: ... but we instantiate it before g is defined
      |                  ~^~~~
order_independence.cpp2:1:55: error: use of ‘auto g(const auto:258&) [with auto:258 = int]’ before deduction of ‘auto’
    1 | f: (i) g(i)+1;  // line 1: ERROR -- because it's a template, but...
      |                                                      ~^~~

The files for reference:

// In Cpp1 translation output
//                                  this is column 55 v
[[nodiscard]] auto f(auto const& i) -> auto { return g(i) + 1;  }// line 1: ERROR -- because it's a template, but...

// In Cpp2
//                                  this is column 55 v
f: (i) g(i)+1;  // line 1: ERROR -- because it's a template, but...

I feel bad for the compiler, it has no way of knowing ;(

[JohelEGP]

The updated table is at #876 (comment):

Something concerned me with regards to Design note: Defaults are one way to say the same thing.
f: () = x; is a shorthand for f: () -> forward _ = { return x; }.

f: () -> forward _ = { return x; }
f: ()              =          x;   // Same as above, omitting defaults.

What concerned was the otherwise -> void default.
But then I remembered:

and having seemingly different defaults but that's just me

I suppose you're referring to the fact that
omitting the return-type results in a -> void default,
whereas it's -> _ for the terse syntax.

https://github.com/hsutter/cppfront/wiki/Design-note%3A-Defaults-are-one-way-to-say-the-same-thing#more-design-rationale
explains that the terse syntax is for a generic function with -> _.

-- #714 (reply in thread)

[hsutter]

Recording another example that just came up in #1203:

// Today's tersest syntax
in: (a, b) :(x) a$ <= x <= b$;

BTW I think this would be clearer with =, which makes it easier to read and see the two functions:

// With this issue's current proposal, add '=' twice
in: (a, b) = :(x) = a$ <= x <= b$;

[DyXel]

This was the case (close to it I guess) that made me write the first rant above 😄 That = is a single character, but its sooo important for human readability, it says so much.

[JohelEGP]

I really like being able to omit the =.
But requiring = to introduce the value has its weight in gold.

[JohelEGP]

But wasn't a problem of requiring = that it's already valid syntax with a default -> void return?
And that making -> _ the default instead leads to order-dependent code.

[JohelEGP]

Another point in favor of requiring =
is that writing == instead makes it a constexpr function,
which wasn't possible before with the tersest syntax (#714 (reply in thread)).

[DerpMcDerp]

Cpp2's function definition syntax:

:(a: i32, b: i32) = whatever

looks like you're constructing the 2-tuple struct { i32 a; i32 b; }. If tuples in C++ ever get popular enough to demand syntax sugar, cpp2's syntax will come in conflict with it.

I'm curious as to why cpp2 doesn't adopt Rust's x; means x; return; and x means return x; convention so that cpp2 syntax could instead be:

// old
:(a) = a;     // value return
:(a) = { a; } // void return

// new
:(a) { a }  // value return
:(a) { a; } // void return

Which gets rid of the = sign.

[jcanizales]

Implicit returns are already allowed, see e.g. #714 (comment) The question I guess is whether to allow other statements before it (or, as you word it later, allow it within a block), or instead leave them as a special one-off.

[DerpMcDerp]

A 90% solution would be to keep cpp2 a statement langauge but as a special case in the block body of a function, the semi-colon can be elided (and elided semi-colons interpreted as implicit returns). This is almost what Swift does (but it disallows any statements preceding the implicit return).

good: () { // <-- the block body
	a: i32 = 0;
	a // allowed and is taken to mean "return a;"
}

bad: () {
	{ // <-- not the block body
		30 // error
	}
}

Cpp2 can then get rid of :() = braceless_expr syntax, get rid of the =, and allow the parens to be elided for 0-argument functions: :{ foo(); }.

[gregmarr]

the semi-colon can be elided.

That reminds me, we also had another thread where we discussed trailing commas and semicolons. I believe that trailing commas are now optional everywhere. We discussed making trailing semicolons in a block optional as well, as they could also be treated as "statement list separators" rather than "statement terminators". With that, a closing brace closes a statement list, and the trailing semicolon it isn't strictly necessary. I don't think it has been adopted, but also hasn't been ruled out. Assigning semantics to the trailing semicolon would prevent that from happening, and make semicolons and commas as separators more dissimilar.

Cpp2 can then get rid of :() = braceless_expr syntax and also get rid of the =.

We just spent a whole thread putting the = back in.

[svew]

A 90% solution would be to keep cpp2 a statement langauge but as a special case in the block body of a function, the semi-colon can be elided (and elided semi-colons interpreted as implicit returns)

But why? What benefit does this serve? What's wrong with an explicit return statement?

The arguments you make further up basically sum up to "it's shorter", but brevity is not the goal of cpp2. Consistency, ease of understanding, ease of learning, and ease of writing safe code are the goals of cpp2. I don't see how this suggestion aligns with any of those goals.

[MaxSagebaum]

I strongly agree. With :() = something;, we will have a very nice short syntax. (The code smiles, it must be good.)

Reducing this further feels unnecessary.

[DyXel]

Herb finally implemented the discussed changes to add = back!
2c03e41
Fellas, I don't want to oversell it, but this function syntax is the best I have seen in any language with strong typing. Thanks a lot Herb for hearing us out and actually committing to the change!

[hsutter]

Aw, shucks! I'm glad you like it.

(Don't worry, there will always be others who don't and that's okay too.)

[hsutter]

Thanks everyone for your feedback!