Attribute inference for non-templated functions

[Anon via Digitalmars-d]

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.