From owner-sc22wg14+sc22wg14-domo2=www.open-std.org@open-std.org Tue Jul 9 02:29:09 2024 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 CA941356EF0; Tue, 9 Jul 2024 02:29:09 +0200 (CEST) Delivered-To: sc22wg14@open-std.org Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by www.open-std.org (Postfix) with ESMTP id 83992356A5D for ; Tue, 9 Jul 2024 02:29:09 +0200 (CEST) Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-58e76294858so7387176a12.0 for ; Mon, 08 Jul 2024 17:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720484949; x=1721089749; darn=open-std.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eagKyaE03rgNHmRRRArvLeWT7PVY/agGiSBPFBpkJvI=; b=ILo2NTHXLrwlW2eUZx1CeWeGAOVxIByL9EMx7lyK7PNldCHF2VMuauzfk4z+kMBKep tItRx0Me3dSnn9qMyRo3bBZ8Ovw65CR+GwfTJiMm2GqDfwoYFwL7pi7j0p+E+Q9ZLSVU D/ZPABekDwUEJvKZ7bvAuqzrNCFgncHqIEJVrP/t0VRc7Agm4FY5T7uWJn9Bsb7Oec0c x4zHnY/H119dYbDUs6ZojlztpK3MNSFjGbSQphYsYMB57Q/a76rM6sD1txdJjlHG1r/M hxtM4pA9A/Txm6XW8NHgy/5Eoa7KSXQbTt1IO69NsrhfKmcxGEAgRBpNq8ZZrnRJ7+s6 kX6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720484949; x=1721089749; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eagKyaE03rgNHmRRRArvLeWT7PVY/agGiSBPFBpkJvI=; b=sJk9XciTY7/KmkOwyueSkb0r7jMWzuGeUUf1k/zugacs5IiBaOncHiFNNzp2duE+4T Hk6u27HM26Njcs+f4d3DvfZvX+/ZPlGdRlDd63yXcRPWYJ7amIWHF8YmyUCs/rDctGdj Is9tZyuMJTxJ/1ZLndxx8VocTGeLvRQOvAgdlSHatjibhc2lCxK/7oAYzwSq7W8Uyt/a CTA1upboCqOckLSMPLPY+eEZZZ14J97IN9UOKR38IQ6wEu4qWKB9K8NBAbOrS9yoMH/Z xkeWEjCk6WHGiWqmnGz3hgdD+6Wa/cNbKgUvMxxT+o0XiXrL8ByByeG8fVGHt7m0uzZA osRQ== X-Forwarded-Encrypted: i=1; AJvYcCW5CONw3r3UXceNlOuqx5KOJR619iU4xTBJIZa86VWe2O46t/CIf7L3xBZ/zdUwQzJA1R5SVGI6ygNN6tj6vMmF4BaTAj8= X-Gm-Message-State: AOJu0YxkOouSuLIuXxTSnrmFlez6GZNV7N247Q4ys51b1TnNE81hpgtY pGSrStqXo17rHP4TvMQ2gBZhkstIGDo5kNu5zFcpuW+ln3LlSKQ/4vZXOqEbkmZEAEodBRWj1Pg yxeg03EE6AxsTIZzGe2Z+arJvDSU= X-Google-Smtp-Source: AGHT+IFwSF08JR+MOSYNdCT8M2LYBvXAgx3XhWe1dSGUL6+rRbIPZUmK7fLH/6S4slwRCVrLASWwnR7Pvsdumkh/e70= X-Received: by 2002:a05:6402:2695:b0:594:4d7e:1b6b with SMTP id 4fb4d7f45d1cf-594dca8f882mr640064a12.5.1720484948655; Mon, 08 Jul 2024 17:29:08 -0700 (PDT) MIME-Version: 1.0 References: <20240626152658.5A99E356F29@www.open-std.org> <20240708171412.5156C356EF0@www.open-std.org> In-Reply-To: <20240708171412.5156C356EF0@www.open-std.org> From: Alex Celeste Date: Tue, 9 Jul 2024 01:28:55 +0100 Message-ID: Subject: Re: [SC22WG14.26089] Can you get a qualified rvalue? To: Joseph Myers Cc: Aaron Ballman , wg14 Content-Type: multipart/alternative; boundary="00000000000034c928061cc59eac" Sender: owner-sc22wg14@open-std.org Precedence: bulk --00000000000034c928061cc59eac Content-Type: text/plain; charset="UTF-8" > '.' on an rvalue produces the unqualified, non-atomic version of the member type So given that it's important that the wording doesn't accidentally lose the element qualification before the step where a member array is converted to a pointer, can we just say that the lvalue _conversion_ applies to member access expressions regardless of whether they are an eligible lvalue or not? The syntactic expression is the same and the conversions are the same, so it is a related thing and could be a new kind of lvalue for wording consistency. That way it doesn't matter how much of the structure is represented by a temporary object or its lifetime; only the part holding the arrays has a relevant lifetime even if the rest exists in an abstract sense. Thanks, Alex On Mon, 8 Jul 2024 at 18:14, Joseph Myers wrote: > On Wed, 26 Jun 2024, Aaron Ballman wrote: > > > A postfix expression followed by the . operator and an identifier > > designates a member of a structure or union object. The value is that > > of the named member,93) and is an lvalue if the first expression is an > > lvalue. If the first expression has qualified type, the result has the > > so-qualified version of the type of the designated member. > > Given the direction of a series of past changes to avoid qualified or > atomic rvalues, I think we should fix this case as well (so saying that > '.' on an rvalue produces the unqualified, non-atomic version of the > member type - meaning it produces an unqualified type in typeof, for > example). And given the consistent direction of how such issues have been > addressed in the past, it would seem reasonable to handle this as a defect > fix. > > -- > Joseph S. Myers > josmyers@redhat.com > > --00000000000034c928061cc59eac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> '.' on an rvalue produces the unqualifie= d, non-atomic version of the member type

So given = that it's important that the wording doesn't accidentally lose the = element qualification before the step where a member array is converted to = a pointer, can we just say that the lvalue _conversion_ applies to member a= ccess expressions regardless of whether they are an eligible lvalue or not?= The syntactic expression is the same and the conversions are the same, so = it is a related thing and could be a new kind of lvalue for wording consist= ency.

That way it doesn't matter how much = of the structure is represented by a temporary object or its lifetime; only= the part holding the arrays has a relevant lifetime even if the rest exist= s in an abstract sense.

Thanks,
Alex

On Mon, 8 Jul 2024 at 18:14, Joseph Myers <josmyers@redhat.com> wrote:
<= /div>
On Wed, 26 Jun 2024,= Aaron Ballman wrote:

> A postfix expression followed by the . operator and an identifier
> designates a member of a structure or union object. The value is that<= br> > of the named member,93) and is an lvalue if the first expression is an=
> lvalue. If the first expression has qualified type, the result has the=
> so-qualified version of the type of the designated member.

Given the direction of a series of past changes to avoid qualified or
atomic rvalues, I think we should fix this case as well (so saying that '.' on an rvalue produces the unqualified, non-atomic version of th= e
member type - meaning it produces an unqualified type in typeof, for
example).=C2=A0 And given the consistent direction of how such issues have = been
addressed in the past, it would seem reasonable to handle this as a defect =
fix.

--
Joseph S. Myers
josmyers@redhat.co= m

--00000000000034c928061cc59eac--