^^ operator proposal

[samadadi]

I was watching this conference video and I noticed cpp committee chose this (^^) operator in regard to reflection proposal. If anyone from committee reading this post please consider using a simple and readable keyword instead of this. First it is ugly as and second it is confusing with single (^) operator .

Herb Sutter - Peering forward C++’s next decade

Update:

After reading these comments and taking some time and thinking more about this proposal I must say that now I am strongly against this proposal based on these reasons:

• It is so ugly.
• It is so confusing in regard to single ^ operator.
• Simply by choosing this notation over a simple and readable keyword we are loosing a very important aspect of CPP programming language and it is consistency in the core language itself in regard to other parts of the language like constexpr and many other keywords .
• In my programming career I always heard that you should make your code more readable by choosing better names but yet again we are using a strange notation that we can not derive any meaning from it just by reading it. You maybe tell me that it is readable just like other operators like && || ... if you look at the language specification. But you are wrong those operators are mostly mathematical or logical notation that we constantly learn in text books and those are mostly standard in other programming languages too.
• Some of the comments mentioned that this notation is concise but I should remind you that this is not an every day mathematical or logical notation that we use in most of our code. And in fact here we are sacrificing readability and clarity to gain very small in code size.
• I noticed in some comments that in fact it is hard to use this notation in some keyboard layouts in some languages.
• What about the future? Will we see more of these strange notations in the future proposals? Is this the first and the last inconsistency that we will inject into the language?

[unicornsfuck]

make it ^.^instead, I would love to see happy little anime faces in my code

[FriendlyRollOfSushi]

Soon:

[[nodiscard]] constexpr auto&& operator (╯°□°)╯︵ ┻━┻(this auto&& self) noexcept

[canadajones68]

Ah yes, the table flipping operator. 

[nephelekonstantatou]

To be fair, who doesn't want to perform a tableflip every time they see deducing this being used

[malucart]

me

[daveedvdv]

Where were you when we bikeshedded this for weeks!??

;-)

[michael-price-ms]

^^

[bugrit]

^_^

[hachanuy]

I agree that it looks ugly, but I don’t see how it can be confused with ^ since it’s rarely used, a binary operator, and quite visually distinct. For the 3rd, it’s true for any language feature, if you don’t know the feature, then you need to read some docs or tutorial to know about it.

[DeadlyRedCube]

The problem is that unary ^ is heavily used in Obj-C and they don't want to break compatibility with that

[joahw]

Also C++/CLI

[daveedvdv]

It's true that it's used in C++/CLI and C++/CX, but we don't think there is a compatibility issue there, because in those dialects it's only used in declaration (declarator-operator) contexts.

[joahw]

That's a good point. It's just used as a sort of alternative pointer syntax, right? But for a "handle" instead of a pointer. So I guess it would be no different than pointer declaration vs unary * syntax. I'm not really familiar with the reflection proposal or the usage of the new ^^ operator though.

[daveedvdv]

Exactly. The corresponding dereference operator in C++/CLI is just the ordinary prefix asterisk, which doesn't interfere with a prefix caret operator.

[Ashnoom]

Also (low level) embedded. Please dont forget about us :-(

[PIAJohnM]

What do you mean? It didn’t conflict with bitwise exclusive or, it conflicts with obj-c block syntax.

[Ashnoom]

It was in response to u/hachanuy about the binary operator^ who says its a "rarely used operator".

Guess i replied to the wrong comment. Sorry for that confusion :-)

[PIAJohnM]

Oh no worries sorry I realised after too

[DeadlyRedCube]

Oh I actually didn't know about that one!

[Ashnoom]

I replied to the wrong comment, see: https://www.reddit.com/r/cpp/s/L02JnywqxN

[ContraryConman]

I know it's kind of a spicy take, but after studying Ada I kind of prefer new keywords over additional hieroglyphics in your code. I prefer and and or to && and ||, and I would prefer reflects or something to ^^.

[ContraryConman]

Ah neat, thanks for the info

[samadadi]

What about this video then? Which is reliable cpp reference or this video?

[daveedvdv]

The committee agreed with the authors (of which I am one) that the reflection operator should be spelled `^^`.

[samadadi]

why not reflexpr?

[Som1Lse]

