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,4ce5890331a5b529 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!g13g2000yqj.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Discriminants of tagged types Date: Wed, 27 Oct 2010 08:06:24 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <14314714-e92c-4036-9cbb-da8e72489261@h7g2000yqn.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1288191984 7019 127.0.0.1 (27 Oct 2010 15:06:24 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 27 Oct 2010 15:06:24 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: g13g2000yqj.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:14836 Date: 2010-10-27T08:06:24-07:00 List-Id: On Oct 27, 6:44=A0am, Robert A Duff wrote: > Maciej Sobczak writes: > > GNAT says that discriminants of tagged types cannot have default > > values. > > Well, Ada says that. =A0GNAT is just following orders. =A0;-) > > > but this is an error: > > > =A0 =A0type T (A : Integer :=3D 0) is tagged null record; > > We tried very hard during Ada 9X to allow this, but > we kept running into semantic difficulties, which required > more and more complicated rules to fix. =A0One day, > Tucker said to me (or I said to Tucker -- I don't > remember which), let's just outlaw this. =A0We both > agreed it was a big simplification. > > Sorry, I don't remember in detail what the semantic > difficulties were. =A0Ludovic's explanation seems > as good as any. AARM 3.7(9.d): "Defaults for discriminants of tagged types are disallowed so that every object of a tagged type is constrained, either by an explicit constraint, or by its initial discriminant values. This substantially simplifies the semantic rules and the implementation of inherited dispatching operations. For generic formal types, the restriction simplifies the type matching rules. If one simply wants a 'default' value for the discriminants, a constrained subtype can be declared for future use." One issue with untagged types with default discriminants is that if you define a type like that: type Rec (Discr : Integer :=3D 0) is record ... and declare a procedure with an IN OUT parameter of that (unconstrained) type: procedure Proc (R : in out Rec) is begin ... R :=3D (Discr =3D> R.Discr + 1, [other components =3D> ...]) -- whether this is allowed depends on the actual parameter end Proc; you could declare both an unconstrained and constrained object of that type and pass them both to Proc: R1 : Rec; R2 : Rec(10); Proc (R1); Proc (R2); Proc is allowed to assign a new value to R that changes the discriminant, but it has to know that if R2 is the actual parameter, the discriminant is not allowed to change. This requires additional information to be passed to Proc so that it knows whether to raise Constraint_Error when the assignment to R happens. Apparently it was felt that where tagged types, class-wide types, and dispatching were involved, this would make things too complicated. This may seem "annoying" to those who think that a default discriminant is *just* a default (rather than creating a different kind of type that allows the creation of both constrained and unconstrained objects). But the last sentence of the AARM note shows that the workaround is simple enough. (Personally, I would have preferred that the two concepts not be mixed, and that there be two syntaxes---one for specifying a default value for discriminants, and another to specify that unconstrained objects of the type can be created. It's not the only case where having one syntax do "double duty" ends up causing problems. I think AI05-154 is a symptom of this, in which putting a constraint on a nominal array subtype not only specifies a constraint but also tells the compiler that an 'Access can't be used as an access-to-unconstrained-array value, causing headaches when you want to include a constraint but *also* want the ability to have an access-to-unconstrained-array point to the object; another case, perhaps, where "double duty" may have seemed like a clever solution to avoid extra syntax, but turned out not to be such a good idea.... But I'm starting to rant a bit.) -- Adam