!standard 5.5.2(2/3)                                  15-06-03  AI12-0161-1/01
!standard 5.5.2(5/4)
!standard 5.5.2(7/3)
!class Amendment 15-06-03
!status work item 15-06-03
!status received 15-03-20
!priority Low
!difficulty Easy
!subject Missing operations of static string types
!summary

Relational operators and type conversions of static string types are now static.

!problem

The general model for static predicates is that if you replace the current
instance with a static expression, then the whole predicate expression would end
up static (see discussion in AI05-0153-3: " ... Every predicate-static
expression necessarily has the property that if you plug in a static expression
in place of every occurrence of the current instance, you get a static
expression. ... "). However, for string subtypes, this model breaks down. As
currently defined, a static predicate for a string can use relational operators
on strings (RM 3.2.4(19/3)), whereas a static expression on strings cannot,
because the corresponding operators are not "static functions" (RM 4.9(19)).

Now that we have static membership tests for strings (e.g. S in "abc" -- RM
4.9(11/4)) it seems odd to not permit static equality tests for strings (e.g. S
= "abc"). We should extending static functions to include relational
operators on strings.

!proposal

(See Summary.)

!wording

Modify 4.9(9):

* a type_conversion whose subtype_mark denotes a static
  [scalar]{@Redundant[(scalar or string)]} subtype, and whose operand
  is a static expression;

Add after 4.9(19):

* a predefined relational operator whose parameters are of a string type
  that is not a descendant of a formal array type;

Modify 4.9(20):

* a predefined concatenation operator whose result type is a string type
  {that is not a descendant of a formal array type};

[Editor's note: A formal array type can be a string type (it can be
one-dimensional with a character type as a component), and since we don't
allow predefined operators of formal scalar types, it seems that we need
the matching case for formal string types. Why we'd allow that for
formal string types and not for formal scalar types is beyond me, so I
consider it an omission and fixed the concatenation rule.]

!discussion

There are three items where static strings have limited capabilities compared
to static scalar types: operators, type conversions, and literals (aggregates).
It's not clear why any of these were excluded originally -- perhaps the
entire static string capability was more a hack than a designed feature.

The problem covered the uses for operators. Type conversions can be useful
if a bounds change or a representation change is needed. A string literal
is supposed to be euqivalent to a positional array aggregate, but the aggregate
is not static while the literal is.

We make changes to cover the first two cases. The wording needed to allow
aggregates seems extensive and complex, so we don't bother. (Static strings
still is a hack. ;-)

Note that for a type conversion, it might be necessary to change the
representation of the components (if the compiler uses the final representation
for the components in the internal static representation). This operation is
similar to the one needed to process string literals, so it shouldn't provide
an implementation hardship.

!ASIS

No ASIS effect.

!ACATS test

An ACATS C-Test is needed to check that the new capabilities are supported.

!appendix

From: Tucker Taft
Sent: Friday, July 29, 2016  8:07 AM

The general model for static predicates is that if you replace the current
instance with a static expression, then the whole predicate expression would end
up static (see discussion in AI05-0153-3: " ... Every predicate-static
expression necessarily has the property that if you plug in a static expression
in place of every occurrence of the current instance, you get a static
expression. ... ").  However, for string subtypes, this model breaks down.  As
currently defined, a static predicate for a string can use relational operators
on strings (RM 3.2.4(19/3)), whereas a static expression on strings cannot,
because the corresponding operators are not "static functions" (RM 4.9(19)).

We could leave this inconsistency as is, or we could fix this two different
ways:

   1) Disallow string relational operators in static predicates
   2) Allow string relational operators in static expressions (presumably by enlarging the definition of "static function" a bit)

Now that we have static membership tests for strings (e.g. S in "abc" -- RM
4.9(11/4)) it seems odd to not permit static equality tests for strings (e.g. S
= "abc").  So I would recommend extending static functions to include relational
operators on strings.

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

From: Tullio Vardanega
Sent: Monday, August 1, 2016  5:25 AM

I second.

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

From: Randy Brukardt
Sent: Monday, August 1, 2016  4:12 PM

For what it's worth, that was one of the reasons that my attempted extension of
staticness to user-defined types didn't work out very well. The intent was to
replace "static string subtype" with "potentially static subtype", but the fact
that various operations that have no reason not to be static weren't included
(like relational operations) turned the idea into a huge bunch of changes.

In addition to relational operators, type conversions and aggregates aren't
allowed as static for strings. For type conversions, 4.9(9) explicitly only
mentions static scalar subtypes. Why the difference? There doesn't seem to be
any difficulty in supporting that. As for aggregates, I presume the reason that
they weren't allowed was simply a lack of need; but it's a wart as usually
string literals are just a short-hand for a positional array aggregate.

I'd suggest at least including type conversions along with relational operators.
Aggregates are probably more work than they are worth (in the absence of the
generalization I was previously proposing).

You can find my original write-up of my proposed extension to staticness in
AI12-0175-1/01 (make sure you look at version /01; the final AI is very
different). The link is:
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0175-1.txt?rev=1.2 Not
sure that there is anything else useful there, but I *did* already consider
these issues, it might help to avoid reinventing the wheel.

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