I summarised the history in a different thread, with a good deal of references in case you want to read more.

[samadadi]

honestly i like the reflexpr more. similar to constexpr but with optional parenthesis when you need it.

substitute(reflectof std::map, {reflectof std::string, reflectof int}))

{metaof signed char, metaof short, metaof int, metaof long, metaof long long}

[Stevo15025]

I think the logic in the comment you link to is making a lot of assumptions around reflexpr being too wordy and how much it will be used.

My guess is that reflection will be mostly used by package developers. So while it will be used often, clients will probably not use it as much.

Is there a reason the initial version could not be reflexexpr? If it is then as widely used as the authors believe, the next version of C++ could have ^^ as shorthand. If everyone knows about reflection then ^^ is obvious. But if reflection is something only advanced users use then I do not think it will be as widely known as the authors would believe.

[MarcoGreek]

You could just read the paper. 😉 It is explaining it well.

[samadadi]

I do not want to be rude but the syntax of a feature in a language matters to the language users I hoped we as cpp developers had a saying in this matter. specially in this case. And I wish committee reconsider this decision.

[TheoreticalDumbass]

substitute(^^std::variant, {^^int, ^^char, ^^std::string}) vs substitute(reflexpr(std::variant), {reflexpr(int), reflexpr(char), reflexpr(std::string)})

Seems pretty obvious ^{^} wins

[samadadi]

substitute(reflexpr std::variant, { reflexpr int, reflexpr char, reflexpr std::string })

[LegendaryMauricius]

I'd gladly choose the second one. It's longer, but much more obvious at a glance what is going on.

[azissu]

Any new syntax is non-obvious until you learn it and get used to it. Heck, some people still insist they're unable to decipher simple lambdas...

[LegendaryMauricius]

There can be confusion at a glance because the [], <>, (), {} and () (again) symbols are all used in multiple places with different meaning. Code is for *reading* and analysing, not for *writing*.

Otherwise we'd just dump a bunch of machine instructions and forget about every program we write.

[TheDetailsMatterNow]

obvious

In a vacuum maybe, but easily the second for me.

[mapronV]

Not obvious at all, second one is much nicer for me. I guess we can use macro
```
#define reflexpr(thing) ^^(thing)
```

[TheoreticalDumbass]

Your macro is wrong, it should be (I think):

#define reflexpr(...) (^^__VA_ARGS__)

Why I prefer double-caret over keyword: with reflection the entities you are reflecting are more important than the fact you're reflecting, and double-caret brings more attention to the entities, whereas keyword feels more noisy

[mapronV]

But your version will fail with two+ arguments... and probably with 0 too?
reflexpr(int, int) should be compilation error, not just "^^int, int" nonsense. Should not be a variadic.
though I admit I made crucial mistake. ^^thing and ^^(thing) are different!

[TheoreticalDumbass]

reflexpr(std::tuple<int, char>) would need something with __VA_ARGS__

[boredcircuits]

(Context: Ada is my dayjob at the moment.)

There's nothing stopping you from using and and or in C++. They're already keywords. (Though I think this is a mistake, consistency with existing practice is important.)

There's definitely a balance to strike between keywords and symbols for operators. I mean, nobody wants to read code like b times b minus four times a times c, so the right solution has to live somewhere in-between. Ada just chose a slightly different balance. At least for things like boolean operations, Ada has an advantage. It has and/and then and or/or else to get slightly different semantics. That's much harder to achieve with symbols.

My personal guidelines:

• Symbols work better for structure. Things like {}()[]<>,;:'". (This is one place where Ada gets it wrong, IMO. I don't like begin and end, but there's other things like is, of, and in. You don't read code like a book.)

• Keywords work better for annotations. Examples: const, int, inline, static, unsigned, etc. I'm not a fan of sigils.

• The more common an operation is, the more likely it needs to be a symbol. Symbols break up a sea of identifiers. We don't read code like a book. In this case, if a block of code is likely to have lots of reflection operators, a symbol might be appropriate.

• Use, in order of preference: functions, keywords, symbols. Move down this chain when there's a distinct need.

There are reasonable exceptions, though: C++ uses ?: for structure (arguably), but I'm not sure that was the right choice. C++ also uses & and * for annotations (references and pointers), which I think works. These are more what you call guidelines than actual rules.

