From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Inheritance of representation aspects
Date: Mon, 4 Feb 2013 20:45:23 -0600
Date: 2013-02-04T20:45:23-06:00 [thread overview]
Message-ID: <kepro5$ba4$1@munin.nbi.dk> (raw)
In-Reply-To: lyehgwrl96.fsf@pushface.org
"Simon Wright" <simon@pushface.org> 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.
prev parent reply other threads:[~2013-02-05 2:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-03 16:27 Inheritance of representation aspects Simon Wright
2013-02-04 17:32 ` Adam Beneschan
2013-02-04 18:23 ` Simon Wright
2013-02-05 2:45 ` Randy Brukardt [this message]
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox