Re: array from static predicate on enumerated type

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2021-03-17 19:44, Matt Borchers wrote:

> I understand what you are saying.  But, we don't pass CURVED_LETTERS to Count, we pass a value of CURVED_LETTERS to Count.

You cannot pass that value. It is type violation as type operations and 
the values set are different. [Predicate does not create a new type, it 
only breaks the old one.] So the value must be converted to the expected 
type (the conversion can be null) or else the operation must be 
overridden or inherited with type conversion or else be class-wide and 
then the value must be converted to a class-wide value.

> In my mind, the value should then assumed to be of the type as declared in the parameter to Count -- which is LETTERS in your example.  Obviously any value of CURVED_LETTERS is actually a value of LETTERS.  This is how Ada treats this case now.

Yes and it is no different to how Ada treats arrays of CURVED_LETTERS 
right now.

> To your question, I would say that the compiler treat the argument for A : LETTERS as a member of LETTERS such that A'First = 0 and A'Last = 11 even if a value of CURVED_LETTERS was passed in (as it does now).

Then why you expect a different behavior from an array of CURVED_LETTERS?

> This discussion is helpful as I am now understanding that what I'm thinking is perhaps also equally inconsistent.  My current thinking is that I preferred a value of a sub-type to continue to be comparable (with =) to a value of the parent type, but I also wanted it to behave like a full-fledged type when using its attributes.

You cannot have it both ways.

> Nevertheless, it still feels like an unfinished feature as it is now.

It is not unfinished. It is irreparably broken.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de