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

[Adam Beneschan <adam@irvine.com>]

On Dec 16, 4:25 am, Martin <mar...@thedowies.com> wrote:
> Are there any good arguments for *not* replacing all simple, single
> line functions that don't [directly] access package body state
> information with expression functions?

If you're talking about a function that is declared in the visible
part of a package specification, and talking about replacing the
declaration with an expression function, then it would usually be a
bad idea to replace it.  The visible part should, ideally, express
what the package is intended to accomplish, at a conceptual level.  So
unless the expression is, itself, part of the concept (a rare case),
it's an implementation detail that should not be present in the
visible part of a package.  A good test here, I think, is: "Is it
possible that at some later point, I may change the expression
returned by an expression function because I've added new features to
the package or because I've changed the implementation to improve its
efficiency or fix problems?"  If the answer is yes, then the
expression is probably an implementation detail and not part of the
package's "concept", and the function shouldn't be an expression
function.  I think this is approximately what Dmitry means by "proper
encapsulation".

Offhand, I don't see any problem with replacing simple function
*bodies* with expression functions.  But I haven't studied the new
rules carefully, so I couldn't tell you if there are some "gotchas" in
the language rules that would cause the semantics or the impact on
other language rules to be different.

In most cases, it's probably OK to replace a function specification in
the *private* part of a package with an expression function if the
body is simple.  But the encapsulation argument could still apply if
the function is intended to be usable by child packages.

                             -- Adam