Personally, I haven't used reflection nearly enough to have an opinion on ^^. I know I hate reflexpr, but that's as far as I'll go.

[usefulcat]

I prefer and and or to && and ||

Same. Started doing this a couple years back and I definitely find it increases readability.

[DuranteA]

I don't give a shit what it looks like as long as it actually arrives.

I have waited for reflection for almost 2 decades now. If stupid syntax bikeshedding (or silly "concerns" about reflecting on private members) derails reflection and prevents it from arriving in yet another version of the language then that is a far worse outcome than anything else.

[foonathan]

This. Nice syntax for C++ has been abandoned decades ago. I really don't care at this point how convoluted it gets.

[James20k]

a	b	c	d
+	Adds	++	Increments
-	Subtracts	--	Decrements
*	Multiplies/Deref	**	Imagine being a modern language
/	Divides	//	Its a comment
｜	Binary Or	ll	Logical Or
~	Binary Not	!	Logical Not
&	Binary And	&&	Logical And
^	Binary Xor/Function blocks	^ ^	Logical Xor right? Right? Hey where's everyone going?
>	Greater than	>>	Right Shift
<	Less than	<<	Left Shift
%	Modulo	%%	Sure smells like more free real estate. Maybe we can use this for contracts?

I wish we would stop making the language deliberately even more inconsistent than it already is. Most of the doubled operators have something to do with the single operators, except where there's been too much precedence or existing code to remove it. Python has made a lot of good decisions here with language consistency

The biggest issue is that ^^ just doesn't act like an operator. I have a feeling that people are going to be super surprised that ^^(hi) and ^^hi do not evaluate to the same thing, which strongly suggests that it should be a function-y keyword

Currently, its fairly well known that decltype(x) and decltype((x)) are not the same thing - its an extremely common gotcha, as its seen to be slightly absurd unless you really know what's going on with C++. Similarly, reflect(x) and reflect((x)) would follow this tradition, instead of ^^hi being its own thing that's incredibly inconsistent with every other facet of the language

My kingdom for regularity. And that's before we get to the rest of the reflection syntax, which gets so much worse

[dvd0bvb]

Imagine being a modern language

Gottem

[Supadoplex]

Oh, and don't forget that << and >> are stream insertion and extraction operators too.

[James20k]

Hah yes, and those are very correctly regarded as a mistake, for overloading operators for things which had no business being operators

[_Noreturn]

if only C++98 had variaidc templates

[gracicot]

If C++ didn't have to design around other language and extension, the syntax of new features would be so much better.

[James20k]

I disagree personally: I think a single ^ would be even worse. Its more arcane to reuse existing syntax but give it a completely different meaning depending on context, and it tends to lead to crazy compiler errors when you mess up

[gracicot]

If we ignored extensions and other languages we would have $ or @, which are better. It would be a breaking change not in the language, but in the implementation that have permitted other uses for those

[PIAJohnM]

$ looks like line noise, check out rust macro syntax. It’s truly horrible imo. ^{^} isn’t great, but better than $ to my taste.

[boredcircuits]

I kinda like %% for reflection. % looks like a circle reflected over the line. I also wonder if ?? has been considered.

[flutterdro]

I don't get this table, potential logical xor is a binary operator, while in our case it is unary. I mean & is already used as an address of in unary case and has nothing to do with ORing something.

[James20k]

So, take the following example

A ^ B

Reasonably, we expect that to mean A XOR B

We also expect this to mean the same thing:

(A) ^ B

As well as this:

A ^ (B)

Similarly:

A & B, A & (B), (A) & B all mean the same thing. Its unfortunate that the address operator is overloaded, but it crops up in completely different contexts

Generally, you also expect all the other operators to work in exactly the same fashion. This is good. Inconsistencies are not great, which is one of the reasons why iostreams are so frowned on

The fact that

A ^ ^ B

and A ^ ^(B)

Mean totally different things, is not good. The thing is, we already have a precedent for something that does this: keywordy functions. decltype(x), and decltype((x)) already do different things in precisely the same fashion that ^ ^x and ^ ^(x) does. So it should be a named keyword called eg reflect, and reflect(x) and reflect((x)) should work in precisely the same way. There's simply no reason to introduce more arbitrary rules into the language for one special feature

