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

[Atila Neves via Digitalmars-d]

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