!standard  3.7(4)                                  15-07-27    AC95-00272/00
!class confirmation 15-10-05
!status received no action 15-10-05
!status received 15-07-27
!subject Currently there is no way to specify a type that has some discriminants publicly known
!summary

!appendix

!topic Known and unknown discriminants
!reference Ada 2012 RM 3.7(4)
!from Joey Fish 2015-07-27
!keywords discriminants privacy public
!discussion

There is no way to specify a type that has some discriminants publicly known
because the syntax of 3.7(2/2..6) says:

2/2    discriminant_part ::= unknown_discriminant_part | known_discriminant_part
3    unknown_discriminant_part ::= (<>)
4    known_discriminant_part ::=
         (discriminant_specification {; discriminant_specification})
5/2    discriminant_specification ::=
           defining_identifier_list : [null_exclusion] subtype_mark [:= default_expression]
         | defining_identifier_list : access_definition [:= default_expression]
6    default_expression ::= expression

I propose a change to this syntax to allow a public view to some discriminants
while maintaining a private view of others. Perhaps altering 3.7(4) to read:
     known_discriminant_part ::=
         (discriminant_specification {; discriminant_specification} [and
<>])
or perhaps 3.7(2/2) extended to read:
     discriminant_part ::= unknown_discriminant_part | known_discriminant_part | partially_known_discriminant_part
    with an appropriate definition for "partially_known_discriminant_part".

***************************************************************

From: Randy Brukardt
Sent: Tuesday, July 28, 2015  4:40 PM

...
> There is no way to specify a type that has some discriminants publicly
> known ...

Right, because even if you could specify such a type, what would you do with it?
You can't use the discriminant when declaring an object, because no objects are
allowed for a type with unknown discriminants. And you can't use the
discriminant in a constraint because Ada doesn't have partially constrained
subtypes. One could consider adding that, but it would be very complicated
(pretty much all of the rules involving constraints would have to be changed
somehow) and I suspect that there would be strong opposition to doing so.

In any case, any language enhancement proposal needs to include an example of
how it would be used, and what problem is being solved that can't be solved any
other (reasonable) way. All you have provided is a syntax change without any
justification whatsoever.

The ARG is primarily interested in the difficult to unsolvable problems that
people have encountered. When we know the problem, we can look into possible
solutions for the problem, which may turn out to be very different than what
you've proposed.

In any case, we don't have the least bit of trouble dreaming up neat language
features of dubious value -- see for example AI12-0014-1 and AI12-0019-1 -- we
definitely don't need help doing that. :-)

***************************************************************