Attribute inference for non-templated functions

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Wed Mar 30 10:27:22 PDT 2016


On Wednesday, March 30, 2016 15:26:21 Seb via Digitalmars-d wrote:
> On Wednesday, 30 March 2016 at 12:57:56 UTC, Mathias Lang wrote:
> >> My question is whether this is just an open issue (I couldn't
> >> find it) or a design decision?
> >
> > It's a design decision. You want to be able to fix the exact
> > type of your function, in order to provide headers for them for
> > example (so you can work with libraries for which the source
> > code is not available).
> >
> > If you want attribute inference, you can either make it a dummy
> > template or, with a recent enough compiler, use `auto` return
> > type.
>
> OK so it makes sense to recommend to always use `auto` for
> non-templated functions in high-level parts of Phobos?
> The current guideline recommends to specify the return type for
> better readability in the code and documentation, but I guess the
> latter can be eventually fixed and having automatic attribute
> inference is way more important than the first point?
>
> (given that most of Phobos makes extensive use of templates, this
> shouldn't be a huge issue anyway)

There is no reason for non-templated functions to infer attributes other
than because people don't feel like typing. And by making them explicit,
it's clear in the documentation what the attributes are, and it's guaranteed
not to change just because some tweak in the implementation was made which
happened to change the attribute inference.

For templated functions, on the other hand, attribute inference is a must,
because it usually depends on the template arguments, which means that
without attribute inference, you're either forced to pick a set of
attributes (thereby limiting the arguments which will work with that
template), or you have to duplicate the template for each possible
combination of attributes. So, attribute inference for templates solves a
real practical problem, whereas for non-templated functions, all it does is
save typing. And actually, in cases where you have a template function, but
an attribute does _not_ depend on the template arguments, then I'd argue
that it should have explicit attributes as well. It's when the attributes
really depend on the template arguments that it matters.

In the general case though, the big reason that normal functions don't do
attribute inference now that we have it for templates is because D allows
for linking against function prototypes without having the source code, in
which case, infering attributes isn't possible. However, both templates and
auto return functions are guaranteed to have their bodies present, so they
don't have that problem.

Regardless, I would argue that the rule of thumb for attributes is to be
explicit about them except when they need to be infered because of template
arguments. Some folks would prefer to drop them to save typing for auto
functions, but doing that makes the documentation less clear and increases
the risk that the attributes will accidentally change - which is part of why
it can be critical to have unit tests which verify that the correct
attributes are infered for a given block of code.

- Jonathan M Davis



More information about the Digitalmars-d mailing list