Talk:Union type

When you talk about union types, the first thing that pops up is the unions from C/C++, but there is such thing in the type theory of programming languages. Don't have any paper on hand, but the Types and Programming Languages by B. Pierce describes the intuitions, which is much general that it is in the current page ^[1] — Preceding unsigned comment added by Hfehrmann (talk • contribs) 23:15, 19 December 2016 (UTC)

The section about C/C++ states: "The primary use of a union is allowing access to a common location by different data types, for example hardware input/output access, bitfield and word sharing, or type punning." This usage might be common but is not actually guaranteed to work according to the standard. I think it should at least be mentioned that this is either undefined behaviour or relying on extra guarantees given by the compiler. 90.230.55.237 (talk) 09:35, 25 November 2019 (UTC)

I think Scala 3 union types should be mentioned somewhere, but if I understand correctly, they are neither union types nor tagged unions... Any ideas? — Chrisahn (talk) 18:46, 21 August 2022 (UTC)

This article was the subject of an educational assignment at College Of Engineering Pune supported by Wikipedia Ambassadors through the India Education Program during the 2011 Q3 term. Further details are available on the course page.

The above message was substituted from {{IEP assignment}} by PrimeBOT (talk) on 20:06, 1 February 2023 (UTC)

I am not going to bother starting an RfC for this one, because there already are two others on the same topic on other pages and that would just be tedious. Instead I am going to just leave a talk section. I propose that on the section regarding structs and unions in C/C++, we use left alignment for asterisks on pointers. The reason is that it is a section on both C and C++, and left alignment is essentially dominant in C++ whereas in C left and right have a more even split. Furthermore, left alignment places the focus on the type of the variable, for example char* s; suggesting s is a pointer to a char, rather than *s having type char. This is consistent with the compiler which will parse s as having type char*. The only arguments in favour of right alignment I have heard are that it is dominant in older (C specific) style guides, but it is once again a section on both C/C++. The full extent of my arguments can be found on Talk:Pointer (computer programming) and Talk:C data types. 2605:8D80:1391:EE1E:39B2:8822:ED56:E98E (talk) 15:36, 23 October 2025 (UTC)

"I am not going to bother starting an RfC" – that's a good call because a request for comment is not the first option for dispute resolution, especially between only two editors. See WP:RFCBEFORE. Yue🌙 18:59, 23 October 2025 (UTC)

@Vincent Lefèvre Union types do not exist solely in C, and it is not acceptable to force right-alignment of pointers here on the grounds that it is supposedly convention in C. (If I do not get a response I will request WP:3O.) ~2025-36699-87 (talk) 21:11, 15 December 2025 (UTC)

Pointer style has already been discussed, e.g. in Talk:Pointer (computer programming)#RFC on Pointer alignment in examples and Talk:C data types#RFC on Pointer alignment. There is no point in discussing further, and this is wasting people's time. — Vincent Lefèvre (talk) 01:46, 16 December 2025 (UTC)

Whatever were discussed on those pages was predicated on those pages being about C conceptions and C conventions thus applying. This is not an article about C programming, it is about programming in general. ~2025-36699-87 (talk) 04:32, 16 December 2025 (UTC)

This page could use substantive improvement about C and C++, by splitting them up, because C unions are seldom recommended or used as such in C++: reinterpret_cast supplants them for the type-punning purpose, and classes with dynamic_cast or std::variant supplant them for the tagged union purpose.

Rather than continue wasting time about where the whitespace goes, I suggest putting effort into splitting the C and C++ parts which are currently confusingly intermingled, and then there need be no more bickering over whether to use C style or C++ style.

I started by splitting the subsection of “Syntax and example”, but the earlier prose under “Unions in various programming languages” should be split up too. Also it's a little silly to have two separate sections per language, one for prose and one for syntax examples. Taylor Riastradh Campbell (talk) 04:22, 17 December 2025 (UTC)

