comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: User-Defined Reference in a Task Type Discriminant Compiler Bug?
Date: Thu, 21 Mar 2013 18:49:21 -0500
Date: 2013-03-21T18:49:21-05:00	[thread overview]
Message-ID: <kig6a8$ada$1@munin.nbi.dk> (raw)
In-Reply-To: 4ef5e6b7-aab3-4229-a245-97dfc5861b8d@googlegroups.com

"Eryndlia Mavourneen" <eryndlia@gmail.com> wrote in message 
news:4ef5e6b7-aab3-4229-a245-97dfc5861b8d@googlegroups.com...
...
>Note that the declaration of Inc_Type in (1) is properly recognized as an 
>access-to-subprogram
>type without the aspect clause.  I find it odd that the declaration of the 
>discriminant + aspect clause
>given a similar circumstance will not compile.  It appears to prevent 
>implicitly the type of construct
>in (1), which seems to me to be legal Ada code.

It's not, Adam explained why. "Access discriminant" only refers to 
discriminants with an anonymous access type. This is important because 
special accessibility rules apply to such discriminants, and those 
accessibility rules are what makes it safe to return these things. 
(Essentially, it is almost impossible to copy the access value, and that 
means that it can only be used for immediate dereferencing.)

As far as using an access-to-subprogram in one of these, I don't think we 
ever considered that. It's not particularly useful, either, as the primary 
intention was to provide convinient write-in-place for elements of 
containers. But you can never write to a subprogram call. You can get the 
same effect by just returning the access type from a function; you don't 
need the "Implicit_Dereference" mechanism for that. So it doesn't surprise 
me that it doesn't work in GNAT.

I don't understand your use-case, either. If you want to call the 
access-to-subprogram discriminant from inside the task, just do that -- the 
Implicit_Dereference is not necessary. And if you want the routine to 
somehow call the task, I don't think that's likely to work -- you won't be 
able to get access to the task object from inside the subprogram and thus 
you can't call an operation of the task from there. So I don't see any point 
to what you're trying to do.

                                  Randy.






  parent reply	other threads:[~2013-03-21 23:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-21 15:11 User-Defined Reference in a Task Type Discriminant Compiler Bug? Eryndlia Mavourneen
2013-03-21 19:11 ` Shark8
2013-03-21 19:12 ` Adam Beneschan
2013-03-21 19:43   ` Simon Wright
2013-03-21 23:49 ` Randy Brukardt [this message]
2013-03-22  1:15 ` Eryndlia Mavourneen
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox