[Cfp-interest] Fwd: data-interchange and scalar types

[Jim Thomas]

Begin forwarded message:

> From: Jim Thomas <jaswthomas at sbcglobal.net>
> Subject: data-interchange and scalar types
> Date: March 11, 2013 4:30:15 PM PDT
> To: "Joseph S. Meyers" <jsm at polyomino.org.uk>
> Cc: SC22 WG14 <sc22wg14 at open-std.org>
> 
> 
> On Mar 7, 2013, at 11:53 AM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
> 
> …
> 
>> 
>> On Mar 6, 2013, at 2:36 PM, Joseph S. Myers <jsm at polyomino.org.uk> wrote:
>> 
>>> Some comments on the part 3 document (interchange and extended types, 
>>> N1680) (page numbers are those printed on the pages):
>>> 
>>> 
>>> Types (pages 3-5):
>>> 
>>> Is a data interchange type on which not all operations are supported an 
>>> arithmetic type or a floating type?  Presumably not, because the 
>>> definitions of "floating types" (C11 6.2.5#11) and "arithmetic types (#18) 
>>> still apply.  
>> 
>> Right - such data-interchange types are not arithmetic types or floating types.
>> 
>>> So which operations are supported for such a type can be 
>>> determined by the existing wording in C11, together with the addition text 
>>> this document adds regarding conversions.  But there are some issues for 
>>> which this isn't sufficient:
>>> 
>>> * Is such a type a scalar type?  To meet the constraints for casts, for 
>>> example (6.5.4#2), it appears these types should be scalar types, and the 
>>> wording added as 6.3.2.3a (page 8) certainly suggests conversions 
>>> involving such types should be allowed.  Similarly, the wording about 
>>> sequencing of side-effects (6.5#2) is something that ought to apply to 
>>> such types; likewise the wording on initializers for scalars (6.7.9#11).  
>>> But I don't see any change to the definition of scalar types (6.2.5#21) to 
>>> include data interchange types that are not arithmetic types.
>>> 
>>> * However, several places assume that scalars can be compared with 0 
>>> (unary !, &&, ||, ?:, selection and iteration statements, assert macro).  
>>> So if you do make these types scalar types, then you need either to allow 
>>> such comparisons for them (given that such types, not being arithmetic, do 
>>> *not* meet the constraints for == and !=), or make exceptions in those 
>>> places.
>> 
>> Good issue. I don't think we want data-interchange types to be scalar types. We can try including data-interchange types just where needed. For example, for casts we could change 6.2.5 to:
>> 
>> …
>> [2] 	Unless the type name specifies a void type, the type name shall specify atomic, qualified, or unqualified scalar or data-interchange type, and the operand shall have scalar or data-interchange type.
>> …
>> [4]	A pointer type shall not be converted to any floating or data-interchange type. A floating or data-interchange type shall not be converted to any pointer type.
>> …
>> 
> 
> …
> 
> After further consideration, I think we do want data-interchange types to be scalar types. This fits with the general meaning of scalar as non-composite, and it requires fewer changes to the C standard (and avoids changes in the memory and atomics clauses). 
> 
> So we'd have "Arithmetic types, data-interchange types, and pointer types are collectively called scalar types." And in a few places, for example in 6.5.13 Constraints, we'd need to change "scalar" to "arithmetic or pointer" to exclude data-interchange.
> 
> -Jim Thomas
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20130311/6c9ee010/attachment.html