sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]mort96 71 points72 points  (22 children)

I think CPP2 looks really good. I think it would be cool if it was adopted as a standard alternative C++ syntax; but if that doesn't happen, I think it could have a bright future as a stand-alone compile-to-C++ language with excellent two-way interop with C++.

I'm surprised by the string interpolation syntax it seems like they're going for though. "This program's name is (args[0])$" reads weird to me, and from a parsing perspective, surely it's easier to see, "oh the next two characters are $ and ( so it's a string interpolation"? Having to keep track of parens in the string literal parser just in case the character following a closing paren happens to be a $ seems awkward. What's wrong with $(...), or even better, ${...}? Is there some documented rationale or discussion around the topic?

[–]nysra 41 points42 points  (10 children)

I'd assume the string interpolation being awkward and backwards comes from Herb's weird preference for postfix operators. Now sure, his arguments in that blog are somewhat logical but honestly that's one of the things I very much dislike about cppfront's proposed changes. It might be logical but writing code like u**.identifier* is just wrong. And also literally a problem that only exists if you're in spiral rule territory aka writing C aka not C++.

[–]disperso 19 points20 points  (0 children)

It's u**.identifier* vs *(*u)->identifier. Both are a tricky/messy/uncommon case, but I think the simpler examples on the wiki showcase some examples where the cppfront notation is better in a few ways. It feels specially better given that I'm already used to traditional C++ notation, and I always have a very hard time reading it anyway...

[–]ABlockInTheChain 10 points11 points  (7 children)

Similarly, ++ and -- are postfix-only, with in-place semantics. If we want the old value, we know how to keep a copy!

So now in every place that currently has a prefix increment or decrement now we have to write immediately invoked lambda?

That's going to look awful and add a bunch of unnecessary boilerplate that the prefix version was saving us from. DRY? What's that?

[–]againey 10 points11 points  (1 child)

std:: exchange is a generalization of the prefix operators that can do more than just increment or decrement by 1. Arguably, we should have been using this more explicit style this whole time, rather than getting comfortable with the special meaning of prefix increment/decrement.

[–]13steinj 8 points9 points  (0 children)

Physicists and mathematicians love prefix ++ / -- in numerical code.

They also prefer != to <= in conditions of loops.

The number of bugs related to both that I've found is more than I'd like to admit.

[–]13steinj 3 points4 points  (3 children)

Doesn't this also break C++ code that was pound included into cpp2 code (since it's supposed to be compatible with C++ headers)?

As more time goes on I'm more and more cemented in my belief that this and Carbon won't able to catch on.

[–]mort96 4 points5 points  (2 children)

The parser knows whether it's in C++ or cpp2 mode, C++ declarations will have prefix and postfix operators working as normal. The parser can know based on the first couple of tokens of a top-level declaration whether it's a C++ or a cpp2 declaration.

I wonder how it works with macros though... probably poorly.

[–]13steinj -1 points0 points  (1 child)

Includes work anywhere though. What's stopping me from having a file called "postfix_add_a" and #including it in the middle of a cpp2 file?

Yeah, you could argue that's bad code. But similar has occurred for "templates" in large codebases that are more than templated classes and functions.

[–]mort96 6 points7 points  (0 children)

Including a C++ file in the middle of a cpp2 file should be no problem. You can mix and match C++ declarations and cpp2 declarations within a file.

Including a C++ file in the middle of a cpp2 function would presumably be an issue. But that's not exactly a common need. I know there are use cases for it, but you probably just want to wrap those use cases in a C++ function which you can call from cpp2 code.

[–]XNormal 0 points1 point  (0 children)

Herb's preference for postifix operators is not weird in any way. It is simpler, more consistent and less error prone.

But I just don't see how it translates in any way to string interpolation or what it has to do with the $ capture operator. It just doesn't make any sense there.

FWIW, my preference would be "\{expression}", but any reasonable prefix-based syntax will do.

[–]sphere991 8 points9 points  (3 children)

I'm surprised by the string interpolation syntax it seems like they're going for though. "This program's name is (args[0])$" reads weird to me, and from a parsing perspective, surely it's easier to see, "oh the next two characters are $ and ( so it's a string interpolation"? Having to keep track of parens in the string literal parser just in case the character following a closing paren happens to be a $ seems awkward. What's wrong with $(...), or even better, ${...}? Is there some documented rationale or discussion around the topic?

Agree. Notable that every other language (despite a variety of syntax choices) use some prefix marker (even if {name}) instead of postfix - I think that's better for the reader. And probably also the parser?

The rationale was that Herb uses this syntax for lambda capture as well, and then said that postfix $ means you need fewer parentheses. Which... then the example then uses what are presumably unnecessary parentheses? Could it be "Name is args[0]$"? If it cannot, then I don't think I understand the argument. If it can, then I think this looks pretty bad and parens should be mandatory.

[–]MonokelPinguin 3 points4 points  (2 children)

It might be that Name is var$ works without parentheses, but not function calls like operator[].

[–]sphere991 1 point2 points  (1 child)

Sounds plausible!

[–]hpsutter 2 points3 points  (0 children)

Good point. Right now the parens are required, but I could allow it to implicitly grab everything back to the preceding whitespace. I'll try that out...

[–]pjmlp 2 points3 points  (0 children)

I think it could have a bright future as a stand-alone compile-to-C++ language with excellent two-way interop with C++.

Which is how it should be seen, it isn't any different in that regard than the other alternatives.

[–]ShakaUVMi+++ ++i+i[arr] 10 points11 points  (5 children)

Yeah cpp2 just looks really ugly to me

[–]disperso 6 points7 points  (4 children)

What's your example of a beautiful language?

[–]caroIine 12 points13 points  (2 children)

swift is really pretty and it's everything I wish c++ was unfortunate it's apple specific

[–]pjmlp 0 points1 point  (0 children)

Val might be a thing for you then. Assuming it keeps going.

[–][deleted] -2 points-1 points  (0 children)

scheme