VSIPL16 — View's block reference-counting is inconsistent

The description of how block reference-counting works with
view-allocated blocks is inconsistent.

In 6.1.1. [block.alloc], it is stated that "For a block allocated by a
view constructor, the effect of creation should include the effect of
invoking increment_count."

In 8.1 [view.view], however, the contrary requirement is given: "A
constructor that does allocate its block must not invoke its block's
increment_count member function."

These do not appear to be consistent – or, at the very least, are very
confusing. I suppose that the intended meaning is that, when a view
allocates a block, the act of creating that block should increment the
count, but that the view constructor should not otherwise increment the
count. However, that's not at all clear from the text.

Further, in 6.1.1, there is this note: "Note: For a block allocated by a
view constructor, the number of increment_count invocations should meet
or exceed the number of decrement_count invocations if the block is to
be used. When the number of decrement_count invocations exceeds, not
just equals, increment_count invocations, the block should be
deallocated." This seems at first glance to be inconsistent with the
definition of decrement_count, which states that the block will be
deallocated when the value reaches zero, not goes below zero. It is
only consistent if we assume that the phrase "the effect of invoking
increment_count" does not include the effect of incrementing the number
of times we consider increment_count to have been invoked!

Much of this would be clarified if we simply explicitly stated, in the
block requirements, that the "use count" should be set to one in the
block constructor, rather than the "effect of calling increment_count"
wording. Then we could omit the 6.1.1 paragraph 7 note entirely.

(That points out a related omission: We do not actually specify the
initial use-count value for the general case; for blocks that are not
Dense and not created by a view constructor, a conforming implementation
could initialize the use-count to infinity. Or three, just for
perversity. This is probably not desirable.)