title: Can a string literal be subscripted in a constant expression?
body: <p>This is valid, because a <code>constexpr</code> expression is allowed to take the value of "a glvalue of literal type that refers to a non-volatile object defined with constexpr, or that refers to a sub-object of such an object" (§5.19/2):</p>
  
  <pre><code>constexpr char str[] = "hello, world";
  constexpr char e = str[1];
  </code></pre>
  
  <p>However, it would seem that string literals do not fit this description:</p>
  
  <pre><code>constexpr char e = "hello, world"[1]; // error: literal is not constexpr
  </code></pre>
  
  <p>2.14.5/8 describes the type of string literals:</p>
  
  <blockquote>
    <p>Ordinary string literals and UTF-8 string literals are also referred to as narrow string literals. A narrow string literal has type “array of n const char”, where n is the size of the string as defined below, and has static storage duration.</p>
  </blockquote>
  
  <p>It would seem that an object of this type could be indexed, if only it were temporary and not of static storage duration (5.19/2, right after the above snippet):</p>
  
  <blockquote>
    <p>[<code>constexpr</code> allows lvalue-to-rvalue conversion of] … a glvalue of literal type that refers to a non-volatile temporary object whose lifetime has not ended, initialized with a constant expression</p>
  </blockquote>
  
  <p>This is particularly odd since taking the lvalue of a temporary object is usually "cheating." I suppose this rule applies to function arguments of reference type, such as in</p>
  
  <pre><code>constexpr char get_1( char const (&amp;str)[ 6 ] )
      { return str[ 1 ]; }
  
  constexpr char i = get_1( { 'y', 'i', 'k', 'e', 's', '\0' } ); // OK
  constexpr char e = get_1( "hello" ); // error: string literal not temporary
  </code></pre>
  
  <p>For what it's worth, GCC 4.7 accepts <code>get_1( "hello" )</code>, but rejects <code>"hello"[1]</code> because "the value of ‘._0’ is not usable in a constant expression"… yet <code>"hello"[1]</code> <em>is</em> acceptable as a case label or an array bound.</p>
  
  <p>I'm splitting some Standardese hairs here… is the analysis correct, and was there some design intent for this feature?</p>
  
  <p><strong>EDIT:</strong> Oh… there is some motivation for this. It seems that this sort of expression is the only way to use a lookup table in the preprocessor. For example, this introduces a block of code which is ignored unless <code>SOME_INTEGER_FLAG</code> is 1 or 5, and causes a diagnostic if greater than 6:</p>
  
  <pre><code>#if "\0\1\0\0\0\1"[ SOME_INTEGER_FLAG ]
  </code></pre>
  
  <p>This construct would be new to C++11.</p>