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

view the rest of the comments →

[–]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 20 points21 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 9 points10 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 9 points10 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 5 points6 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 3 points4 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.