"Niklas Holsti" <niklas...@tidorum.invalid> wrote in message
news:ikrlsp...@mid.individual.net...
...
>> Is this "type-less" naming a copy of the popular omission schemes
>> like auto in C++? Optional type annotations in Swift, or Scala?
>
>
> I don't know all the origins of this language change, but it can be seen
> as a correction because it avoids the wart in the earlier Ada form of
> renaming, where a (sub)type name is included. The wart is that the
> constraints of that (sub)type are essentially ignored, and so can be
> misleading.
Right; the name of the type is often a lie vis-a-vis the subtype properties;
moreover, it is often the case that the type is included in the renamed
item:
Foo : renames Some_Type'(Bar(Obj));
Repeating the type in such cases is not useful and violates DRY ("Do Not
Repeat Yourself"):
Foo : Some_Type renames Some_Type'(Bar(Obj));
We felt this was something that was better handled by style guides rather
than imposing unnecessarily wordy syntax.
The actual motivation behind this change was a strong desire for a shorter
way to write bindings in declare expressions. We tried a number of things,
but they all seemed oddly special case. Eventually, we settled on using
normal syntax throughout declare expressions, but simplified the syntax for
renaming in all cases. The tipping point was noticing the duplication in
examples like the above, along with the fact that the subtype given is
ignored anyway.
If we were designing Ada from scratch, the subtype in a renames would have
to statically match the nominal subtype of the name being renamed. But that
wasn't required in Ada 83 and it would be way too incompatible to require
now. (The reason that Ada 83 didn't require it? Jean Ichbiah didn't want to
have to define "static matching" -- according to an old thread that John
Goodenough dug up. Of course the Ada 9x team decided such a concept was
necessary and added it to the language, so we ended up with most constructs
using static matching, but renames being different.)
Randy.