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

[John Colvin via Digitalmars-d]

On Tuesday, 17 March 2015 at 18:29:20 UTC, Almighty Bob wrote:
> On Tuesday, 17 March 2015 at 11:48:15 UTC, Nick Treleaven wrote:
>> On 17/03/2015 10:31, Almighty Bob wrote:
>>> 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.
>>
>> Part of the art of API design is to hide implementation where 
>> it's not necessarily needed. Designers might err on the side 
>> of hiding things, because how you expose something is 
>> important as it has to be maintained indefinitely. If they 
>> expose everything then the internals can never be redesigned 
>> for better performance, etc.
>
> They don't increase encapsulation. The public members of a 
> voldomort type are still public, you still have to code to the 
> API of the return type whether it's a regular or voldomort 
> type. You can keep as much private or public in either case as 
> you like.
>
> All they do take the typename out of circulation, they make 
> life harder for the user. There's no benefit. None.
>
> But at least the library author can stroke his chin a feel smug 
> that there's one less type in the modules' namespace.

Totally missing the point. The crux of the matter is this: 
changing a voldemort type (assuming the public semantics are the 
same) is not a breaking API change, because no-one else's code 
ever names it.

Admittedly this is sort-of true for any function that returns 
auto and doesn't document its return type, but that is by 
convention (the type is always readable in the relevant .d or .di 
file) whereas using a voldemort type enforces it.

Note that if you really want a name to use in your code:
alias IotaFloat = typeof(iota(0f, 2f, 1f));