[v3] constexpr array additions

[Benjamin Kosnik]

Hi!

> 	Why returning _M_instance[0] if __n is invalid ? This is the
> best way to hide an issue under the carpet. I know that calling
> std::abort is not valid within a constexpr but returning a
> potentially valid instance will hide the problem, returning
> _M_instance[__n] have more chance to make the code break quickly.

I agree this patch is, as it stands, wrong. It's been bugging me too.
 
> 	IMO the whole 'at' method should be hidden without exception
> support if we can't substitute with std;;abort. 

I like the harsh nature of what you're suggesting! I've long advocated
a language (not library) solution for -fno-exceptions semantics. It
would be great to have this as a formalized dialect of c++.

For entertainment purposes only, since there is now another reason for
-fno-exceptions to care about throw expressions, see this thread on
bugzilla:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2519

> This method is
> completely based on exception support and if some code is using it it
> means that it expects exception support, without it it should not
> compile anymore. 

I'd say that this method is completely based on the idea of
range-checking, and to do nothing when found to be out-of-range is
pointless. 

One can make this general argument about all uglification
around -fno-exception, not just this method.

The usual diagnostic map of what happens when things go wrong is, more
or less:

-fexceptions == exceptions, ststem_erorr, etc.
-fno-exceptions == abort

It seems like this relatively simple model for diagnostic mapping should
be preserved at the expense of a uniform constexpr interface. Since
constexpr array:at is, at this point, an extension, it seems like
killing it when -fno-exceptions is the way to go.

> An other option is to make the method constexpr only
> when there is exception support.

Yes.

I'll do that today, and put in a marker for this issue in the testsuite.

best,
benjamin