# union types

A type-system construct representing values that may conform to any one of two or more member types.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Explore new features available in C# 15 preview

DevFeed: [Explore new features available in C# 15 preview](<https://devfeed.tech/articles/explore-new-features-available-in-c-15-preview-2949.md>)

Original publisher: [Read original article](<https://devblogs.microsoft.com/dotnet/explore-csharp-15/>)

Author: Bill Wagner

Published: 2026-08-24T17:00:00Z

Content type: article

Language: en

Sources: [.NET Blog](<https://devfeed.tech/sources/net-blog.md>)

Topics: [C# 15](<https://devfeed.tech/topics/c-sharp-15.md>), [.NET](<https://devfeed.tech/topics/net.md>), [union types](<https://devfeed.tech/topics/union-types.md>), [.NET 11 Preview 7](<https://devfeed.tech/topics/net-11-preview-7.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [c-sharp](<https://devfeed.tech/tags/c-sharp.md>), [c-sharp-15](<https://devfeed.tech/tags/c-sharp-15.md>), [closed-hierarchies](<https://devfeed.tech/tags/closed-hierarchies.md>), [dotnet](<https://devfeed.tech/tags/dotnet.md>), [features](<https://devfeed.tech/tags/features.md>), [net](<https://devfeed.tech/tags/net.md>), [net-11](<https://devfeed.tech/tags/net-11.md>), [net-11-preview-7](<https://devfeed.tech/tags/net-11-preview-7.md>), [union-types](<https://devfeed.tech/tags/union-types.md>)

### AI overview

An overview of the new features in C# 15, which ships with .NET 11. The article covers union types, closed hierarchies, the preview memory-safety redesign, and several smaller language changes.

### Source excerpt

C# 15 ships with .NET 11. It adds union types, closed hierarchies, a preview of the updated unsafe model, and a few smaller changes that remove everyday ceremony. The post Explore new features available in C# 15 preview appeared first on .NET Blog.

## KotlinConf 2025 Announcements

DevFeed: [KotlinConf 2025 Announcements](<https://devfeed.tech/articles/kotlinconf-2025-announcements-39349.md>)

Original publisher: [Read original article](<https://kt.academy/article/kotlinconf2025-announcements>)

Published: 2025-06-03T00:00:00Z

Content type: article

Language: en

Sources: [Kt. Academy](<https://devfeed.tech/sources/kt-academy.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [destructuring](<https://devfeed.tech/topics/destructuring.md>), [exceptions](<https://devfeed.tech/topics/exceptions.md>), [union types](<https://devfeed.tech/topics/union-types.md>), [syntax](<https://devfeed.tech/topics/syntax.md>), [Safe-Call Operator](<https://devfeed.tech/topics/safe-call-operator.md>)

Tags: [announcements](<https://devfeed.tech/tags/announcements.md>), [destructuring](<https://devfeed.tech/tags/destructuring.md>), [exceptions](<https://devfeed.tech/tags/exceptions.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlinconf](<https://devfeed.tech/tags/kotlinconf.md>), [new-features](<https://devfeed.tech/tags/new-features.md>), [safe-call-operator](<https://devfeed.tech/tags/safe-call-operator.md>), [syntax](<https://devfeed.tech/tags/syntax.md>), [union-types](<https://devfeed.tech/tags/union-types.md>), [workshop-learning-programming](<https://devfeed.tech/tags/workshop-learning-programming.md>)

### AI overview

The article summarizes announcements from KotlinConf 2025, including K2 becoming stable, upcoming name-based destructuring, and rich errors with language-level support for result-or-error types and related operators.

### Source excerpt

The greatest announcements from KotlinConf 2025.

## Enhanced Checks and Observability in GraphOS

DevFeed: [Enhanced Checks and Observability in GraphOS](<https://devfeed.tech/articles/enhanced-checks-and-observability-in-graphos-23289.md>)

Original publisher: [Read original article](<https://www.apollographql.com/blog/enhanced-checks-and-observability-in-graphos>)

Author: Nick Marsh

Published: 2024-07-16T09:19:00Z

Content type: release

Language: en

Sources: [Apollo Blog](<https://devfeed.tech/sources/apollo-blog.md>)

Topics: [GraphOS](<https://devfeed.tech/topics/graphos.md>), [API](<https://devfeed.tech/topics/api.md>), [test](<https://devfeed.tech/topics/test.md>), [configuration](<https://devfeed.tech/topics/configuration.md>), [Usability](<https://devfeed.tech/topics/usability.md>), [union types](<https://devfeed.tech/topics/union-types.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [features](<https://devfeed.tech/tags/features.md>), [graphos](<https://devfeed.tech/tags/graphos.md>), [schema](<https://devfeed.tech/tags/schema.md>), [test](<https://devfeed.tech/tags/test.md>), [union-types](<https://devfeed.tech/tags/union-types.md>), [usability](<https://devfeed.tech/tags/usability.md>)

### AI overview

Apollo GraphOS has shipped reliability and usability improvements to schema checks and insights. The changes refine checks for input objects, enum types, union types, and interface types; add configuration for potentially breaking changes and default values; and improve the operation checks page with filtering and pagination.

### Source excerpt

Good API programs promote agility and can evolve APIs according to the needs of the business. While it's important to roll out changes quickly, it cannot come at the expense of reliability. Apollo GraphOS provides workflows to evolve a supergraph safely, including schema checks and insights. These popular features enable API teams to test for breaking changes before rolling out schema updates, allowing them to deliver changes quickly without impacting reliability downstream.

## The problem of union types for type systems

DevFeed: [The problem of union types for type systems](<https://devfeed.tech/articles/the-problem-of-union-types-for-type-systems-39390.md>)

Original publisher: [Read original article](<https://kt.academy/article/union-types-into>)

Published: 2024-06-10T00:00:00Z

Content type: opinion

Language: en

Sources: [Kt. Academy](<https://devfeed.tech/sources/kt-academy.md>)

Topics: [union types](<https://devfeed.tech/topics/union-types.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [subtype](<https://devfeed.tech/topics/subtype.md>), [generics](<https://devfeed.tech/topics/generics.md>)

Tags: [generics](<https://devfeed.tech/tags/generics.md>), [inference](<https://devfeed.tech/tags/inference.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [programming](<https://devfeed.tech/tags/programming.md>), [programming-languages](<https://devfeed.tech/tags/programming-languages.md>), [smart-cast](<https://devfeed.tech/tags/smart-cast.md>), [static](<https://devfeed.tech/tags/static.md>), [subtype](<https://devfeed.tech/tags/subtype.md>), [type](<https://devfeed.tech/tags/type.md>), [types](<https://devfeed.tech/tags/types.md>), [union](<https://devfeed.tech/tags/union.md>), [workshop-learning-programming](<https://devfeed.tech/tags/workshop-learning-programming.md>)

### AI overview

This article explains why general union types are difficult to add to Kotlin and other statically typed systems. It discusses ambiguity in subtype relationships and generic type inference, including the claim that inference is NP-hard, then describes Kotlin's proposed limited use of union types for representing errors through rich errors.

### Source excerpt

Why union types are not such a good idea for static type systems.

## Converting between Firestore FieldValue and Variant

DevFeed: [Converting between Firestore FieldValue and Variant](<https://devfeed.tech/articles/converting-between-firestore-fieldvalue-and-variant-16406.md>)

Original publisher: [Read original article](<https://firebase.blog/posts/2021/09/converting-firestore-fieldvalue-and-variant>)

Author: Konstantin Varlamov

Published: 2021-09-24T00:00:00Z

Content type: tutorial

Language: en

Sources: [Firebase Blog](<https://devfeed.tech/sources/firebase-blog.md>)

Topics: [Firestore](<https://devfeed.tech/topics/firestore.md>), [union types](<https://devfeed.tech/topics/union-types.md>), [Firebase](<https://devfeed.tech/topics/firebase.md>), [Realtime Database](<https://devfeed.tech/topics/realtime-database.md>), [C++](<https://devfeed.tech/topics/c-plus-plus.md>), [SDKs](<https://devfeed.tech/topics/sdks.md>), [Cloud Functions](<https://devfeed.tech/topics/cloud-functions.md>)

Tags: [best-practices](<https://devfeed.tech/tags/best-practices.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [class](<https://devfeed.tech/tags/class.md>), [cloud-functions](<https://devfeed.tech/tags/cloud-functions.md>), [data](<https://devfeed.tech/tags/data.md>), [database](<https://devfeed.tech/tags/database.md>), [firebase](<https://devfeed.tech/tags/firebase.md>), [firestore](<https://devfeed.tech/tags/firestore.md>), [realtime-database](<https://devfeed.tech/tags/realtime-database.md>), [sdk](<https://devfeed.tech/tags/sdk.md>)

### AI overview

A Firebase team tutorial explains how to convert between Firestore C++ SDK FieldValue and Variant values. It describes their overlapping but non-identical domains and presents an application-specific approach, including straightforward conversion of primitive values and considerations for strings and blobs.

### Source excerpt

News, tutorials, and updates from the Firebase team.

## Union syntax

DevFeed: [Union syntax](<https://devfeed.tech/articles/union-syntax-38898.md>)

Original publisher: [Read original article](<http://neopythonic.blogspot.com/2016/05/union-syntax.html>)

Author: Guido van Rossum (noreply@blogger.com)

Published: 2016-05-18T18:55:00Z

Content type: opinion

Language: en

Sources: [Guido van Rossum](<https://devfeed.tech/sources/guido-van-rossum.md>)

Topics: [Python](<https://devfeed.tech/topics/python.md>), [union types](<https://devfeed.tech/topics/union-types.md>), [syntax](<https://devfeed.tech/topics/syntax.md>)

Tags: [python](<https://devfeed.tech/tags/python.md>), [syntax](<https://devfeed.tech/tags/syntax.md>), [types](<https://devfeed.tech/tags/types.md>), [union](<https://devfeed.tech/tags/union.md>)

### AI overview

The article explains why PEP 484 uses Union[X, Y, Z] for expressing union types in Python. It argues that alternatives such as X|Y|Z, {X, Y, Z}, and (X, Y, Z) would create compatibility or semantic confusion, while Union[] works with existing Python versions and type-checking behavior.

### Source excerpt

Union syntax (I'm trying to do this as a quick post in response to some questions I received on this topic. I realize this will probably reopen the whole discussion about the best syntax for types, but sorry folks, PEP 484 was accepted nearly a year ago, after many months of discussions and hundreds of messages. It's unlikely that any idea you can think of here would be new. This post just explains the rationale of one particular decision and tries to put it in some context.) I've heard some grumbling about the union syntax in PEP 484: Union[X, Y, Z] (where X, Y and Z are arbitrary type expressions). In the past people have suggested X|Y|Z for this, or (X, Y, Z) or {X, Y, Z}. Why did we go with the admittedly clunkier Union[X, Y, Z]? First of all, despite all the attention drawn to it, unions are actually a pretty minor feature, and you shouldn't be using them much. So you also shouldn't care that much. Why not X|Y|Z? This won't fly because we want compatibility with versions of Python 3 that were already frozen (see below). We want to be able to express e.g. a union of int and str, which under this notation would be written as int|str. But for that to fly we'd have to modify the builtin 'type' class to implement __or__ -- and that wouldn't fly on already-frozen Python versions. Supporting X|Y only for types (like List) imported from the typing module and some other notation for builtin types would only sow confusion. So X|Y|Z is out. Why not {X, Y, Z}? That's the set with elements X, Y and Z, using the builtin set notation. We can usefully consider types to be sets of values, and this makes a union a set of values too (that's why it's called union :-). However, {X, Y, Z} confuses the set of types with the set of values, which I consider a mortal sin. This would just cause endless confusion. This notation would also confuse things when taking the union of several classes that overlap, e.g. if we have classes B and C, where C inherits from B, then the union of B and