Re: Ping: [PATCH gcc/* 0/2] Typed qualifiers

Hi Joseph,

Joseph Myers <[email protected]> writes:

> Do you have a sense of how the design would be adapted if in future it
> needs to handle an arbitrary set of qualifiers determined when the
> compiler runs (so objects that can store qualifier sets need to
> involve dynamic allocation in some cases)?  For example, for features
> such as the N3587 "strong typedefs" proposal.

Hm, I think qualifier_set should ease implementing N3587, if the C FE
was to be also converted to use the operations provided by qualifier_set
(join, merge, etc) rather than performing the same work inline.

I see that at least one more operation would have to be introduced, that
strips non-virtual qualifiers ("Unlike a concrete qualifier, the virtual
qualification is not removed by value conversion, and may appear at any
level of derivation."), so, an operation like 'value_convert'.

'merge' would have to be adjusted to respect the hierarchy of these
virtual qualifiers ("The composite type of two different strongly-typed
typedef names inherits the strong typing associated with both names." -
this is the operation 'merge' implements, you'll notice it does the same
for address spaces), as would 'can_qualify' and 'join'.

None of this should require us to go back and replace qualifier_set
itself, however.  It would just require us to complicate its operations.

Taking the setup from example 6:

  [[strong]] typedef int S1;
  [[strong]] typedef int S2; // unrelated to each other
    
  S1 s1 = ...;
  S2 s2 = ...;

... it seems to me that the following holds:

  [[strong]] typedef typeof (s1 + s2) S3;

  S3 s3_1 = s1; // OK
  S3 s3_2 = s2; // OK

  S1 back_1 = s3_1; // not OK
  S2 back_2 = s3_2; // not OK

... and that S3 has as its "super"qualifiers those generated S1 and S2.

This seems to imply to me that these virtual qualifiers form a DAG.

So, we'd need a new (presumably garbage collected) type (say,
'strong_qualifier') that contains a set of its parents (from which
implicit conversion is possible), and which represents one such instance
of [[strong]].  If we lean into the GC here, we can use the pointers to
test for equivalence (two [[strong]] typedefs of the same type would
generate two new instances of strong_qualifier which are distinct by
pointer even if they have the same set of parents, which is what we
want; though we probably also ought to hold the location of the typedef
name that created that virtual qualifier for diagnostic purposes).

A qualifier_set then holds a set of such garbage collected types (to
distinguish 'typedef typeof (s1 + s2) S4' from the 'S3' given above; S4
would have virt. qualifiers of S1 and S2, and S3 would have a new,
singular virt. qualifier whose parents are S1 and S2).

> (I think that particular proposal is seriously flawed in both the
> design and the specification, including the whole idea of expressing
> things in terms of qualifiers rather than some other concept, but I
> still think it's worth considering how the available qualifiers being
> added to during a translation unit could be handled.  Certainly I hope
> that typed qualifiers are a step in the right direction for anything
> requiring such dynamic allocation in future.)

Indeed, I'm also not really convinced by it either, but it seems
implementable.
-- 
Arsen Arsenović

-----BEGIN PGP SIGNATURE-----

iQEKBAEWCgCyFiEE/uKz0RP8AKMWLWBhUsKUMB6ixJMFAmpwciIbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z
Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRUUyQjNEMTEzRkMwMEEzMTYyRDYw
NjE1MkMyOTQzMDFFQTJDNDkzGBxhYXJzZW5vdmljQGJheWxpYnJlLmNvbQAKCRBS
wpQwHqLEk3MtAP0Sd06JziLChuzSWVZRgpnVg01TJTJvU2rMaHzt+pIT7wD6A2dX
p4GrClSV4d2hKZeDXvDsmlJJ7O2WL6/kxucr4AA=
=jQ4F
-----END PGP SIGNATURE-----