Version 1.4 of ai12s/ai12-0342-1.txt
!standard 4.2.1(0) 20-01-10 AI12-0342-1/02
!class Amendment 19-09-10
!status work item 19-09-10
!status received 19-08-15
!subject Various issues with user-defined literals (part 2)
The aspects related to user-defined literals are inheritable.
The "a literal is equivalent to a call" equivalence is
extended from just dynamic semantics into static semantics.
Conformance rules are tightened up for user-defined literals.
There are a number of issues with definition of user-defined literals
(even after AI12-0325, which is the "part 1" implicitly referred to
in the !subject text).
This AI is about two topics:
1) Inheritance of Integer_Literal, Real_Literal, and String_Literal
aspects. These aspects are inherited according to the rules given
in 13.1. In the case of type extension, any such inherited aspects
must be overridden.
2) Treating a user-defined literal like a function call for purposes
static semantics, not just dynamic semantics. This is intended to
clarify, for example, the rules about how user-defined literals interact
with abstract types and abstract subprograms.
A minor hole in the 6.3.1 conformance rules is also addressed.
In 4.2.1(2/5), delete "nonoverridable, ".
In 4.2.1(3/5, 4/5, and 5/5), replace (once in each)
"primitive function of T" with "function"
Append after 4.2.1 (5.a/5) (i.e., at the end of the Static Semantics section)
Thus, the following example is legal because the preceding rules
are name resolution rules (see 13.1.1):
package Pkg1 is
type T is record X, Y : Integer; end record
with Integer_Literal => Int_Lit;
function Int_Lit (X, Y : T) return Duration; --
function Int_Lit (Lit_Image : String) return T; --
end AARM note]
These three aspects are inherited according to the rules given in 13.1.
This means that in this example
package Pkg is
type T1 is record
X, Y : Integer;
end record with Integer_Literal => I_L;
function I_L (S : String) return T1 is ((0, 0));
type T2 is new T1;
function I_L (S : String) return T2 is ((1, 1));
X : T2 := 123;
the initial value of Pkg.X is (0,0), not (1,1).
end AARM note]
When a numeric literal is interpreted as value of a non-numeric
type T or a string_literal is interpreted a value of a type T that
is not a string type (see 4.2), it is equivalent to a call to the
subprogram denoted by the corresponding aspect of T: the
Integer_Literal aspect for an integer literal, the Real_Literal aspect
for a real literal, and the String_Literal aspect for a string_literal.
The actual parameter of this notional call is a string literal
having the textual representation of the original (numeric or
Such a literal is said to be a "user-defined literal".
This equivalence defines, for example, the nominal type, the nominal
subtype, and the accessibility level of a user-defined literal.
It also has the consequence that a user-defined literal shall not
be of an abstract type (because that would be equivalent to a
nondispatching call to an abstract function). This equivalence
also defines the dynamic semantics of evaluating a user-defined
Append after 4.2.1(6/5) (i.e., at the end of the Legality Rules section)
If a nonabstract tagged type inherits any of these three aspects,
then each inherited aspect shall be overridden.
- each primary that is a literal in one has the same value as the
corresponding literal in the other.
Ramification: The literals may be written differently.
- each primary that is a literal in one is a user-defined literal
if and only if the corresponding literal in the other is also a
user-defined literal. Furthermore, if neither are user-defined literals
then they shall have the same values [redundant , but they may have
differing textual representations]; if both are user-defined literals then
they shall have the same textual representation.
delete the entire Dynamic Semantics section (it is now redundant)
Because these are aspects, we don't get reemergence for with
formal derived types (the way that we might with primitive
subprograms). That means that in this example,
procedure Proc is
package Pkg is
type T1 is (T1_Op, T2_Op) with Integer_Literal => F1;
function F1 (S : String) return T1 is (T1_Op);
type T2 is new T1 with Integer_Literal => F2;
function F2 (S : String) return T2 is (T2_Op);
type Formal_Derived is new T1;
package G is
package body G is
X : Formal_Derived := 123;
package I is new G (T2);
begin null; end;
the variable I.X is initialized with the value T2_Op, not T1_Op.]
No change here; the aspects already exist.
ACATS B- and C-Tests will be needed to test that inheritance happens and that
the various Legality Rules are enforced.
From: Steve Baird
Sent: Thursday, August 15, 2019 7:49 PM
I have some questions question about user-defined literals.
The Integer_Literal, Real_Literal, and String_Literal aspects are
defined to be operational aspects.
... whether operational aspects are inherited by a derived type
depends on each specific aspect; unless specified, an operational
aspect is not inherited.
I saw no mention of inheritance or derived types in 4.2.1 (the section
on User-Defined Literals).
So these are not inherited? Is this what was intended?
There is no discussion of this question in the AI, so I'm wondering
whether this was an oversight.
Do we really want to reject
package Big_Nums is
type Big_Integer is private with Integer_Literal => ... ;
package Client is
type My_Int is new Big_Nums.Big_Integer;
procedure Foo (X : My_Int := 1); -- legal literal ?
You can't even work around the problem because these are
nonoverridable aspects. Having nonoverridable non-inherited
aspects seems like a really bad idea - you can't inherit them
and you can't explicitly (re)specify them (unless you can
figure out how to write a confirming specification for a
One could imagine a rule that the specified subprogram for one of these
aspects has to be a primitive operation of the type; this would allow
the definition of an inherited aspect for a derived type to be the
corresponding primitive operation of the derived type. At least in the
case of a tagged type (and presumably for other types, just for
consistency) this notion of "corresponding" would then have to take
overriding into account.
Perhaps we want something along these lines.
Related to the question of derivation, do we really want to allow
these three aspects to be specified for an abstract type?
type T1 is abstract tagged null record with Integer_Literal => ... ;
And do we want to allow an abstract function to be specified as
the value of one of these aspects?
type T2 is private with Integer_Literal => Abstract_Func;
function Abstract_Func (Lit_Image : String) return T2 is abstract;
At first glance, it might seem that other rules prevent these constructs
from causing any real problems. Specifically:
If the result type of a function is abstract, then the function shall
A call on an abstract subprogram shall be a dispatching call;
But recall that the equivalence between a literal and a function
call is only dynamic semantics; it has nothing to do with any legality
rules. So the aforementioned rule about "a call on an abstract
subprogram" has no bearing on the legality of a use of a numeric
In any case, it seems like useless implementation complexity to allow
these useless constructs. As far as I can see, allowing these constructs
isn't doing the user any favors either.
Presumably the specified subprogram for one of these aspect
specifications can be the dereference of an access-to-subprogram
Can it be a prefixed view of a subprogram?
I see no rule disallowing these cases, but I thought I'd
check to be sure.
Of course the restrictions discussed above in item #1 would
Is one of these user-defined literals an object or just a value?
More specifically, is the following example legal or not?
type T1 is ... with Integer_Literal => ...;
X : T1 renames T1'(123); -- legal?
I'd say it is not because, statically, 123 is not a function call
and literals are not on 3.3's "All of the following are objects"
As mentioned earlier, the equivalence between literals and function
calls is strictly dynamic semantics.
On the other hand, something like
type T2 is record
Aliased_Component : aliased Some_Type;
with Integer_Literal => ... ;
procedure Foo (Ref : access Some_Type);
Foo (T2'(123).Aliased_Component'Access); -- legal?
seems less clear. Is this legal?
I think we want these guys to be treated like function result objects
in the aforementioned 3.3 list. And besides, composite "values" seem odd
- for example, what does it mean to have an actual parameter in
a call which is a value, but not an object, of a by-reference type?
Interestingly, the 3.3 list does include "the result of evaluating
an aggregate" while 4.2 says "The evaluation of a string_literal ...
yields an array value ...". This seems like an area where the
equivalence between string_literals and array aggregates breaks
down even before we start talking about user-defined literals.
AI12-0270, which is about cleaning up these object/value issues,
is on hold. But just because we don't want to tackle the existing
problem doesn't mean we shouldn't avoid making the situation worse
with the addition of new features.
If one of these literals is not an object, then it doesn't have
a nominal subtype (recall that 3.3 says "At the place where a view of an
object is defined, a nominal subtype is associated with the view").
I don't see that this causes any of the problems that
AI05-0006 was worried about because you cannot case on
a literal (because the expression of a case statement is
a complete context). And besides, a literal is not
a name (if that matters - AI05-0006 talks about ensuring
that every *name* has a well-defined nominal subtype).
On the other hand, "nominal type" is defined in terms of
"nominal subtype". However, having an undefined "nominal type"
doesn't seem to introduce any definitional problems.
So I don't think there are any problems here, but I thought I'd
raise the question.
From: Tucker Taft
Sent: Thursday, August 15, 2019 9:22 PM
> So these are not inherited? Is this what was intended?
Certainly not, in my view.
> There is no discussion of this question in the AI, so I'm wondering
> whether this was an oversight.
Oversight for sure.
> end Client;
Clearly these should be inherited.
> You can't even work around the problem because these are
> nonoverridable aspects. Having nonoverridable non-inherited aspects
> seems like a really bad idea - you can't inherit them and you can't
> explicitly (re)specify them (unless you can figure out how to write a
> confirming specification for a non-inherited aspect),
Yes, clearly an oversight.
> In any case, it seems like useless implementation complexity to allow
> these useless constructs. As far as I can see, allowing these
> constructs isn't doing the user any favors either.
But suppose you have an abstract type derived from a non-abstract type that
has literals? It seems we might want that to be legal.
I would say you can't have a literal of an abstract type, but I see no
particular harm in allowing an abstract type to have an aspect specifying
it has user-defined literals. Non-abstract types derived from the abstract
type is where the literals could actually be used.
> Presumably the specified subprogram for one of these aspect
> specifications can be the dereference of an access-to-subprogram
> Can it be a prefixed view of a subprogram?
> I see no rule disallowing these cases, but I thought I'd check to be
Seems unimportant; if they create any problem I would make them illegal.
> I'd say it is not because, statically, 123 is not a function call and
> literals are not on 3.3's "All of the following are objects"
> seems less clear. Is this legal?
This looks really weird. I don't particularly care whether or not it is
legal. Whatever is simpler. I wouldn't go out of our way to make it legal,
nor make it illegal. Whatever falls out from the rules.
> AI12-0270, which is about cleaning up these object/value issues, is on
> hold. But just because we don't want to tackle the existing problem
> doesn't mean we shouldn't avoid making the situation worse with the
> addition of new features.
Agreed. Again, I don't think it matters much from the point of view of
usability, so the simpler rule is probably the better rule.
> On the other hand, "nominal type" is defined in terms of "nominal
> subtype". However, having an undefined "nominal type"
> doesn't seem to introduce any definitional problems.
> So I don't think there are any problems here, but I thought I'd raise
> the question.
There seems no harm in defining the nominal subtype/type of a user-defined
literal, even if we don't have to for other reasons.
From: Steve Baird
Sent: Friday, August 16, 2019 3:07 AM
> If one of these literals is not an object, then it doesn't have
> a nominal subtype (recall that 3.3 says "At the place where a view of an
> object is defined, a nominal subtype is associated with the view").
> I don't see that this causes any of the problems that
> AI05-0006 was worried about because you cannot case on
> a literal (because the expression of a case statement is
> a complete context).
There is slightly more to this than I thought at first.
I implied that we can't case on a user-defined literal.
I think I was right about casing on an integer literal, as in
case 123 is
because that will always be ambiguous, but this might not be
true for other forms of literals.
The name resolution rules for case statements include
The selecting_expression is expected to be of any discrete type.
so we can case on a literal other than an integer literal and it
is possible that resolution will be successful.
So I think it is possible to have case statements of the form
case 123.45 is
case "dog" is
where the type of the user-defined literal is an enumeration type
(enumeration types are discrete but not numeric).
But since a literal is not a name, the case statement rules
don't care about its nominal subtype so it is ok that
nominal subtype is undefined in these cases.
We don't want this example to be legal
type Enum1 is (Aa, Bb, Cc, Dd, Ee);
type Enum2 is new Enum1 range Bb .. Dd with Real_Literal => R_L;
function R_L (Lit : String) return Enum2'Base is (Ee);
case 1.0 is
when Enum2 =>
but I think that falls out from the current rules.
> Clearly these should be inherited.
I agree, but it needs to be stated explicitly how this works
in the tagged case (for the same reason that we have the 3.9.3
rules about the "if a type other than a nonabstract null extension
inherits a function with a controlling result" case).
We don't want to allow something like
package Pkg is
type T1 is tagged null record
with Integer_Literal => Nested.Not_A_Primitive;
package Nested is
function Not_A_Primitive (Lit : String) return T1 is
type T2 is new T1 with record Field : Float; end record;
X2 : T2 := 123;
and even if we delete the inner package so that
the function becomes a primitive, we still need some rules to
define how the inheritance works.
From: Randy Brukardt
Sent: Friday, August 16, 2019 5:51 PM
> and even if we delete the inner package so that the function becomes a
> primitive, we still need some rules to define how the inheritance
Actually, we need rules to state how it works in any case, 'cause untagged
routines don't magically work without rules, either. (Recall the rules about
type converting the arguments given in 3.4.) I would suggest just requiring
the routine to be primitive for any type, as that way the routine will always
be inherited and thus we wouldn't need to define any rules for what that
means. It's easy enough to define a primitive expression function in the
unusual case where someone needs to declare a non-primitive function as the
user-defined literal routine, so the added expressivity by allowing any
routine in the untagged case doesn't seem worth the complication.
I presume that you are providing a fix-up AI with rules for all of these
issues, right, complete with questions/discussion??? :-)
From: Steve Baird
Sent: Friday, August 16, 2019 6:20 PM
> I presume that you are providing a fix-up AI with rules for all of
> these issues, right, complete with questions/discussion???
Sure, I'll take that action item.
Like you, I'm leaning toward the general idea that the specified function
has to be a primitive operation of the type (I like your approach of requiring
this even in the untagged case). In the untagged case presumably you get
reemergence - overriding an inherited subprogram doesn't change the behavior
of evaluating a literal.
In the tagged case, I see the dynamic semantics of evaluating a literal whose
type has an inherited user-defined-literal aspect as being equivalent to those
of a dispatching call to the function named in the original aspect
specification (having the descendant type's tag as the controlling tag value)
followed by a conversion to the descendant type. So in that case, overriding
an inherited subprogram can change the behavior of evaluating a literal.
I haven't thought about untagged views of tagged types and descendants
thereof, but I don't think there are big problems there.
Obviously wording is needed for all of this (that was your point).
Presumably the 13.1.1 rule that
If a type inherits a nonoverridable aspect from multiple ancestors,
the value of the aspect inherited from any given ancestor shall be
confirming of the values inherited from all other ancestors.
means that the following example is legal
package Pkg is
type Ifc1 is Interface with Integer_Literal => I_L;
function I_L (Lit : String) return Ifc1 is abstract;
type Ifc2 is Interface with Integer_Literal => I_L;
function I_L (Lit : String) return Ifc2 is abstract;
type Concrete is new Ifc1 and Ifc2 with null record
with Integer_Literal => I_L;
function I_L (Lit : String) return Concrete;
and, furthermore, the aspect specification for type Concrete is redundant
and could be omitted without any effect.
From: Steve Baird
Sent: Tuesday, September 10, 2019 7:31 PM
The attached is a new AI, aimed at addressing some of the problems with
user-defined literals that were identified in my ARG mail message of
Aug 15 2019 and in subsequent discussions.
[This is version /01 of the AI, with some missing parts added. - Editor.]
From: Randy Brukardt
Sent: Tuesday, September 24, 2019 10:33 PM
This AI is not ready for prime-time, sadly. You didn't change it at all (at
least I can't see any significant changes) from the version we discussed
privately and was considered the wrong solution.
(1) Editorial: A !proposal section should immediately follow the !problem
section. (I stuck in "See summary."). The !discussion goes after the
wording. I realize you put this where you did because the entire AI is not
really finished given that you ignored the advice Tucker and I gave you
privately -- but this is useless for the ARG -- finish it first.
(2) Abandoning 100% of the existing wording means a complete restart on the
wording. Most likely, all of the wording changes in 4.2 and elsewhere will
also have to be reworded (which you neither did nor made any discussion
about having checked). All of the existing wording was written in terms of a
type having a specified aspect, and that isn't appropriate when an aspect is
(3) Constant_Indexing is only defined for tagged types, and thus the
inheritance rules are built around that. Integer_Literal et. al. have to
work for untagged types, and inheritance of those is squirrely at best.
(4) Similarly, "Nonoverridable" is only well-defined for tagged types.
(5) The "stream-attribute" model seems a better fit for these aspects.
There's no reason to make this overly complicated -- indeed, if it gets much
more complicated, I suspect most of the ARG would simply vote to remove it
(only a handful of people really supported it in the first place -- it has
to be simple). I could even make an argument that the original
no-inheritance model is best for untagged types.
A few specific comments.
>... the "default" inheritance rule described in 13.1(15.2/2) doesn't work.
Right, but you seem to be drawing the wrong conclusion from that. One
*always* has to specify how inheritance works for type extensions as no
default rule could possibly make sense. What happens to the extension
components always has to be defined.
>They feel (I hope I am stating their position correctly) that following
>the "Constant_Indexing model", where the value of the aspect is not a
>subprogram but rather the name of a subprogram, may be unnecessarily
>in the case where the aspect refers to a single subprogram rather than
>to (potentially) a set of subprograms (as is the case with the
>Constant_Indexing aspect). They would prefer something more similar
>to the way that inheritance of streaming attributes is handled. This would
>presumably involve mandatory overriding in the case of a type extension.
At a minimum, we need to try writing up the AI that way to see if it does
simplify the presentation. I personally think the stream attribute model
makes far more sense for these aspects, but in the absence of trying it, we
cannot really know.
>Tuck makes the good point that we need to agree on a meta-rule to decide
>when to use which model so that we don't end up making this decision
>arbitrarily on an aspect-by-aspect basis as new aspects arise.
I proposed a meta-rule in the private e-mail as a starting point for
(1) If any type is allowed, and the profile is fully specified with only a
single match allowed, then use the streaming model.
(2) If only tagged types are involved, and if the profile is only partially
specified, and especially if a family is desired, then use "nonoverriding"
(3) If only tagged types are involved, and the profile is fully specified,
use whichever model makes the most sense. ("Nonoverriding" might work better
for interfaces, not sure.)
(4) In any other case (mainly any type with a partially specified family
profile), please don't do that. ;-)
Note that the only other sensible meta-rule is "Never use the stream
attribute model", but that will require extending the
"Constant_Indexing/nonoverridable" model to support untagged types. (Which I
suspect will be a morass, given that inheritance/overriding of untagged
types has almost no rules, especially about parameter modes and defaults.)
To hack an example from your private mail to show one part of the problem:
type T1 is (T1_Op, T2_Op) with Integer_Literal => I_L;
function I_L (S : String) return T1 is (T1_Op); -- primitive
type T2 is new T1;
function I_L (S : out String) return T2 is (T2_Op);
The overriding function is a legal overriding for an untagged type. But it
is not a legal Integer_Literal aspect. The Constant_Indexing/nonoverridable
model doesn't worry about such cases 'cause they can't happen for tagged
types. Adding a pile of such rules sounds messy and expensive for
>Randy questions whether these new aspects need to be overridable. I think
>we at least want the property (which is a consequence of being overridable)
>that all views of a single type agree with respect to the new aspects.
This is a basic property of aspects (that they are never view-specific); the
question is how that is enforced, not whether it is true or not. As
previously noted, "nonoverridable" prevents certain specifications of
aspects; I don't see any reason to do that here (certainly not for untagged
types). The stream attribute model uses re-specification to handle
redefinition, otherwise the original routine is inherited unmodified.
Note that the stream attribute model essentially makes the stream aspects
primitive operations of the type (and there is no relationship to any
inherited subprograms); that seems to make more sense in this case.
>[TBD: the corresponding uses of function_name instead of direct_name
>in 4.1.6 probably should be changed to match the above; we don't want to
> package Foo is
> type T is ... with Constant_Indexing => Foo.Bar;
> function Bar ... ;
> end Foo;
Why? What's the harm? The requirement for a "primitive function" eliminates
any dynamic names (dereferences are never primitives), so we're only talking
about expanded names. Yes, it's a bit redundant, but I don't see any problem
>A user-defined literal is illegal if the equivalent function call is
>[AARM note: For example, this implies that if the equivalent function call
>is a call to an abstract subprogram then the equivalent function call
>shall be a dispatching call.]
I note that this particular example is not possible in the stream-attribute
model; specified subprograms cannot be abstract. Not sure if that is
>A user-defined integer literal of a type T is illegal if the type T
>does not have exactly one visible primitive function having the name
>specified in T's (explicit or inherited) Integer_Literal aspect
>a result type of T, one parameter of type String, and no other parameters.
>[AARM note: If exactly one such primitive function exists then that is the
>function that is called when the literal is evaluated.]
This is horrible. This is always known when type is defined (since we're
only talking about primitive operations) [at least at the end of the unit in
which it is defined], it needs to be enforced there. That should be the case
even if we end up using the Constant_Indexing model (which clearly is not a
good match given the need for this bizarre rule). Also note that you seem to
be using this to fix up the deficiencies of "nonoverridable" for untagged
types, but that is a terrible approach since the next guy to use
"constant_indexing" on all types is highly unlikely to remember this nuance.
> - each primary that is a literal in one is a user-defined literal
> if and only if the corresponding literal in the other is also a
> user-defined literal. Furthermore, if neither are user-defined
> then they shall have the same values [redundant , but they may have
> differing textual representations]; if both are user-defined literals
> they shall have the same textual representation.
While I agree with this semantics, the term "textual representation" is
undefined in the RM (the only place it appears is twice in the current 4.2.1
-- and that isn't acceptable either). Either we have to define what this
means somewhere in Clause 2 (OK, Chapter 2 to pretty much anyone not using
current ISO terminology), or come up with an alternative.
In particular, "representation" has a formal meaning in Ada (see 13.1), and
this use is very different. 2.2 using the term "text of a program", but
lexical elements are made up of a "sequence of characters". (Thus the two
possible wordings given above.) I note that equivalence of identifiers are
described in terms of a "sequence of characters", so probably that would be
So either say "the sequence of characters of the literal lexical elements is
the same", or define "textual representation of a lexical element" in 2.2 to
mean "the sequence of characters of the lexical element". (Since the latter
doesn't seem to shorten anything much, I'd just use the longer phrase.)
From: Tucker Taft
Sent: Thursday, September 26, 2019 3:57 PM
It seems like Steve ran out of time before his vacation, or simply missed one
of your emails, Randy. I agree that your "meta rule" is a good start, and it
would be nice to discuss it explicitly in the ARG meeting, hopefully with
some examples (since in the abstract it can be pretty hard to decide!).
Questions? Ask the ACAA Technical Agent