cor3ntin added inline comments.
================
Comment at: clang/include/clang/Basic/LangOptions.h:534
+ /// Returns true if implicit int is supported at all.
+ bool implicitIntEnabled() const { return !CPlusPlus && !C2x; }
+
----------------
aaron.ballman wrote:
> erichkeane wrote:
> > cor3ntin wrote:
> > > erichkeane wrote:
> > > > This name seems inverse of what you mean to me? IDK if you're
> > > > bike-shed-sniping me here, but:
> > > >
> > > > `prohibitsImplicitInt` to be the reverse of above? It becomes SLIGHTLY
> > > > ambiguous to me (in that we don't mean "the language standard
> > > > prohibits", we mean "the compiler implementation prohibits"), but that
> > > > can be fixed up with a comment.
> > > >
> > > > If you want to keep the direction, perhaps `implicitIntPermitted`, at
> > > > which point I might suggest the one above become `implicitIntRequired`.
> > > @erichkeane `requiresImplicitInt` is only used twice. Does it needs a
> > > name?
> > >
> > *shrug*, I tend to be of the feeling that if you have to say something this
> > often, and functions are basically free, mind as well make one.
> The idea here is that `requiresImplicitInt()` tells you when the support is
> mandatory per spec, and `implicitIntEnabled()` tells you when the support is
> either mandatory or an extension. I'm not strongly tied to the names, how do
> these sound?
>
> `isImplicitIntRequired()` and `isImplicitIntAllowed()`?
>
> (I could also add the word `Support` in there as in
> `isImplicitIntSupportRequired()` but then the function names start to get a
> bit longer than I think is reasonable.)
`implicitIntEnabled` makes sense to me. I guess my question is, is there
precedence for options for language-mandated features?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D124258/new/
https://reviews.llvm.org/D124258
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
