Imported From: https://issues.scala-lang.org/browse/SI-6785?orig=1
Reporter: Travis Brown (travisbrown)
Affected Versions: 2.10.0-RC3

@paulp said (edited on Dec 7, 2012 11:58:37 PM UTC):
It's a (very) conscious decision not to expose flags. You can easily obtain it through the side door, {code}sym.asInstanceOf[scala.tools.nsc.Global#Symbol].flags{code}
Examples of things which you cannot do for want of access to flags do represent bugs or possible improvements, but exposing flags is not the only way, nor the most likely way, to remedy them.

@adriaanm said:
(Pushing reflection bugs to 2.11 to aid scheduling -- as it's experimental in 2.10.x, it shouldn't influence 2.10's schedule. They may be fixed earlier, of course.)

@adriaanm said:
Unassigning as milestone deadline was reached.

@xeno-by said (edited on Feb 1, 2014 1:49:44 AM UTC):
I was very close to fixing this issue in scala/scala#3452, but in the end I decided against it, because just flags are unlikely to be enough.

When creating flags based on someone else's flags it is oftentimes necessary to negate some bits or to only obtain a subset of those bits - something that's currently not available in the API, and exposing all that stuff on the verge of #6267 seems a bit too much.

If you feel that you need flags in the public API, please speak up - I will be glad to re-evaluate the "won't fix" given strong evidence.

@xeno-by said (edited on Feb 15, 2014 12:49:50 AM UTC):
scala/scala#3452

#6785 exposes Symbol.flags, setFlag and resetFlag

My first feeling was not to expose Symbol.flags, because that would
inevitably lead to exposing more methods on FlagSet. However we do need
flag manipulation in async, which is representative of advanced macros,
so I'm caving in.