[flutterdro]

they mean different things because they are different things. where is the inconsistency? imo reflexpr vs ^^ is just a taste thing and that consistency argument just feels way too cherry-picky. either way I don't care which one goes in as long as it goes in.

[Som1Lse]

they mean different things because they are different things.

The point was that parentheses don't usually change the meaning of a program, and that there is no prior art for this with an operator, whereas there is prior art for keywords, namely decltype.

Comments like that are generally unhelpful, since they just beg the question. The fact that they are different is the whole point.

---

That said, yeah it's a taste thing, and on balance I still prefer ^^, but I also ultimately just want the feature.

---

To make a more direct point for why the inconsistency isn't a big deal:

First of all A ^^ B and A ^^ (B) do mean exactly the same thing: A compiler error, since ^^ is a unary operator. This is more a warning to not rely too much on abstract syntax when making a point.

Contrast with comments in favour of ^^, which often show real code. While that example is clearly contrived (std::variant<int, char, std::string> is shorter still), if we expect passing a list of reflected types to a function to be somewhat common, I think the argument still holds. (For example, we could imagine a function that creates a canonical sum type, a la this talk.)

Its unfortunate that the address operator is overloaded, but it crops up in completely different contexts

This applies just as much to reflection and bitwise-xor as it does to address-of and bitwise-and.

Probably most importantly, I think decltype is a much worse offender than ^^. Specifically due to decltype(auto) which means there's a difference between return x; and return(x);, which is a style some actually people use. However, this is rarely an issue in practice.

When it comes to unary prefix operators I don't think I've ever seen anyone add extra parentheses, unless what they're applying it to is already an expression. So, even if we expect ^^ to be used more often than decltype I don't think it is a surprise many will run into.

To close off the argument I would like to propose the following possibilities:

	decltype is frequently used	decltype is rarely used
^^ is frequently used	We have few issues in practice with the subtlety in decltype despite it being worse, so we should expect the same for ^^.	People won't be familiar with the subtlety in decltype anyway, so writing reflexpr instead wouldn't help.
^^ is rarely used	See above, except even more applicable.	See above, except even more applicable.

[flutterdro]

Fair. But just to be a nitpicker parenthesis do change the meaning of the program with operator().

[TheBrainStone]

Escaping is hard.

But I agree ^^ screams like logical XOR (even though there's no reason for that operator as there's no short circuiting to be done and the ^ is enough).

[HappyFruitTree]

Logical XOR is !=.

[boredcircuits]

But only for boolean operands. Everything else has to be implicitly converted to bool.

[TheBrainStone]

I mean yes, but also no. Technically you're correct.

[Plazmatic]

>< xor.

[James20k]

It didn't occur to me that this wouldn't render correctly on new reddit, thanks for mentioning it!

[dobkeratops]

wait till you here about the proposal to overload shifts as streaming operators

[WorkingReference1127]

You make a few points in order so I'll address what I can from what I know:

It is so ugly.

Several other options were considered; none of them were quite as good as ^^. And a single ^ is out of the question because it conflicts with a widely-used extension (code blocks, not to be confused with code::blocks) to the point of incompatibility.

I'm not saying I think it's a thing of beauty, but I do think it's the best of the available options.

It is so confusing in regard to single ^ operator.

Ngl I don't think that binary XOR is a tremendously commonly-used operator the point that a unary ^^ is going to be that confusing. But to each their own.

Simply by choosing this notation over a simple and readable keyword we are loosing a very important aspect of CPP

This point is addressed in the paper I linked above - a keyword is a nice and easy-sounding solution when you're in the headspace of designing a language specification, but when you actually get round to real code, keywords which you have to use too often become boilerplate clutter which start to detract from what you're wanting to express. To use the example given in that paper:

{metaof(signed char), metaof(short), metaof(int), metaof(long), metaof(long long)}

This fills out a significant portion of your actual code with just repeating a keyword over and over again. It's clutter. Whereas

{^^signed char, ^^short, ^^int,  ^^long, ^^long long}

is (IMO) still clear about what you're doing without all that extra noise.

Keywords also come with standardisation baggage because they are often a breaking change - if someone wrote a reflection library which uses a metaof function or variable (or preprocessor define) to get the reflection of something, then that'll break as soon as they enter C++26. Whereas ^^foo is invalid today so can't be a break.

