On Wednesday, 17 April 2013 at 07:04:16 UTC, Peter Alexander
wrote:
On Wednesday, 17 April 2013 at 01:55:54 UTC, Jesse Phillips
wrote:
On Tuesday, 16 April 2013 at 20:21:00 UTC, Peter Alexander
wrote:
This is the point I have a problem with:
2.2. One cannot opt out of nothrow or pure with auto
functions.
This argument has one solid answer: don't use auto when the
need is to specify an attribute pattern explicitly.
I find this unacceptable. Thanks to the proliferation of
template code in D, it is often rather difficult to spell out
return types. Indeed, this is part of the original reason for
auto's existence. Denying return type deduction for this use
case is a major inconvenience.
How frequently do you write a non-templated function which
returns a complex template type? It isn't something I really
think about, but I'm pretty sure if I am returning a complex
template type I've already got the function a template.
Often enough. I often find myself returning ranges, which are
almost invariably complex template types.
And, to be honest, I would just like to use auto without being
locked into inferred attributes. It just feels wrong that these
things should be conflated, and I get the feeling we will
regret this later on when D starts to be used in larger
projects.
I strongly believe you should never use "auto" for API types,
because it is too easy to break them. If
Dont-Repeat-Yourself/complex types is a problem, they should be
solved at the other end by enhancing function body type inference.
An alternative approach would be to do this optimization during
optimization. However, this means it has to be reimplemented in
dmd, LLVM, GCC separately. This is e.g. the case for
pure-inference in C code.
