title: Unconsistent fully qualified enum compile time behavior
body: <p>A colleague and I bumped into a a weird behavior when working with enums.</p>
  
  <p>We're both compiling the same project, with (presumably) the same make file, with the same compiler (gcc 4.8.4 ) . The only difference would be that I'm an a Linux VM Machine and he's in a native Linux environment but this shouldn't be the source of the issue.</p>
  
  <p>Given the following code snippet</p>
  
  <pre><code>namespace Something
  {
        enum Something {
               DARK_SIDE,
               LIGHT_SIDE
        }
  }
  
  ...
  
  Something::Something leEnumVal = Something::Something::DARK_SIDE; // inconsistency here
  </code></pre>
  
  <p>The inconsistency is that on my computer i get the following error :</p>
  
  <pre><code>'Something::Something' is not a class or namespace
  </code></pre>
  
  <p>However, everything works fine on in my Colleagues environment.</p>
  
  <p>It's worth while mentioning that we're using QT Creator ,and some extra stuff might be generated in the build process.</p>
  
  <p>Ofc, I managed to make the code compile on my environment, and the inconsistent line became :</p>
  
  <pre><code> Something:Something leEnumVal = Something::DARK_SIDE; // this compiles for both
  </code></pre>
  
  <p>Q1 : what is the standard way of addressing enum values ?</p>
  
  <p>Q2 : what could generate this inconsistency in the way the compiler treats the code ? (my guess is that my colleague is using some C++ 11 features on his setup, but I need some confirmation before starting to research how he enabled them )</p>
  
  <p>The code used above is used to show the problem we're facing. </p>
  
  <p>Considering that this is a significantly large project, with many enums used, we are facing scenarios where some developers use the first way of addressing enum values while some others are using the 2nd method. </p>
  
  <p>1st method has the benefit of listing during autocomplete solely the values from the qualified enum and not from the entire namespace (such as for the 2nd one). </p>
  
  <p>Considering there are many many enums in the namespace, it makes sense why one would rather go for the first approach.</p>