Re: empty slices: defined?

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

DJ Delorie <dj@redhat.com> writes:

| > Oh, I assumed you were applying the general provision that lack of
| > description of behaviour is equivalent to "undefined behaviour", 
| 
| If it were for my own information, that would be sufficient.  However,
| in this case I'm asking in relation to a customer query, so I have to
| understand it more completely and exactly.
| 
| > and consequently you're asking for whether it would make sense to
| > extend the specification to cover those boundary conditions.
| 
| Given that there are *some* places where the spec says "can't do" one
| might assume that lack of a "can't do" implies "can do" rather than
| "unspecified".  Would this then be an invalid assumption?
| 
| > OK, the general type of answer is that lack of description of
| > behaviour is "undefined behaviour" :-)
| 
| Ah.  Ok, so strictly speaking, you can't legally do anything the spec
| doesn't specifically say (or strictly imply) that you can do, and
| "can't do" verbage is only to restrict special cases of otherwise
| specified allowed behavior?

Right.

| But one could then argue that, in this case, the availability of a
| default constructor means that the object has been constructed, which
| should (may? must?) leave the object in a defined state.  Especially
| when we have multiple constructors which all result in "object", and
| later refer to "object" without specifying which constructors are
| legal for objects used in that context.

Indeed, that is why I asked what useful purpose it would serve.  

The way *I* see it is that slices are implementation detail helper
function/classes for selecting subsets of value arrays.  *My* view is that
the default constructors are allowed so that one can put them in
vectors or arrays, e.g.
    

    std::slices ix[N];

and assign to them.

| IMHO, any constructor which leaves the object in an undefined state
| should specify that.  I can imagine lots of people assuming otherwise.
| 
| > However, that does not imply that the specification did not have a
| > design rule not formally translated into Standardese.
| 
| To what extent would it be a Good Thing to either (1) reword the
| standard so that what it says is more obvious, or (2) change our
| implementation so that we err on the side of users choosing the wrong
| interpretation?

For (1), Howward fowarded our request to the library reflector.
For (2), I'm open to anything that does nto introduce more checks.

| To go back to the original case, a user misunderstood the meaning of
| "empty slice" to mean "a slice which is empty" rather than "empty of
| slices".  I can convince myself that either intrepretation is "legal"
| but obviously they can't both be.  Our implementation has hints that
| imply both interpretations too; it is neither "always undefined" nor
| "always legal".
| 
| Sigh.  Makes me glad I'm a programmer and not a lawyer.

:-)

-- Gaby