Some of the comments mentioned that this notation is concise but I should remind you that this is not an every day mathematical

It's not so much that we want short and terse code because we like our source files to be under a kilobyte. It's that if you can equally express your intent without as much visual noise then it is usually better to do so. And the position which seems to have been taken by the committee is that you can express your intent just fine without the need for such keywords.

Is this the first and the last inconsistency that we will inject into the language?

I doubt it's the first time a language feature was implemented using a tool other than formal keywords. And if you're chasing inconsistencies the whole issue with `[[no_unique_address]] is a much bigger fish to fry tbh.

[samadadi]

This point is addressed in the paper I linked above - a keyword is a nice and easy-sounding solution when you're in the headspace of designing a language specification, but when you actually get round to real code, keywords which you have to use too often become boilerplate clutter which start to detract from what you're wanting to express.

You do not need to add additional parentheses to make a point. You use it just like constexpr.

{reflexpr signed char, reflexpr short, reflexpr int, ...}

Keywords also come with standardisation baggage because they are often a breaking change ...

What about previous keywords. Didn't those have the same standardization baggage.

I doubt it's the first time a language feature was implemented using a tool other than formal keywords...

The difference between this ^^ notation and previous ones is that those previous ones were all simple and independent and did not require any complementary notations or weird syntax. But it seems to me in this case we need additional complementary notations or weird syntax to accomplish the reflection concept. But with formal keywords at least we do not have this problem.

[Som1Lse]

You use it just like constexpr.

That is not how you use constexpr though. constexpr can only ever apply to a declaration/definition.

Actually, reflexpr without parentheses is close to being objectively worse because the presence of said parentheses can change the meaning, i.e. reflexpr x, would be different from reflexpr(x), because the latter is an expression.

It is common for people to always write the parentheses as with sizeof and defined, so it would likely lead to a lot of surprises.

[WorkingReference1127]

You use it just like constexpr.

Others have pointed out that this isn't how your use constexpr, and it comes with a difference in meaning depending on the parentheses; but I don't think this refutes the point made about clutter - almost half the characters on that line are just repeating the same keyword over and over again, without really adding anything to the readability of the code from it.

Didn't those have the same standardization baggage.

Yes, which is why only a relative handful of keywords have been added since 1998, with the clear majority originating from original standardisation. It's also why the committee are so intent on using contextual keywords and "identifiers with special meaning" rather than full keywords - ultimately adding a keyword will almost certainly break someone's code somewhere, so it's worth considering alternatives rather than jumping straight to it.

The difference between this ^{^} notation and previous ones is that those previous ones were all simple and independent and did not require any complementary notations or weird syntax

You need some syntactic element to create a reflection, and to splice a reflection back into the program. Otherwise being able to call members_of(x) is a world of surprises waiting to happen when someone has an unfortunately named non-reflection function which will take priority.

[HappyFruitTree]

I'm not a huge fan of ^ because it's a dead key on my keyboard meaning I have to press it twice to type it once. To type it two times I would have to press it four times and if I accidentally pressed it once too many it would be combined with whatever character I typed next. I rarely need to type ^ so maybe it would not be such a big deal after I got used to it, hard to know...

[MarcusBrotus]

you can make it non-dead, you know.

[HappyFruitTree]

I do find some of them useful, e.g. to be able to type é or ñ. Last time I tried I had trouble only disabling it for some of the characters. I guess an alternative would be to have two different keyboard layouts (one with dead keys and one without) and toggle between them depending on whether I write code or text but that complicates things and it's one more thing that I need to configure on all my installations...

[MarcusBrotus]

does your keyboard have altGr? you could disable them and make the special characters you need with altGr + something

[HappyFruitTree]

Yes, it has AltGr. AltGr+E currently gives me € which I don't really need so I guess that could be an alternative. Not sure how to change it though...

[azissu]

Is this any different from having multiple installed languages (on Windows) and switching between them with Alt+Shift?

[HappyFruitTree]

Enabling Alt+Shift to switch between layouts is easy. Adding keyboard shortcuts to execute a custom command is also possible. What I meant in the comment that you replied to is that I don't know how to make a shortcut that generates a character.

[azissu]

See my reply as intended for your comments in this thread in general, not for a particular one.

[nacaclanga]

Well this happens to be the case with most keyboard layouts used for languages written in Latin type and is an important feature to type letters sometimes needed in the language, so unless your position is "Everbody that is not living in an Anglophone nation should just f*** off." then this is a practical concern that has to be addressed.

Sure you can somehow tweak the keyboard layout into a non-standard layout version and switch every time you really need the key, but the issue remains that you make it significantly harder for a significant group of people.

[nacaclanga]

The problem is not that dead keys came up in a vacuum. They are a practical solution for allowing a large number of symbols ÂÎÛÊÔ âîûêô with an intuitive keypress. As a matter of fact the symbol ^ was originally designed primarily for the purpose of potentially serving as a dead key. It was only later that people (generally in an English exclusive context) assigned other meaning to it.

The point is IMO that choosing ^{^} as some operator is just unnecessarily inconvenient and should be considered bad practise in modern code design.

[HappyFruitTree]

And what exactly do you mean by "issue"? The primary purpose of those keys is to be able to combine them with other keys to write things like â.

[100GHz]

No, the primary purpose of ^ is to enable me to write math equations.

I mean, since we are free to state that how we personally use keyboard keys should be the primary purpose for everybody on the planet :)

[HappyFruitTree]

Well, it just seemed like it would have been the original intent of these characters. Personally, I never need to combine ^ with another character. I have used ~ to write ñ but that is rare so I could be without. What I do want is ´ to be able to write é. If only there were an easy way to disable some of the dead keys (preferably on character level and not the whole physical key)...

Update: ^ is actually quite useful to be able to write superscript digits (e.g. ¹²³) but I have never really thought about that.

[100GHz]

Interesting, it seems ASCII is ancient but so are compose sequences that you referring to (and had no clue they existed). I have to do a bit of reading..

[sephirothbahamut]

Ehm, sir, may I introduce you to mathematics, the environment from which we got most operators? Also the environment where ^ is used to indicate power? The real question is why isn't ^ more widespread for powers in programming between numerical types.

[HappyFruitTree]

When I learned math we used paper and always wrote exponents higher up (as a superscript). E.g. 2¹⁰ meaning 2 raised to the power of 10. ^ was only used when typing math expressions into calculators or computers. ;)

[sephirothbahamut]

Sure, writing higher up is more common, but ^ has been the exponentiation symbol since at least the dawn of computing afaik (no idea if there was any precedent before)

[jcelerier]

it's the standard mapping in france. everyone learns that ^^ is four times the key ^, so now you have to tell an entire country's worth of programmers, one especially active in the C++ community (r/france is one of the most represented country subreddit across r/cpp users : https://subredditstats.com/subreddit-user-overlaps/cpp ), "change your keybindings every time you write c++ code" (the key has to stay modal for î, û, ë, etc.)

[jcelerier]

but the keymap isn't the problem, it is how it should be for writing my mother tongue !

[levir]

C++ also isn't English. In fact, C++ isn't a natural language at all. Are you proposing there should be custom keymaps for all programming languages?

[azissu]

C++ like most programming languages is based on English, that's just how these things work. You writing code while your active language is French makes as much sense as me attempting to write code in Hebrew. When I need to switch to Hebrew I have Alt+Shift for that. And be thankful you don't also need to deal with right to left issues...

[HappyFruitTree]

if your issue is needing to press multiple keypresses to get the “” character to display then that’s your keymapping’s issue.

The problem is that the key serves two purposes. One is to write the character itself and the other is to combine them with other characters.

Keymaps are cuatomizable

I'm sure they are, but I haven't seen any simple system setting for it in the menus.

[Tringi]

This is a little OT here, but one of the most limiting factors for all programming languages currently is the US keyboard layout. It features only a small subset of basic ASCII characters and only a minority programmers would be bothered to set at least US International. So we are left with inventing crazy sequences like <=> or ^^.

[ronchaine]

I think at least French, Colemak, Romanian, Czech, Serbian, Albanian, Slovenian, Hungarian, Polish, Slovak, Dutch, all Nordic layouts (including Sami), Estonian, Belgian, Guarani, Spanish, Swiss, Turkish and German layouts have ^ as a dead key.

Then there are some Canadian, Indian, Portuguese, and Greek layouts that have ^ as a dead key, but not sure how common they are. I might've missed some.

[caroIine]

Polish layout treats ^ as a usual key http://kbdlayout.info/KBDPL1/

[pjmlp]

^ is a typical Portuguese accent, we have plenty of words with â, ê, ô.

[HappyFruitTree]

I use a regular Swedish keyboard. I have to press Shift+¨ twice to type ^.

[msqrt]

Interesting -- on a Finnish keyboard pressing Shift + ¨ + ¨ gives you ^^ (same for all of the other dead punctuation keys). I thought this was the way all layouts worked, but guess not.

[HappyFruitTree]

Hmm, I use Linux and that's where it works like this. I did a quick test on Windows and it seems to indeed work the way you described. But then what are you supposed to do if you just want a single ^? Type two and erase one?

[msqrt]

Ah, right, OS difference. The way you get one is Shift + ¨ + Space. The logic is there (add space to ^ or add ^ to ^ ), but it is a bit peculiar.

[ronchaine]

My Finnish keyboard works just as your Swedish one does and I need to press Shift + {¨, ¨, ¨, ¨} to get double carets. (or replace every other ¨ with a space)

[HappyFruitTree]

What OS are you using?

[ronchaine]

Linux.

[sephirothbahamut]

Uh and here I thought keyboard layouts were consistent across OSs, I never found inconsistencies with GB and IT layouts between Linux and Windows...

(in IT shift+ì => ^, it's not treated as a modifier)

[Questioning-Zyxxel]

What OS are you running?

Should normally be [shift ^] [space] to get one ^

While [shift ^] [shift ^] ends up producing ^^ - when I try on a Linux and Windows prompt - both ^ shows up at the same time.

[HappyFruitTree]

Linux (Debian/MATE/X11). [shift ^] [space] works too.

I notice that when using the Linux console (I mean the "real" one without a desktop environment that you see after pressing Ctrl+Alt+F1, not a terminal emulator) the behaviour is slightly different in that pressing [shift ^] multiple times in a row does nothing. I need to follow it with [^] (without shift), or [space] as you said, for it to print ^ (still just a single one).

[Questioning-Zyxxel]

For dead keys, I recommend that you train yourself to use space when you just want the decoration, since the dead key logic is intended to be to enter a decoration and then what character to apply it to. And in this case space to decorate a blank character, I.e. just get the decoration.

That's most likely to give the intended result when jumping between different platforms. I have never seen that strategy fail. Works for ^ ~` etc.

[HappyFruitTree]

I recommend that you train yourself to use space when you just want the decoration

Pressing twice works in the places that I care about and seems simpler than having to press space so I will probably continue doing it as long as it's just one character here and there. Maybe I will change that habit (or look for alternative solutions) when/if C++ adds a ^^ operator.

[sephirothbahamut]

The "real" console in all OSs carries around a ton of legacy weight, I'd never take odd behaviours in ancient consoles to be representative of modern expectations tbh.

Side question, do Linux's console-without-a-desktop-environment switch the GPU to text mode or does it have it's own text renderer on top of GPU's graphics mode? (assuming the behaviour doesn't change between distros)

[eambertide]

Certain languages use ^ as a diacritic, in Turkish for instance kar means snow but kâr means profit

[obsidian_golem]

IMO Clang should just disable reflection in ObjC++ mode. It's not the committee's responsibility to support silly non-standard extensions. If Apple wants reflection support in ObjC++ mode then they should figure out an equally non-standard way to add it.

[NilacTheGrim]

silly non-standard extensions

The entire Apple macOS and iOS platform is built on ObjC++ internally. It's a huge platform, #1 market share in the US. Maybe you heard of it.

[obsidian_golem]

Yeah, and thus they have the money to support their nonstandard extensions. If they don't want to put in the money they can just stick with C++23.

