Why not allow default arguments? (was: [SUGGESTION] GH Discussions)

[jmafc]

This is not a suggestion regarding syntax or the tool itself. I just tried using cppfront on a program that used a standalone function with a default argument and got a message saying:

error: Cpp2 is currently exploring the path of not allowing default arguments - use overloading instead

It wasn't too difficult to add a second function that called the first with an extra fixed argument, but I was intrigued so I looked in the wiki and also searched the open issues for "default" or "default arg" and found nothing. I realize that this is your experiment and you're probably quite busy to be answering queries like explaining the rationale for the above, but I'd like to suggest that the project use GitHub Discussions to allow such questions to be posed. For this particular instance, you could alternatively have a documentation label until the grammar and its documentation are more settled down.

As an aside, although I understand that, based on your CPPcon 2022 talk, many design/syntax decisions are geared at not having to teach parts of C++ that are, shall we say, "undesired", the tradeoff is that many developers will have to "unlearn" practices that are not necessarily "bad", but --at least-- in the current state of Cpp2/cppfront-- add quite a bit of verbosity.

If you don't want to use GH Discussions, please go ahead and close the issue.

[JohelEGP]

See also #24,
particularly #24 (comment).

[jmafc]

Ok, I can understand (and already mentioned) that (the administrative burden), but the OP in response asked for links to the "existing places" that Herb mentioned he uses, but I don't see them on the project README and I'm unaware of where Cpp2 is being discussed, except Herb's blog (and that's mostly one way). In addition, although Herb says he doesn't want to start a community, by making the project public on GitHub he essentially has done so.

[jcanizales]

Searching for that error message in the code and blaming the line was fruitful: #75

[jcanizales]

where Cpp2 is being discussed

From what I've seen by lurking the project for a few months, it's mostly these github issues and pull requests. Sometimes Herb points to material he's already written (papers or the wiki of this project).

[JohelEGP]

It's also discussed in r/cpp threads
about Herb's talks or Cpp2 articles on his blog.

[jmafc]

Searching for that error message in the code and blaming the line was fruitful: #75

I'm not convinced by the example with cyclic dependency. The equivalent:

int foo(int x = bar()) 
{
    return 3 * x + 1;
}
int bar(int x = foo())
{
    return x / 2;
}
int main()
{
    return foo();
}

cannot be compiled and I don't think you can get around the cycle, because there's no way to declare one function before the other.

[hsutter]

I'd like to suggest that the project use GitHub Discussions to allow such questions to be posed.

OK, let's try it! Done: cppfront Discussions

Thanks!

[hsutter]

I'll also take a pass through the open Issues that looks like they're questions or discussions, and convert them into Discussions (apparently there's a button for that somewhere).

[hsutter]

cannot be compiled

True. In Cpp2 which requires overloading instead of default parameters, you can compile it... though it leads to an infinite recursion at run time in that particular code: Godbolt

[jmafc]

My original example/question was regarding a simple standalone function. However, now that I've started experimenting with classes/types, I find that the lack of default arguments can become quite cumbersome. A very simple example:

Foo: type = {
    operator:= (out this) = {
         bar = 42;
   }
   operator:= (out this, b: i32) = {
        bar = b;
  }
  bar: i32 = 42;
}

Compare that with:

class Foo {
public:
     Foo(int b = 42) { bar = b; }
private:
      int bar {42};
};

And of course constructors could have multiple default arguments and some may have more complex operations. Does the current cppfront support calling the second constructor from the first?

[JohelEGP]

It seems that not. See #409.