Re: Legit Warnings or not

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:bvr7wfbofhal$.10mess7c3uv9j.dlg@40tude.net...
> On Fri, 22 Jul 2011 19:36:26 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1rx6dwrxmc81p.eazb4fjqztox$.dlg@40tude.net...
>> ...
>>> I think that Ada should not try to support this stuff.
>>
>> Ada *does* support this stuff. As Adam noted, there are rules preventing 
>> the
>> creation of accesses/renames of/into components that might change size.
>
> But it should not. Programmers expect types constructed by the compiler be
> contiguous in their private view.

Why? Only the semantics of the objects should matter to the programmer; the 
rest of it should be left to the implementers.

Besides that, it is impossible to implement Ada with solely contiguous 
objects -- the ability to pass slices means that array descriptors and the 
actual data have to be handled separately. These clearly are parts of a 
single object (you cannot replicate the semantics of the Ada object without 
the descriptor part).

>> There also are rules supporting allocation/deallocation of objects that 
>> have
>> multiple parts. So far as I know, those are the only rules needed to do 
>> so.
>
> Meaningful X'Size?

X'Size is not meaningful for unconstrained types and never has been. I'd 
probably go further and say that the language definition is 'Size is close 
to useless; only what GNAT calls 'Object_Size is valuable (and it is 
unfortunate that we couldn't get agreement to put that into the language).

> Expectations in an implementation of
> Ada.Finalization.Adjust?

The semantics of the language doesn't care if objects are contiguous or not. 
This is all invisible to the programmer if done right.

>> There also are rules supporting allocation/deallocation of objects that 
>> have
>> multiple parts. So far as I know, those are the only rules needed to do 
>> so.
>
> E.g. in a user-defined specific pool?

Correct; the language allows multiple calls to Allocate for a single use of 
"new". It also allows Allocate to be called on assignment if the object 
needs to change size (by far the most complex part of handling mutable 
objects properly).

>> And, as noted, Janus/Ada always has worked this way. I originally thought
>> Ada compilers were expected to work this way, because there is no good
>> reason not to support this as the default (as noted, some target
>> environments might not want such objects, and pragma Restrictions can 
>> surely
>> be used to prevent them from being generated). But apparently, 
>> implementers
>> are lazy enough to avoid it, and customers have never pushed hard enough 
>> to
>> get it added as an option.
>
> As a customer I see that the language separates definite and indefinite
> types. If this distinction is necessary, then the same logic applies to 
> the
> implementation. I prefer transparent and simple implementations in order 
> to
> know what to expect. In cases where I need referential semantics I prefer
> to implement it by myself, rather than to rely on the compiler.

I don't think the distinction between definite and indefinite types IS 
necessary; it just one of many expediencies in the Ada language designed to 
ease implementation. They don't always help, and there is little value to 
forcing the same mistake on users.

                                  Randy.