Re: [Cbor] CBOR tag proposal for enumerated alternatives (tagged unions)

Emile Cormier <> Wed, 07 April 2021 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADDFA3A2AA2 for <>; Wed, 7 Apr 2021 14:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KK5GEXQwj9bf for <>; Wed, 7 Apr 2021 14:37:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45ABB3A2A9A for <>; Wed, 7 Apr 2021 14:37:32 -0700 (PDT)
Received: by with SMTP id v8so10012108plz.10 for <>; Wed, 07 Apr 2021 14:37:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Bpesor/mhmY/CKw/OFLHZaLf1jo9QiqESfsIM6/ApJw=; b=G4VHwbgGl+KHvrdHL3QT7Ste//3GuASEbrCpjbN+57/ALG8YWvII9qwHVlMQiU4xw5 XvUZUHanIUrElYeWPvaoiy9+IK4ALCpdKJ0Kphk/2ieSt2vOvn5zU1t5W7qXYZ+cN598 BL80riZQPeJ/u/FID1S8zyxqbLXkvJpGfUX2BMJnCjxdlhd907QQAFB4t83dtZOxfttq o5K3MHEbpgECmqfnqB6Cj54QQvazfnmHlW3gzPUshxe1B8MTvvyPKv/OE+Dz8n1VH/Yz hyhwID1cgayZdszmgN73CttqYxOYHxFKaCUb2b9awT9we9zjBiI+jjUhMVtcIcTSI63A pXzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Bpesor/mhmY/CKw/OFLHZaLf1jo9QiqESfsIM6/ApJw=; b=U5VaDMa3p52GJ7AS8cxsYUhZMnjwPXf01Ma514EA8PDYXSZeMxv8/w+FRJojeIZTrg 4KKReXYq0S29hL177lBL1TcjERkJBgMzZ/ET74OU4ZwzTKlCFw3s6VOPCqv5B7h3U+/g FAM44MfH14c6z58aaRYOf3vGXBrcEAGT+aFzIHEGqaN/44DEluZSuSRfrY6r5rHbA3+Z l4tJRlIKipxQ/HcSQOD6dcINdFgDV1ZPt7ZhjESIGBYWUcQIW8cX5C/YkFVpBvwUc4qR wAND6fa4z7EnkHFaOuH6JPoFFh+sbDArlAXo7tlAoi8nNhyfamFUegsgLFS/UsGVIA66 MeTA==
X-Gm-Message-State: AOAM530+bxjbLBXkIUWOOPcfa0tKtKL95H8czOOUFFKn+NyyQ7V4qIkE biZUE9GBYKkDuRXpqugSwkGven+7PZve4vQJP1g=
X-Google-Smtp-Source: ABdhPJyPRhSauH9HGbKu+BuNpOXhM93Pay9WUqA+6/C+5HHKwRy2VApikdu3ZgoBVAzSG0YPUOe3McPwukVq2nweM/g=
X-Received: by 2002:a17:90b:310e:: with SMTP id gc14mr5368058pjb.198.1617831450527; Wed, 07 Apr 2021 14:37:30 -0700 (PDT)
MIME-Version: 1.0
From: Emile Cormier <>
Date: Wed, 7 Apr 2021 18:37:19 -0300
Message-ID: <>
To: Carsten Bormann <>,
Content-Type: multipart/alternative; boundary="000000000000ea4add05bf68bcfb"
Archived-At: <>
Subject: Re: [Cbor] CBOR tag proposal for enumerated alternatives (tagged unions)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Apr 2021 21:37:37 -0000

On Wed, Mar 31, 2021 at 9:38 AM Carsten Bormann <> wrote:

> I’m not sure we discussed this one yet in detail:
> This is a (cbor-tags) registration request, so the WG does not have to
> have an opinion, but the designated expert would be interested in it
> nonetheless.
> (I’m personally pretty convinced of the use case; this is more of an issue
> of keeping tabs on available tag numbers and looking out for related use
> cases.)

As I had mentioned in the interim meeting, a related use case is
optional<T> (aka Nullable<T>). The meeting host (Christian?) was
questioning whether separate tags would be more appropriate to represent
the optional<T> semantic.

It would indeed be possible for the enumerated alternatives tags to be used
for representing an optional<T>. For instance, alternative 0 would
represent the "no value" state, followed by a null data item (0xF6),
whereas alternative 1 would represent the "has value" state followed by the
actual value. However, this is just an arbitrary convention and the
enumerated alternatives tags used in this fashion don't explicitly express
the "optional" semantic (it has to be assumed by the application). I
therefore agree that separate tags would be preferable for the optional<T>
use case.

I communicated with one of the co-authors of the enumerated alternatives
proposal about the possibility of including extra tags for the optional<T>
use case. They declined, not wanting to expand the scope of their proposal,
which is perfectly understandable.

My idea of tags for representing optional<T> might be overkill. One can
simply encode an optional value as either null (0xF6) or the actual value.
A contrived example where this would not work is encoding
optional<null_type> (i.e. "optional null").

Anyway, the idea of tags for optional values is out there for the
designated expert to consider. I cannot say if it's an idea actually worth
pursuing. I don't currently need them for encoding/decoding
std::optional<T> in my C++ work (I just check for null when deserializing
an optional value). However, I could definitely make use of the enumerated
alternatives tags for encoding/decoding std::variant<T0, T1, T2...>,
especially when the alternative types are ambiguous once converted to CBOR.

Emile Cormier