Re: [sv-bc] Mantis 2380: array assignment compatibility

From: Greg Jaxon <Greg.Jaxon_at_.....>
Date: Fri May 22 2009 - 08:46:17 PDT

jonathan.bromley@doulos.com wrote:

incompatibility can be avoided by excluding [queues] from your proposal
    

But they were not part of the proposal, which addresses only
the assignment compatibility of various array types.
  

Yes, I meant just that the backward incompatibility in casting can be avoided by making an exception
there for variable-sized casting types. 

However, one could widen the proposal to forbid bit-stream
casting to a variable-sized target.  Its existing uses
can always be replaced (with more flexibility) by streaming
concatenation {>>{...}}.

As I see it there are three possible outcomes here:

1) Previous decisions (Manti 1447, 1702) relaxing array
   assignment compatibility could be revoked.  I really
   don't like this; those changes met some important user
   needs, and also fixed a number of internal contradictions
   in the 2005 LRM, so undoing them would be not only
   undesirable but also far from trivial.
  

I don't think 1447 or 1702 affected the definition of assignment compatibility in a way which
changed the outcome of casting;  but I could be wrong, since I did not read 100% of that material.
I have nothing against those improvements, so option (1) is not attractive.

2) Continue with approximately the current suggestion for 2380,
   and accept that the semantics of bit-stream casting to
   queues and dynamic arrays will be incompatible between 2005
   and 2009.
  

I support this option.  Unsafe casting here isn't so useful, and the coding styles I've seen
for such transformations already use the streaming operator to do these things.
It's a minor sort of incompatibility for which many vendors are likely to already have
a "standards level" setting and they can offer a smooth upgrade path.
Of course, the committee and public review need to confirm this opinion, so it should be
presented clearly.  I would like to reserve the term "bit-stream casting" for the (unsafe)
casts that do not alter bit patterns.  It should not be used as the name of the type'()
"casting" operation, but only as the term for one of its semantic possibilities.

3) Make it illegal to do a bit-stream cast to a variable-length
   array, and expect users to change existing code to use
   streaming concatenation or some other substitute.
  

I think (3) is just setting up the extension to (2).   My guess is that it would get us to
(2) in the 2014 standard.   That seems ponderously long for such a small matter to take.

I am willing to act as scribe for either (2) or (3), but
I'm not qualified to decide which option is preferred.

There's also option (0), do nothing and leave the present
internal contradictions about array assignment compatibility,
but I sincerely hope that would be vetoed by some balloting
entity!
  

You didn't describe the most conservative option (4), which was what I tried to suggest:
Change the definition of casting so that it acts like assignment only if the operand is
assignment compatible with the casting_type and the casting_type is not variable-sized.
This leaves the variable-sized arrays falling into their (current) bit-streamed behavior.
It breaks the assignment-fidelity of casting, though - so I don't favor this approach.

Greg
Disclaimer: I'm only trying to help frame a good proposal, I am not a voting member
of SV-BC or SV-EC, and cannot offer it any other support.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Fri May 22 08:48:17 2009