Re: Interresting, possibly buggy behavior in GNAT generics w/ expression function.

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1ilubaaaex6jp$.zd9lslst85nn.dlg@40tude.net...
> On Fri, 29 Mar 2013 19:56:05 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1ex3dm2hk2j54$.1uiyljwziv0hi$.dlg@40tude.net...
>> ...
>>>> But, do you think it should have failed at instantiation?
>>>
>>> It should fail to compile, instantiation time is too late. Generic
>>> contracts are much too weak.
>>
>> This doesn't make much sense, as you then go on to suggest adding a 
>> formal
>> contract which would have the effect of rejecting an instantiation if the
>> type actually had Foo. That's exactly what Ada does, so I don't see any
>> advantage of a complication.
>
> That is because you consider only one possibility, that is a client-side
> error. Then instantiation is the right time to report this contract
> violation. For the generic package itself this time is when the generic is
> compiled.
>
> My example had the purpose to show that matching formal parameters is not
> enough. It could illustrate an error in the generic itself as well, e.g.
> when *all* intended actual types for instantiations of P have Foo per
> design.

True. But I don't think it is possible to unambiguously tell which side of 
the contract is wrong, in general. You have the same problem with a 
subprogram profile: it's possible that the error is that the subprogram is 
wrong for its intended use, or that the clients are using it wrong.

>> The problem you are having is that you are viewing the contract of a 
>> generic
>> in too narrow of a fashion. The contract includes not only the things in 
>> the
>> generic part, but also a number of properties expressed in the rest of 
>> the
>> specification.
>
> You lumped together two different contracts. There is a contract on the
> actual parameters which is defined by be the formal parameters
> specification. Another contract is the generic package specification
> (public part), which is a contract for the clients using an instance of 
> the
> package.

No I didn't - I'm only talking about the contract of a generic unit. The 
case in question is the meaning of "not overriding" in a generic 
speecification. Uses of overriding indicators in a generic specification is 
part of the contract of the generic, as are various other things (like 
accessibility checks - it's easy to write a generic that can only be 
instantiated at library level). The contract of a generic also includes the 
things in generic formal part (between "generic" and "package"). None of 
this has anything to do with parameters - I don't know what gave you that 
idea.

                         Randy.