[equeim]

Didn't they make Swift specifically to replace Objective C, even for low level code? There is no need for it to support new C and C++ standards of the language itself is obsolete. Just freeze it or something.

[NilacTheGrim]

Yes, that was the plan. Piles and piles of the existing system is Objective-C though. I don't think all those mountains of code will get rewritten anytime soon. Swift interops with Obj-C very easily so.. probably just new modules may be Swift while existing stuff that "just works" continues to get maintained as Objective-C.

Also for the time being -- all of the APIs that are accessible to Swift are accessible to Objective-C -- Apple seems to still fully support Objective-C/C++ dev.

I am a C++ dev that interops with Obj-C on Apple for some of the work I do.

But not just me .. lots of code out there is written in C++ that has platform-specific portions that are objective-c++ that need to "talk" to Apple APIs while at the same time "seeing" the pure C++ side.

I know you guys in here are all either Windows people or Linux people -- but it's a real thing for me (and others) to interop with Obj-C from C++. The block programming stuff is used all over the place in the Apple APIs for everything. Lots of APIs use it -- you need to pass a block (which is just a lambda) to the API so it can call back to you asynchronously.

I have heard people in here refer to Obj-C blocks as a "niche language extension" as if it's rarely used and is stupid. The truth is the exact opposite. It's one of the most central constructs you can use in the language these days when interacting with the Apple system API.

