On Tuesday, 17 March 2015 at 10:31:06 UTC, Almighty Bob wrote:
On Tuesday, 17 March 2015 at 09:25:57 UTC, Panke wrote:
How do you keep it around if you cant declare a member to
hold it?
It's all well and good explaining the reason for them but it
doesnt void the fact that they are a PITA if you say want to
use cvsReader to parse some records and keep the results as a
class member.
I don't think csvReader supports your point. The input range
returned is not for permanent storage,
How do you know it's not meant for permanent storage? The docs
dont say that. Is that a typical idiom with returned ranges?
And what's the point of an all singing and dancing API if it
imposes pointless restrictions on the user for the sake of some
questionable benefit for the library writer?
It's far more useful for csvReader to return a type I know and
can use than it is to obscure the return type for the sake of
some philosophical ideal of increasing encapsulation.
In short, for the user, Voldomort types have no benefit and only
cost.
This discussion happens often when discussing C++'s or D's
`auto`. It doesn't matter what the type is, what matters is in
the interface.
As for storing it:
auto foo = voldemort();
Oh, you meant in a struct?
struct Foo(T) {
T thingie;
}
auto foo(T)(T thingie) {
return Foo!T(thingie);
}
auto f = foo(voldemort());
Atila
