On Wednesday, 30 March 2016 at 15:26:21 UTC, Seb 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?
No. Non-templated public API should make it clear what guarantees
it has. The easiest way to do this is explicitly mark any @safe,
pure, etc, just as you explicitly mark the type.
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?
Being able to tell what guarantees a method has (and ensure they
can't accidentally be broken in updates) is way more important
than automatic inference. If you use automatic inference for a
public API, you then need to write unittests to make sure it
stays @safe, pure, etc. If you mark things explicitly, the
compiler does those tests for you at compile-time.
(given that most of Phobos makes extensive use of templates,
this shouldn't be a huge issue anyway)
Templates have little choice but to infer attributes. A bit more
rigor in public-facing non-templates is affordable and desirable.
