empty slices: defined?

[DJ Delorie]

> 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?

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.

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?

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.