From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,556e5b18154df788 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.224.172.134 with SMTP id l6mr2449743qaz.7.1364575416152; Fri, 29 Mar 2013 09:43:36 -0700 (PDT) X-Received: by 10.50.150.180 with SMTP id uj20mr53900igb.7.1364575416111; Fri, 29 Mar 2013 09:43:36 -0700 (PDT) Path: v17ni9qad.0!nntp.google.com!ca1no16395318qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 29 Mar 2013 09:43:35 -0700 (PDT) In-Reply-To: <1ex3dm2hk2j54$.1uiyljwziv0hi$.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.20.190.126; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 69.20.190.126 References: <1k6ipbtagwzw4$.1dv47rfygcedg.dlg@40tude.net> <1ex3dm2hk2j54$.1uiyljwziv0hi$.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <64b868ed-6e6e-4bc9-97ca-72ed20fc5a54@googlegroups.com> Subject: Re: Interresting, possibly buggy behavior in GNAT generics w/ expression function. From: Shark8 Cc: mailbox@dmitry-kazakov.de Injection-Date: Fri, 29 Mar 2013 16:43:36 +0000 Content-Type: text/plain; charset=ISO-8859-1 Date: 2013-03-29T09:43:35-07:00 List-Id: On Friday, March 29, 2013 10:21:39 AM UTC-6, Dmitry A. Kazakov wrote: > On Fri, 29 Mar 2013 14:45:33 +0000, Simon Wright wrote: > > > "Dmitry A. Kazakov" writes: > > > >> On Fri, 29 Mar 2013 07:45:04 +0000, Simon Wright wrote: > >> > >>> I don't know whether this is a language problem > >> > >> It is a general language problem that generic specifications and bodies > >> cannot be fully checked. Matched formal parameters only is not sufficient. > >> Much better than with C++ templates, but still same mess. > > > > 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. I'm not sure I believe that [they are too weak] -- in any case this isn't a problem of the weakness of generics, it's a case of the compiler choosing a function which it should not dependent upon information it should not "know". Keeping the instantiation of Package Margins is new Generic_Attribute_Set( Attribute_Name => "margin-left", Attribute_Values => Integer, --J, Attribute_Units => Screen, Units => Units ); altering the profile of Image [in the generic] from: Function Image(Value : Positive) Return String is to: Function Image(Value : Natural) Return String is alters the behavior from: margin-left="88%" to: margin-left="884" The issue disappears entirely if an enumeration is supplied for attribute_values so that the correct Image is chosen in either case of Image/Natural or Image/Positive. > > For example: > > generic > type S is new T with private; > package P is > type Q is new S with null record; > not overriding procedure Foo (X : Q); > > It is uncheckable if S does not have Foo already. Thus, this must be a > compile error. > > If we wanted properly contracted generics (personally, I don't care), we > would need some syntax to tell that S may not have operation Foo, e.g. > > generic > type S is new T with private; > not with procedure Foo (X : S); > package P is > type Q is new S with null record; > That's a good point, perhaps you should submit an AI?