@Taylor Riastradh Campbell, stop accusing others of "ideological crusades" and then forcing the continued use of #include in C++. The simple fact of the matter is that import std; is a standard feature of C++, is supported by all compilers (MSVC STL since version 17.10, Clang libc++ since version 18, GNU libstdc++ since version 15), and the crux of your complaint with using import std; is that it does not "demonstrably" work (even though it does work, and has worked on my device - it works on my device because I have correctly configured building it, and your version with #include wouldn't work if I used -nostdinc++ either). The simple fact of reality is that it does work, is part of the language, and even if I were to grant you that it did not work, it is not Wikipedia policy that every snippet of code must compile - this is a page on union types and just needs to demonstrate what a union type looks like (specifically in this section, how std::variant looks), not a tutorial. ~2026-58554-3 (talk) 20:31, 31 January 2026 (UTC)

I tested your code with the latest version of every compiler available in the godbolt.org compiler explorer. Without exception, the build failed.

I reviewed the latest gcc and clang documentation for C++ modules. Both clearly indicate that support is incomplete, e.g. directly quoted from the gcc manual (italicized emphasis in the original):

G++'s modules support is not complete.

The real-world evidence shows that this is an aspirational future feature. You are welcome to advocate for its use, but Wikipedia is not the place for this advocacy. The burden is on you to show that the material you're adding is encyclopedic, not merely advocacy. Taylor Riastradh Campbell (talk) 20:46, 31 January 2026 (UTC)

As I have said already, even if it is the case that it doesn't work (I'm able to do it myself), it is not the objective of the article to provide compilable code. ~2026-58554-3 (talk) 21:01, 31 January 2026 (UTC)

I am able to do the following with Clang/libc++ 21:

$ clang++ -std=c++23 -stdlib=libc++ --precompile -o std.pcm /usr/share/libc++/v1/std.cppm
$ clang++ -std=c++23 -stdlib=libc++ -fmodule-file=std=std.pcm Example.cpp -o example

where Example.cpp just has the example contents demonstrated in the page. ~2026-58554-3 (talk) 21:34, 31 January 2026 (UTC)

Wikipedia is an encyclopedia, not a programming manual for the latest C++ standard. — Vincent Lefèvre (talk) 21:12, 9 April 2026 (UTC)

@Chrisahn, why is it a problem to use using to add classes into scope while avoiding it for functions? I believe the justification I gave is sound:

