On Tuesday, 17 March 2015 at 07:15:17 UTC, Walter Bright wrote:
> On 3/16/2015 4:29 AM, ninja wrote:
>> This. Figuring out the return types in the examples was a daily struggle in the
>> first few weeks.
>
> When Voldemort types are returned, they must be by auto. The user isn't supposed to know what the return type is, just how to use it.

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.

> 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, just store the struct if you've used csvReadder!SomeStruct or store cells individually as Contents if you used csvReader!Contents. (by default Contents is string).

I think it's a very good api.

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.

On Tuesday, 17 March 2015 at 08:46:52 UTC, Almighty Bob wrote:
> On Tuesday, 17 March 2015 at 07:15:17 UTC, Walter Bright wrote:
>> On 3/16/2015 4:29 AM, ninja wrote:
>>> This. Figuring out the return types in the examples was a daily struggle in the
>>> first few weeks.
>>
>> When Voldemort types are returned, they must be by auto. The user isn't supposed to know what the return type is, just how to use it.
>
> 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.

typeof still works for voldemort types. The point isn't "You can't declare variables with a voldemort type" it's the subtly different "You can't declare variables with an *specific* voldemort type".

On Tuesday, 17 March 2015 at 11:39:04 UTC, John Colvin wrote:
> On Tuesday, 17 March 2015 at 08:46:52 UTC, Almighty Bob wrote:
>> On Tuesday, 17 March 2015 at 07:15:17 UTC, Walter Bright wrote:
>>> On 3/16/2015 4:29 AM, ninja wrote:
>>>> This. Figuring out the return types in the examples was a daily struggle in the
>>>> first few weeks.
>>>
>>> When Voldemort types are returned, they must be by auto. The user isn't supposed to know what the return type is, just how to use it.
>>
>> 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.
>
> typeof still works for voldemort types. The point isn't "You can't declare variables with a voldemort type" it's the subtly different "You can't declare variables with an *specific* voldemort type".

s/ an / a /

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.

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

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.

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 thoroughly enjoyed reading this thread. I don't have much experience with Go, but for a quick project, my goto language is typically Python. However, there are definitely areas that Python can be frustrating (where you have to have a loop, parallel processing). I would view D as an ideal language to complement Python's downsides.

As a frequent user of R and the various scientific Python libraries, I found myself agreeing a lot with Russell's comments, particularly that idea of getting D in Jupyter. To me, the infrastructure/community of R or Python is the biggest benefit of those languages. My work is typically at a high enough level that it just doesn't make sense to re-invent the wheel on a lot of things. I don't have the programming knowledge to do something like get armadillo or nlopt or MC Stan to work in D. Tools, like Calypso, that would make it easier to get C++ libraries working would be very important in using D more. I've looked at the source code to a few of those libraries and they look sufficiently complicated that it puts me off the idea of trying to get any of them working myself.

In addition, further development of the ability to call D from R or Python* or Julia (or vice-versa) would also be a positive.

One point that has been discussed thoroughly was learning D from the website. The book is a much better resource than the reference materials on the website for learning D. For instance, if I google d language classes, it takes me to the reference page, which is too confusing for a beginner to the D language. I've learned a lot from it, but it is very hard to make much headway without having read the books section on classes first. Improving tutorials and examples might go a long way. Moreover, quality of tutorials and examples would also be very helpful in terms of getting C/C++ libraries to work and calling code in other languages. The Interfacing to C page in the reference materials is written at a sufficiently high level that I'm still not confident I understand it well enough to use it myself.

*When I google pyd python d language, it takes me to an old link at dsource.org that requires two jumps before hitting a github page with the more recent version of the project (new release 3 days ago!). However, that page doesn't really give you much information about how to use it or anything else.