Re: GNAT GPL 2013 bug?

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

On Mon, 12 Aug 2013 10:20:05 -0700 (PDT), Adam Beneschan wrote:

> On Monday, August 12, 2013 10:03:14 AM UTC-7, Dmitry A. Kazakov wrote:
> 
>> That implied null-exclusion for controlling parameters does not change/save
>> anything. Just added language weirdness that
>> 
>>    "access T" is subtype conformant to "not null access T" depending on T
>> 
>> !, for apparently no gain.
> 
> Well, from the point of view of dynamic semantics, a call to a dispatching
> subprogram *has* to fail if given a null parameter.

A dispatching call, you mean, and not fail, but propagate Constraint_Error.
And that does not imply that a non-dispatching call have to. Semantically
they are different.

> There's no way around this.

Actually there is one. Access type is a by-value type. As such it could
have non-tagged classes, using the standard scheme:

   T -> Value
   T'Class -> (T'Tag, Value)

So null access T'Class would become (T'Tag, null) rather than bare null.
Which would make it possible to dispatch on it without assuming that the
target body is always (begin raise Constraint_Error; end). Not that
dispatching on null would be terribly useful, of course...

> So, dynamically, it's going to behave like a null-excluding access
> type no matter what.

Yes, though, as I said, it is because of access T'Class. It is not because
there is something wrong with access T. Smoke and mirrors.

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