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: 103376,5a88548f1bcf3510 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Received: by 10.66.83.35 with SMTP id n3mr6325228pay.23.1352595733369; Sat, 10 Nov 2012 17:02:13 -0800 (PST) Path: s9ni4182pbb.0!nntp.google.com!news.glorb.com!us.feeder.erje.net!feeder.erje.net!eu.feeder.erje.net!news.mixmin.net!aioe.org!.POSTED!not-for-mail From: =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= Newsgroups: comp.lang.ada Subject: Re: Overring function and its returned type Date: Sun, 11 Nov 2012 02:02:09 +0100 Organization: Ada @ Home Message-ID: References: NNTP-Posting-Host: aWaWeUaBdaj2Zzc04J1v5A.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.02 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable Date: 2012-11-11T02:02:09+01:00 List-Id: Le Sat, 10 Nov 2012 08:55:11 +0100, Randy Brukardt = a =C3=A9crit: > I'd strongly suggest to use different names for different types in = > examples, > otherwise you'll confuse everyone (and yourself). Just because you can= = > use > the same name in the real code (and might want to in unusual = > circumstances) > is no good reason to make examples that confuse the heck out of everyo= ne. Though it was clear, since there was package prefixes. Hope every one wh= o = has read it understood it the way it was to be. > Since overriding requires subtype conformance (among other things, = > requiring > the same subtype on all non-controlling parameters and results), and > R2'Class /=3D R'Class (and this isn't a controlling result), no overri= ding = > is possible. That's how it is actually, yes. > There are good reasons for these restrictions (mostly > implementation-oriented). Not convinced at all, as I gave an Ada interpretation of this, using a = postcondition and a type conversion, which can be checked to be valid: i= f = you replace the postcondition by a proper returned result type, the = postcondition is statically checked and not needed any more, and the sam= e = for the type conversion. I also explained why one could expect Ada to = obviously support it. I don't believe they are implementation issue here= , = except may be AdaCore or their clients not being at all interested in th= is = kind of constructs (I name AdaCore, as there seems to be the near only = ones implicitly referred to, when talking about compiler implementation,= = and good reason for integration of Ada features). Dmitry's idea of a more general application of the same principle is nic= e, = but may indeed present more issues. I gave one example issue, but I'm = thinking about another even with simple `in` mode parameters. I still = believe his idea should be feasible too and good for Ada (and to be as = much sounds). > I'm sure there exist (very limited) cases where it might make sense to= = > relax > subtype conformance, but there would need to be a strong justification= = > for > the significant added complication in the language rules and = > implementation. > I'm pretty certain that an example using types T and R isn't it. > > In any case, Ada 2012 is finished (with possibility of some editorial > corrections in the final edition, but nothing substansive). If we were= = > going > to fix anything in it, it would be the handful of bad bugs that have b= een > identified, surely nothing involving features that are unchanged in Ad= a = > 2012 > (which is the case with overriding, modulo wording bugs). Yes, I understand it's far too late for Ada 2012. I will wait and send a= = proposal to the Ada=E2=80=91Comment list a future day (I believe not bef= ore some = months), =E2=80=A6 this will leave enough years to figure the case in de= eper = details. -- = =E2=80=9CSyntactic sugar causes cancer of the semi-colons.=E2=80=9D [1] =E2=80=9CStructured Programming supports the law of the excluded muddle.= =E2=80=9D [1] [1]: Epigrams on Programming =E2=80=94 Alan J. =E2=80=94 P. Yale Univers= ity