A few notes on choosing between Go and D for a quick project

Atila Neves via Digitalmars-d digitalmars-d at puremagic.com
Tue Mar 17 05:51:58 PDT 2015

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());


More information about the Digitalmars-d mailing list