# UNION

Published articles for UNION.

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

## 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.

## How to use jOOQ's Converters with UNION Operations

DevFeed: [How to use jOOQ's Converters with UNION Operations](<https://devfeed.tech/articles/how-to-use-jooq-s-converters-with-union-operations-28947.md>)

Original publisher: [Read original article](<https://blog.jooq.org/how-to-use-jooqs-converters-with-union-operations/>)

Author: lukaseder

Published: 2023-03-02T11:18:17Z

Content type: tutorial

Language: en

Sources: [jOOQ](<https://devfeed.tech/sources/jooq.md>)

Topics: [SQL](<https://devfeed.tech/topics/sql.md>), [Databases](<https://devfeed.tech/topics/databases.md>)

Tags: [ad-hoc-converter](<https://devfeed.tech/tags/ad-hoc-converter.md>), [converter](<https://devfeed.tech/tags/converter.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [jdbc](<https://devfeed.tech/tags/jdbc.md>), [jooq](<https://devfeed.tech/tags/jooq.md>), [jooq-in-use](<https://devfeed.tech/tags/jooq-in-use.md>), [lambda](<https://devfeed.tech/tags/lambda.md>), [multiset](<https://devfeed.tech/tags/multiset.md>), [r2dbc](<https://devfeed.tech/tags/r2dbc.md>), [rdbms](<https://devfeed.tech/tags/rdbms.md>), [sql](<https://devfeed.tech/tags/sql.md>), [union](<https://devfeed.tech/tags/union.md>)

### AI overview

This tutorial explains how jOOQ ad-hoc converters behave with UNION operations. Because conversion occurs on the client after JDBC retrieval, it does not affect server-side UNION processing, and jOOQ applies the result-fetching row type from the first subquery. The article recommends applying client-side conversions consistently across subqueries or moving the conversion to the server when appropriate.

### Source excerpt

jOOQ 3.15 introduced the concept of an ad-hoc converter, a converter that is applied "ad-hoc" to a single query. It uses the same underlying mechanisms as any ordinary Converter that is attached to generated code for use in every query. An example of such an ad-hoc converter is this: While there are other ways to ... Continue reading How to use jOOQ's Converters with UNION Operations ->

## 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