On Tuesday, 17 March 2015 at 18:32:10 UTC, Almighty Bob wrote:
On Tuesday, 17 March 2015 at 12:52:01 UTC, Atila Neves wrote:
On Tuesday, 17 March 2015 at 10:31:06 UTC, Almighty Bob wrote:
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
That proves my point cost for the user just so the library
designer can group his type inside the function that returns it.
How many times is csvReader used vs how many times is it
written. It it's 100 to 1, that's 100 times the cost to the
user vs 1 x the cost to the library author.
I cant help thinking it's like how when programmers first learn
about design patterns they start trying to make everything they
can into a ****ing singleton.
I have on a number of occasions wanted this:
struct S {
Iota r; // ?? Would be nice, can it be done ??
}
if(something) {
s.r = iota(10);
} else {
s.r = iota(0, 10, 2);
}
As a new D user and relatively new to programming I've tried
really hard to find a way to do this and given up. If it's
possible I'd love to know!!
I did try the template approach with "function return type part
of my struct type" route but it a) made my code very messy with
templates everywhere even where I didn't want them and b) the
compiler memory usage blew out to over 4Gb with 2.067 and I could
not compile my project.
I had to take it all out again and in the end implemented my own
iota with my original approach (as above). I'm not doing that
again.
bye,
amber
