Am Donnerstag, dem 08.08.2024 um 16:56 +0200 schrieb Jens Gustedt:
> Am 8. August 2024 13:28:57 MESZ schrieb Joseph Myers <josmy...@redhat.com>:
> > On Thu, 8 Aug 2024, Alejandro Colomar wrote:
> >
> > > Hi Jens,
> > >
> > > On Thu, Aug 08, 2024 at 11:13:02AM GMT, Jens Gustedt wrote:
> > > > > but to maintain expectations, I think it would be better to do
> > > > > the same here.
> > > > >
> > > >
> > > > Just to compare, the recent additions in C23 typeof etc. only have the
> > > > parenthesized versions. So there would be precedent. And it really
> > > > eases transition
> > > >
> > > Hmmm, interesting.
> > >
> > > The good part of reusing sizeof syntax is that I can reuse internal code
> > > for sizeof. But I'll check if I can change it easily to only support
> > > parens.
> > >
> >
> > Since typeof produces a type, it's used in different syntactic contexts
> > from sizeof, so has different ambiguity issues, and requiring parentheses
> > with typeof is not relevant to sizeof/lengthof. I think lengthof should
> > follow sizeof. Make sure there's a testcase for lengthof applied to a
> > compound literal (the case that illustrates how, on parsing sizeof
> > (type-name), the compiler needs to see what comes after (type-name) to
> > determine whether it's actually sizeof applied to an expression (if '{'
> > follows) or to a type (otherwise)). (If you're following the sizeof
> > implementation closely enough, this should just work.)
> Hi,
> I am not convinced that we should introduce the same syntax weirdness
> for this feature. sizeof seems to be the only place in the core language
> where a keyword is used as an operator in expressions, and
> that does not resemble function-call notation. In particular your
> example with compound literals shows that we could avoid syntax look-ahead
> by not doing this.
It is the other way around: With the "(" there is the ambiguity
whether this starts a compound literal or a type name enclosed
in parentheses. But this is not problematic for parsing.
Martin
> (People argued violently against look-ahead when we discussed
> possible inclusion of lambdas into C23)
> We don't have to repeat all historic accidents when inventing a new feature.
> Sure that gcc may invent anything to their liking, but when and if we pass
> this
> for standardisation we will give such considerations a careful look.
> Jens
