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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,de8112bdf65b223b X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.79.102 with SMTP id i6mr1736580wix.4.1360469028452; Sat, 09 Feb 2013 20:03:48 -0800 (PST) MIME-Version: 1.0 Path: g1ni1983wig.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!xlned.com!feeder1.xlned.com!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newspeer1.nac.net!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!nrc-news.nrc.ca!goblin2!goblin3!goblin.stu.neva.ru!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.de!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Inheritance of representation aspects Date: Mon, 4 Feb 2013 20:45:23 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1360032325 11588 69.95.181.76 (5 Feb 2013 02:45:25 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 5 Feb 2013 02:45:25 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2013-02-04T20:45:23-06:00 List-Id: "Simon Wright" wrote in message news:lyehgwrl96.fsf@pushface.org... ... > Still, it's be nice for it to be legal (perhaps 13.1(18.2) could be > amended to say that a confirming aspect clause isn't "really" a > specification?! Simpler if (10) just said that > > "For an untagged derived type, it is illegal to specify a > *non-confirming* type-related representation aspect if the parent type > is a by-reference type, or has any user-defined primitive > subprograms." Since 13.1(10) long predates the notion of "confirming" rep. clause, it doesn't surprise me. Personally, I'd much prefer if this rule didn't exist (although it does eliminate some weird cases that we'd otherwise have to deal with). It makes it virtually impossible to use an untagged derived type for anything valuable (no representation changes unless there are no operations -- in which case what is the point of supporting a representation change). I've never gotten any traction on that, and I doubt that I ever will, so mainly I think, forget about untagged derived types as a useless appendage of the language. (It's not worth fixing this rule, as it still won't allow anything useful other than silly test programs.) Randy.