Am 8. August 2024 17:42:54 MESZ schrieb Martin Uecker <uec...@tugraz.at>:
> 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.
No, the ambiguity is there because the first ( after the keyword could start
either a type in parenthesis or an expression, and among these a compound
literal. If that first parenthesis would be part of the construct (as for the
typeof or offsetof constructs) there would be no ambiguity a the only look
ahead would be balanced parenthesis parsing.
And just because there is "no problem"
because we learned to deal with this weirdness, it still doesn't mean we have
to write an inconsistency forward for which we don't even remember why we have
it.
>
> 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
>
--
Jens Gustedt - INRIA & ICube, Strasbourg, France
