Re: Ada2012 : When to use expression functions rather than function bodies?

["Randy Brukardt" <randy@rrsoftware.com>]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:12acbf57-01fc-43dd-8881-d39c2a63146b@q9g2000yqe.googlegroups.com...
...
>Apparently the ARG thought this was a good argument.  I'm not
>endorsing it personally -- I don't have a particular opinion -- but it
>appears sensible on its face.

One of the things we learned when thinking about Preconditions and the like 
is that there is such a thing as too much encapsulation. The entire point of 
preconditions is that they be understandable to the client, so the client 
(caller) knows what they must ensure before calling the routine.

You could write all of your preconditions like:

     procedure Do_It (A, B : in out Integer)
         with Pre => Do_It_Precondition (A, B);

but no one would have any idea what the precondition is. After all, an 
important part of the point of preconditions is to change what currently is 
specified in English in the comments in a more formal way that can be 
checked (statically and dynamically).

So it is best to use as little encapsulation as possible in preconditions 
and the like, breaking them down to the primitive operations of the type(s) 
involved.

But preconditions can get very long, and the need to simplify them for 
readability surely exists. Thus expression functions provide a middle 
ground. They're also handy for simple accessor functions (which can give the 
effect of read-only components of a private type).

There also is one more fact: an expression function can almost always be 
inlined (beware of recursion, though), and that can be done automatically 
when it makes sense (no need for pragmas or body dependencies -- inlining is 
something the compiler should be deciding upon anyway, it is stupid for 
users to have to declare something that should always be done if it makes 
sense -- and not be done when it doesn't make sense).

                                        Randy.