From owner-sc22wg14+sc22wg14-domo2=www.open-std.org@open-std.org Wed Sep 2 11:11:23 2026 Return-Path: X-Original-To: sc22wg14-domo2 Delivered-To: sc22wg14-domo2@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id AFC24356E41; Wed, 2 Sep 2026 11:11:23 +0200 (CEST) Delivered-To: sc22wg14@open-std.org Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by www.open-std.org (Postfix) with ESMTP id 52A87356CE7 for ; Wed, 2 Sep 2026 11:11:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:from:to:cc:subject:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=++PaQfi7frWvTqgoKjSkp+NX4wwnAwcHP22WGcJX5SM=; b=b9l1dAO+wuhmHV1N6e4SPSXvMFxX1zKagKUXEQVw2izJfjoQWBkdEQIB 0N9ZENabbPhFPUpxs6bAtWF0NmyFz8PniVPZBB4/Zja5o9RIflhMMV1bc Yh8Utb1vqAvBkc9n1Tp3gt203nsE1/5pb1NPFKYpcu/lqSxqCKEqVVfZZ 4=; X-CSE-ConnectionGUID: YORg2inlTGuYXFVKjz4jcw== X-CSE-MsgGUID: xbOzDBuzRD2C9WnzAHdmHA== Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=jens.gustedt@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="6.25,257,1779141600"; d="scan'208";a="155678954" Received: from lfbn-str-1-96-234.w92-140.abo.wanadoo.fr (HELO inria.fr) ([92.140.223.234]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Sep 2026 11:11:20 +0200 Date: Wed, 2 Sep 2026 11:11:16 +0200 From: =?UTF-8?B?SuKCkeKCmeKCmw==?= Gustedt To: Joseph Myers Cc: sc22wg14@open-std.org Subject: Re: [SC22WG14.37786] New issue #1102: Conditions for when types are inferred Message-ID: <20260902111116.02e84bb9@inria.fr> In-Reply-To: <20260901201538.52728356E47@www.open-std.org> References: <20260901201538.52728356E47@www.open-std.org> Organization: inria.fr X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) X-Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAACRQTFRFERslNjAsLTE9Ok9wUk9TaUs8iWhSrYZkj42Rz6aD3sGZ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-sc22wg14@open-std.org Precedence: bulk Hi, on Tue, 01 Sep 2026 20:15:32 +0000 you (Joseph Myers ) wrote: > The following new C standard issue has been submitted. >=20 > https://www.open-std.org/jtc1/sc22/wg14/issues/c23/issue1102.html >=20 > ## Issue 1102: Conditions for when types are inferred >=20 > Authors: Jay Ghiron =20 > Date: 2026-09-01 =20 > Submitted against: C23 =20 > Status: Open >=20 > > If `auto` appears with another storage-class specifier, or if it > > appears in a declaration at file scope, it is ignored for the > > purposes of determining a storage duration or linkage. In this > > case, it indicates only that the declared type can be inferred. =20 >=20 > (C23 6.7.2 "Storage-class specifiers" paragraph 15.) >=20 > Consider the following: >=20 > ```c > int main(){ > constexpr auto int x=3D0; > } > ``` >=20 > This should probably be invalid, but there does not appear to be any > wording that actually prohibits this. This seems to be undefined by omission. > Specifically, the type is > inferred because another storage-class specifier appears with `auto` > but there does not appear to be any prohibition on type inference with > a type specifier. Additionally, consider the following: >=20 > ```c > int main(){ > auto y=3D0; > } > ``` >=20 > This declaration does not have another storage-class specifier and > does not appear at file scope, so it appears that the type is not > inferred and therefore violates a constraint for not having a type > specifier. I assume that it was not intended for this to be invalid. It is not invalid. 6.7.2 p16 (current version) mirrors the restrictions that are made in 6.7.2 p4 and only makes provisions for other cases but does not exclude this one. In particular in this example the role of `auto` is double, it is a storage-class specifier *and* it ensures that the type can be inferred. > There is a proposal > [N3579](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3579.htm) > currently that should fix these issues. The current text avoids > actually defining when type inference happens, just defining when type > inference can happen and applying constraints based off of if type > inference happens. The following is a minimal correction that I > believe will fix these issues. >=20 > ### Suggested correction >=20 > Modify C23 6.7.2 paragraph 15: >=20 > > If `auto` appears with another storage-class specifier, or if > > it appears in a declaration at file scopeno type > > specifier, it is ignored for the purposes of determining a > > storage duration or linkage. In this case, it indicates only that > > the declared type can be inferred. =20 I don't think that this is the right place to make such an addition. But we could strengthen it a bit If `auto` appears with another storage-class specifier, or if it appears in a declaration at file scope, it is ignored for the purposes of determining a storage duration or linkage. In this case, it indicates only that the declared type can is to be inferred. It would be better to have all the constraints regrouped in 6.7.10, Type inference. That could then read **Constraints** 1 A declaration for which the type is inferred shall contain the storage-class specifier `auto` and shall not contain any type specifiers`. Thanks J=E2=82=91=E2=82=99=E2=82=9B --=20 :: ICube :::::::::::::::::::::::::::::: deputy director :: :: Universit=C3=A9 de Strasbourg :::::::::::::::::::::: ICPS :: :: INRIA antenne de Strasbourg :::::::::::::::::: Camus :: :: INRIA PIQ program Strasbourg :::::::::: piq.inria.fr :: :: :::::::::::::::::::::::::::::::::::: =E2=98=8E +33 368854536 :: :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::