• Avoid cluttering function signatures with irrelevant details such as the full name of classes. For things like std::invalid_argument and std::variant, clarifying that it comes from std does not particularly add additional context in reading the code.
• Not adding functions like std::get_if() and std::modff() into scope is because of preserving its context of where it comes from. The applicability of this is somewhat diminished by the flatness of std in C++ (namely how C++ doesn't divide the standard library the way Java, C#, or Rust do), but I believe it is relevant because functions, unlike classes, are often far more ambiguous with what their usage is - get_if() is quite ambiguous of a name, without the context of it being standard library (if it were a user-defined function, what might it refer to? Retrieving an optional value from some database or resource manager? etc.)
• Finally the two additional lines of using don't distract from the reader's flow at all, it perhaps only seems not to be a tremendous gain because of the short names like std::variant as opposed to a name with several nested namespaces like std::chrono::duration (or for a more contrived, Java-esque example, java.util.stream.DoubleStream), but in such cases the tradeoff is clear.

This is why I think it is a consistent and reasonable rule of thumb to follow. ~2026-58554-3 (talk) 15:48, 1 February 2026 (UTC)

Maybe that's a good rule for production code, but this is just a short example. And many of our readers probably don't know C++ very well. They'll probably wonder why some names use "std::" while others don't. (We could add an explanation, but that would clutter the code further.) Using "std::" everywhere and dropping the "using std" lines makes the example shorter, simpler and clearer. Similar point: You removed the [[nodiscard]] annotations. Good choice! In production code, I'd probably keep them, but here they are a distraction. By the way, I think we should also remove the [[maybe_unused]] annotation, for the same reason. — Chrisahn (talk) 10:56, 2 February 2026 (UTC)

It is a short example, and in most cases not importing the symbol into scope saves only five characters per scope. But I still think this is bad for things like function signatures which are traditionally long and can be reasonably reduced. In examples in other languages, such as using import in Java or use in Rust, we still continue to use these for adding symbols to scope, even if examples are short. (It might be claimed as a counterargument that using statements are bad practice in some C++ codebases, but this applies only to headers - which our example is not, and in source files, especially corporate codebases, there is liberal usage of using.)

I removed [[nodiscard]] for that reason - it didn't seem vital to communicate additional information, even if in true production code it is even preferable. On the other hand, I do think [[maybe_unused]] is worth keeping here for signalling clear intent we aren't interested in its value. It's more modern than using (void), anyway. ~2026-58554-3 (talk) 14:16, 2 February 2026 (UTC)

@Chrisahn Why are you removing import std; from the example? Nothing is holding the code back from using it, it is a clearly defined part of the standard library and has been in the language for three years. Furthermore, there is no reason why C++ shouldn't have using imports, when the C# and Java examples have them. Finally, there is no reason to use auto when the types are neither long nor obscure - they are pointers and nothing more. ~2026-21913-57 (talk) 21:07, 9 April 2026 (UTC)

@Vincent Lefèvre What "errors" does this example give? ~2026-21913-57 (talk) 21:08, 9 April 2026 (UTC)

See #import std; vs #include <*.h>. — Chrisahn (talk) 21:09, 9 April 2026 (UTC)

See:

$ clang++ -std=c++23 -stdlib=libc++ --precompile -o std.pcm /usr/share/libc++/v1/std.cppm
$ clang++ -std=c++23 -stdlib=libc++ -fmodule-file=std=std.pcm Example.cpp -o example

Did you even try this or do you conclude that just because you couldn't compile it without researching the correct steps, that it was "wrong"? ~2026-21913-57 (talk) 21:11, 9 April 2026 (UTC)

Wikipedia is an encyclopedia, not a programming manual for the latest C++ standard. — Vincent Lefèvre (talk) 21:13, 9 April 2026 (UTC)

Non-answer. Wikipedia isn't a tutorial on how to compile import std; either, so just because you couldn't compile it the first time doesn't disqualify it as an example.

Content is added on the basis that it improves the quality of content. A single line to import the standard library is far more concise than including every header needed, which even further begs the question of what symbols belong to what header and when that has to be updated. ~2026-21913-57 (talk) 21:17, 9 April 2026 (UTC)

Wikipedia, as an encyclopedia, must be based on well-established usage. Your example, which requires a specific compiler and non-default options, isn't. — Vincent Lefèvre (talk) 21:21, 9 April 2026 (UTC)

requires a specific compiler and non-default options

import std; is supported on all three major compilers: MSVC, GCC, and Clang

well-established usage

There are countless examples of "well-established usage" of modules. Even Stroustrup's latest edition of Programming: Principles and Practice Using C++ (which I am sure I cannot link, but can be easily found on Google) use it.

Please do research before commenting. ~2026-21913-57 (talk) 21:23, 9 April 2026 (UTC)

Three users disagree with some of your edits and gave their reasons in edit summaries and here on the talk page. Maybe it's time to WP:DROPTHESTICK. — Chrisahn (talk) 21:31, 9 April 2026 (UTC)

I've given you ample time to give merit-based reasons to disqualify the usage of modern C++ here, you still haven't acknowledged any of the arguments given. I think this is an appropriate place to use WP:3O if anything. ~2026-21913-57 (talk) 21:35, 9 April 2026 (UTC)

WP:3O: "two editors" — Chrisahn (talk) 21:38, 9 April 2026 (UTC)

Did you read the page? See 3O is usually flexible by allowing a few exceptions, like those involving mainly two editors with an extra editor having minimal participation. As far as I'm concerned this debate seems to be between you and me. ~2026-21913-57 (talk) 21:40, 9 April 2026 (UTC)

Ridiculous. — Chrisahn (talk) 21:41, 9 April 2026 (UTC)

While it's not an absolute requirement that the example code compiles, it's more convenient if readers can copy the code into an editor, Compiler Explorer, etc. and just compile it without having to precompile std. (Of course, this won't convince you, and you'll come back with some other argument...) — Chrisahn (talk) 21:41, 9 April 2026 (UTC)

C++ is not Python or JavaScript. Having a compilation process is natural. Rust has the luxury of a built in build system that streamlines this, otherwise in the exact same case we'd be calling rustc multiple times manually. Just because it's the case in C++ that some (minimal) work has to be done first, does not make it an inferior example. And not to mention this example doesn't even have a main function, so the question of whether it compiles as is without a copy-and-paste hardly matters if the user has to write their own main anyway.

Of course, this won't convince you, and you'll come back with some other argument...

You're quite right. Why wouldn't I respond? ~2026-21913-57 (talk) 21:47, 9 April 2026 (UTC)

Sure, you can respond as long as you want, but at some point, others won't talk to you anymore. You have a history of misinterpreting such situations, e.g. in Wikipedia talk:WikiProject Computer science/Archive 11#C/C++ pointer asterisk and null checks. As I said, at some point, you'll just have to WP:DROPTHESTICK. — Chrisahn (talk) 21:59, 9 April 2026 (UTC)

There's a difference between that archived link, which I clearly did WP:DROPTHESTICK, because it was clear nothing was going to come of it, and even I agreed (and maintain) that it was pointless. It doesn't compare to matter like this, where I repeatedly explained my changes (as you asked for in edit summary, no less: If you disagree, please discuss and explain on the talk page.), and in fact, this dispute over import std; is completely new here was never raised in the original dispute between the two of us, this was only raised again today. ~2026-21913-57 (talk) 22:05, 9 April 2026 (UTC)

"completely new here" – What??? — Chrisahn (talk) 22:08, 9 April 2026 (UTC)

I misspoke. ~2026-21913-57 (talk) 22:11, 9 April 2026 (UTC)

OK. I hadn't really looked into the import/include issue before. Now I did. I find your arguments less convincing than what @Vincent Lefèvre and @Taylor Riastradh Campbell said. No big deal. C'est la vie. — Chrisahn (talk) 22:17, 9 April 2026 (UTC)

...which is why it's being covered by the WP:3O request. ~2026-21913-57 (talk) 22:21, 9 April 2026 (UTC)

Regarding import/include: You don't seem to understand WP:3O. Regarding auto: See Special:Diff/1347964363. — Chrisahn (talk) 22:25, 9 April 2026 (UTC)

To add on to the WP:3O request: camelCase is a widespread adopted convention for function names in C++. To name a few pf these large codebases:

• Abseil, by Google
• Folly, by Meta
• Unreal Engine
• Clang/LLVM
• Chromium
• Qt

~2026-21913-57 (talk) 22:53, 9 April 2026 (UTC)

So what? Snake case is also widespread in C++, and it's used in std. We use std in the example, but none of the libraries you mentioned. There is no reason to use two different styles in the example. — Chrisahn (talk) 22:59, 9 April 2026 (UTC)

We use std in the example, but none of the libraries you mentioned.

Using one library doesn't "lock" us in to the stylistic choices it makes. ~2026-21913-57 (talk) 23:04, 9 April 2026 (UTC)

There is no reason to use two different styles in the example. Using camel case doesn't make the example code better in any way, but it might make readers wonder why some parts use snake case and other parts use camel case. Let's not confuse or distract our readers. Let's keep the code simple. We're trying to provide simple examples of union types. That's all. The examples are not intended to do anything else. They are not intended to teach coding styles that some may consider more "modern". — Chrisahn (talk) 23:08, 9 April 2026 (UTC)

I'd add that I find camel case more difficult to read than snake case, and it seems that I am not alone: Camel case#Readability studies. This would be a good reason why snake case should be preferred on WP. — Vincent Lefèvre (talk) 00:13, 10 April 2026 (UTC)

it might make readers wonder why some parts use snake case and other parts use camel case

We can speculate about hypotheticals that have not happened all day but that does nothing, and Wikipedia generally writes articles with the expectation that the reader has some general fluency or competency in the subject material. We don't write analyses of Shakespeare or descriptions and examples of Cauchy's integral theorem with the target audience being second graders. Expecting that readers can distinguish between a standard library symbol and a symbol that we have ourselves defined, especially in a language where there is already a precedence of camelCase names (in addition to snake_case names), is perfectly reasonable.

You used this same argument earlier on why using statements were applied to classes but not to functions. The context that namespaces provide for functions is helpful, but independent classes like variant and invalid_argument are used in places where said context is agnostic, and especially here, hardly relevant. Meanwhile, it follows the precedent already set on this pages in sections like Java and C# to simplify the names by qualifying them ahead. Another hypothetical question readers could ask is why fully qualify in C++, but not in those other languages.

Let's not confuse or distract our readers. Let's keep the code simple.

import std; is far simpler than independently listing out a bunch of #include directives, in addition to being standardised, supported by all compilers, and having real adoption. On the other hand listing out each #include can just as hypothetically lead readers to ask what std symbol comes from what header. And, if the examples are not intended to do anything else. They are not intended to teach coding styles that some may consider more "modern" as you say, then it shouldn't matter at all whether or not the code compiles without first compiling std. The examples aren't tutorials nor are they meant to just be copied and pasted by readers without any modification beforehand. If readers want to just mindlessly copy examples and compile them themselves, they can go to cppreference or ask ChatGPT for examples that work out of the box, but as you said, the only goal here is to show how it works, not provide a guide on how to compile it or explain to users what symbols come from what headers. ~2026-21913-57 (talk) 01:46, 10 April 2026 (UTC)

There is no reason to use two different styles in the example. — Chrisahn (talk) 02:26, 10 April 2026 (UTC)

And there is no reason to force ourselves to use #includes when imports exist and are far simpler. How about we quit it with the speculating and hypotheticals and base things on reality and not "X person might find Y thing weird". ~2026-21913-57 (talk) 02:29, 10 April 2026 (UTC)

There is a reason why we prefer #include. Three editors have been explaining it to you for months, but you're obviously a case of WP:ICANTHEARYOU. — Chrisahn (talk) 02:33, 10 April 2026 (UTC)

Double standards much. The examples aren't intended to teach anything other than unions, except until it comes to intentionally being more verbose by listing out a bunch of headers, because it really matters to the reader what header std::get_if comes from. ~2026-21913-57 (talk) 02:36, 10 April 2026 (UTC)

That's not the reason why we prefer #include. Three editors have been explaining it to you for months, but you're obviously a case of WP:ICANTHEARYOU. — Chrisahn (talk) 02:39, 10 April 2026 (UTC)

Keep rule lawyering. The only one doing WP:ICANTHEARYOU, WP:JUSTDONTLIKEIT even, is you by refusing to engage with any of my points and trying to hide behind other people saying things. Each of the allegations made against import std; were "this doesn't work (on my outdated compiler)", "this isn't a standard feature" (untrue), "I can't be bothered to compile std first so the example is invalid" (not Wikipedia's problem), "this requires non-default options" (no longer true), etc. Also, keep using language like You're obviously a case of and reducing people into textbook examples. ~2026-21913-57 (talk) 02:40, 10 April 2026 (UTC)

There is no reason to use two different styles in the example. There is a good reason to prefer #include. Three users have been explaining these things to you for months. But since you're a case of WP:ICANTHEARYOU, there's nothing else we can do after a while. You'll just have to WP:DROPTHESTICK. — Chrisahn (talk) 02:47, 10 April 2026 (UTC)

You're this, you're that. Blah blah blah. I guess it wasn't clear that WP:ADHOMINEM constitutes a personal attack. Try reading WP:AVOIDYOU. ~2026-21913-57 (talk) 02:49, 10 April 2026 (UTC)

You don't seem to understand WP:3O.

Well, at least I understand that the page says Discussions of issues should not take place here.

~2026-21913-57 (talk) 22:27, 9 April 2026 (UTC)

You didn't even understand that part. — Chrisahn (talk) 22:41, 9 April 2026 (UTC)

Well, who started discussing the issue there on the grounds of whether it was an appropriate 3O request or not, you or me? ~2026-21913-57 (talk) 22:43, 9 April 2026 (UTC)

You don't seem to understand what the word "issue" means in "Discussions of issues should not take place here". — Chrisahn (talk) 22:56, 9 April 2026 (UTC)

Well, the people at WP:3O are more than capable of deciding whether a request is worth pursuing, without your "help". ~2026-21913-57 (talk) 22:58, 9 April 2026 (UTC)

I am willing to compromise by showing neither import std; nor #include in the code example. Showing users what classes come from what header is not the point of the example at all nor is the expectation that code should just be able to be freely copy and pasted by readers anywhere without modification. After all, Wikipedia is not a tutorial, and in your own words, We're trying to provide simple examples of union types. That's all. ~2026-21913-57 (talk) 09:25, 10 April 2026 (UTC)

I agree that the headers are a bit ugly and distracting, but in this case that's acceptable, because readers and editors should be able to check the code easily. Of course, you're not going to understand this, but there's nothing we can do about that. You'll just have to accept that several others disagree with you and move on. — Chrisahn (talk) 11:17, 10 April 2026 (UTC)

Well, I offered a WP:COMPROMISE, but apparently WP:NOTHOWTO no longer applies and the code needs to be such that readers can copy and paste and compile it without modification (as if doesn't already fail to compile as an executable, because it doesn't have a main function).

You'll just have to accept that several others disagree with you and move on.

You're just WP:BLUDGEONing (WP:REHASHing, even) the process at this point by refusing to engage with any compromise proposal. You don't have an argument against not showing includes/imports at all (in your own words, I agree that the headers are a bit ugly and distracting), other than your assumption that all the code needs to be copy-pasteable by readers (ignoring WP:NOTHOWTO).

It reminds me of another thing, your unilateral decision that using statements don't belong on the page because you WP:JUSTDONTLIKEIT, ignoring the fact that other code examples on this page do this already and whatever "justification" you gave revolved around hypothetical readers apparently lacking comprehension of C++ or reasonable judgement that exist only in your mind. ~2026-21913-57 (talk) 14:16, 10 April 2026 (UTC)

I usually wouldn't respond, but since you have a history of mistaking silence for agreement, I'll just add that I still disagree. And since you claimed that I was the only one who disagreed with you and you wanted a third opinion: Special:Diff/1347960634, Special:Diff/1335884087,

Special:Diff/1333177717, Special:Diff/1329223649. You've been engaged in a slow edit-war for months now. It's not going to work. Just let it go. — Chrisahn (talk) 17:24, 10 April 2026 (UTC)

Yeah, no one knows what you're talking about, and you're just casting WP:ASPERSIONS, and you're just proving to everyone that you're unwilling to participate in good faith. Disputing content doesn't constitute an edit war, especially edits built on factually untrue claims (that import std; is unsupported by most compilers, that it's not standard, that it doesn't work because you don't want to bother making it work, etc.

But expecting anything fruitful, or even expecting compromise, is apparently too much to ask for. You've yet to reasonably justify why my compromise proposal is unacceptable, beyond hiding behind WP:REHASHing "people disagree" (literally only you have voiced disagreement to my compromise proposal) and trying to urge others to "let it go" on the assumption that you yourself are not WP:BLUDGEONing the process by unilaterally dictating what can and cannot go into an article. ~2026-21913-57 (talk) 20:29, 10 April 2026 (UTC)