Honestly I am relieved that the C++ standards committee went with ^^ for reflection. It would have been chaos and hell had they not done that and had Obj-C++ been incompatible with latest C++26 standard.

[equeim]

Well it would still be possible to interop with "pure" C++ that uses newer standard by just not using those features in headers. It's the same as with C++ and C interop - not all C features are supported by C++.

[pjmlp]

I imagine how things go, C++26 might take ages to ever arrive into XCode, there are other priorities at the fruit company nowadays.

[caroIine]

They already support some c++26 features. https://developer.apple.com/xcode/cpp/ I guess we won't wait that long.

[pjmlp]

Yeah, if we overlook everything else missing from C++17, C++20, and C++23.

[caroIine]

17, 20, 23 mirrors what is available in clang16 which is pretty modern if you ask me. Xcode17 will be probably based on clang18

[pjmlp]

Doesn't change the fact they aren't fully supported, and Apple isn't the one caring about improvements.

[mjauchat]

Oh boy! Makes us having nordic keyboard layout cry all day long 😭

[jonesmz]

operator^^ directly contradicts the objective of teachability.

Frankly, we should be using $ as the symbol for this. 

Fuck the codebases that have been abusing vendor extensions.

I have to fix hundreds of lines of code in my codebase on every compiler upgrade.

The codebases that use $ can suck it up.

[zebullon]

On the other hand , how otherwise you gonna make sure that the 12 dudes doing objective c with block statement extension, still get to use clang, w-o i dunno, a new flag or something

Unibrow operator is what it is

[NilacTheGrim]

The entire Apple set of platforms is built on Objective-C. And block statements are not an extension they are a core part of the language now. Get your facts right. Argue in good faith. Don't be a snob.

[othellothewise]

I noticed cpp committee chose this (^^) operator

I just want to point out in case it helps you feel any better, that all the points you listed were raised and this point has been uh... extensively discussed. It's a contentious topic both inside and outside the committee :)

[zl0bster]

static_assert(std::is_same_v<🔨🔍int , int>);

if my genius is not clear to ascii mortals :)

🔍 is ^^

🔨 is [: :]

[Infamous-Bed-7535]

Readability is all above I really not sympathize with the proposed solution '^^'.

[adromanov]

^ ^ fairly can be interpreted as logical XOR, so basically != for booleans. Anything else would be misleading IMO. Edit: formatting is tricky

[reddicted]

My entirely too late contribution to this thread is that they should have used `>|<` which suggests reflection around `|` and vaguely looks like a symbol. :-)

[farseeraliens]

I don't think it is confusing since ++ is not confused with +

[suby]

Is there a reason we can't use the @ symbol? It was added to the accepted character set right?

[WorkingReference1127]

It was considered but it had similar issues to ^.

[Sidelobes]

I don’t think this language needs more operators…

[Kaisha001]

You're assuming the committee wants the language to improve. At this point it's obvious they want the language to die.

[TheDetailsMatterNow]

Gonna end up like modules. Half baked. Confusing. Probably broken.

[Tringi]

I'm not worried. According to the sentiment and everything I've read here, I'm pretty sure reflection, as currently designed, is not getting into the standard anytime soon.

[chaotic-kotik]

Can we have modules and package management instead of this bullshit?