The following reminds me of the good old C++ template errors the C++ compiler spits out.

Whilst D has fixed that problem, some things have gotten more complex. I just wanted to find a replacement for D1 path join, and found this, but it doesn't seem very easy to wade though this stuff.


immutable(ElementEncodingType!(ElementType!Range))[] buildPath(Range)(Range segments) if (isInputRange!Range && isSomeString!(ElementType!Range));
pure nothrow @safe immutable(C)[] buildPath(C)(const(C)[][] paths...) if (isSomeChar!C);

http://dlang.org/phobos/std_path.html

It would take me a lot of time to appeciate what that all means, although I can imagine what it is for.

...just and observation. The complexity is building.

Hi!
I completely agree. D1 is much better :-) I removed a threading
support from my variant  because program don't start if OS don't have
a POSIX threading (LInux 2.4.37 for example). A garbage colllector can
be disabled (as I understand). May be a compiler support (warnings) is
needed if gc will be used (needed) in the code

With such changes D1 can be used for Linux kernel modules. But I don't done this yet. I nice stuff: libc written in D (a small part of the uCLibc, not finished)

PS: trying to understand a D backend I removed all stuff related to
the C++ and win32
PPS: what is the rigth way to connect a backed to the frontend? I
studied only d-to-js, d-to-c, d-to-c#, tdc and some version of the D0
compiler with custom asm generator (GDC and LDC are not studied)


2015-08-30 5:42 GMT+03:00, Spacen Jasset via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>:
> The following reminds me of the good old C++ template errors the C++ compiler spits out.
>
> Whilst D has fixed that problem, some things have gotten more complex. I just wanted to find a replacement for D1 path join, and found this, but it doesn't seem very easy to wade though this stuff.
>
>
> immutable(ElementEncodingType!(ElementType!Range))[]
> buildPath(Range)(Range segments) if (isInputRange!Range &&
> isSomeString!(ElementType!Range));
> pure nothrow @safe immutable(C)[] buildPath(C)(const(C)[][]
> paths...) if (isSomeChar!C);
>
> http://dlang.org/phobos/std_path.html
>
> It would take me a lot of time to appeciate what that all means, although I can imagine what it is for.
>
> ...just and observation. The complexity is building.
>

On Sunday, 30 August 2015 at 02:42:30 UTC, Spacen Jasset wrote:
> immutable(ElementEncodingType!(ElementType!Range))[] buildPath(Range)(Range segments) if (isInputRange!Range && isSomeString!(ElementType!Range));
> pure nothrow @safe immutable(C)[] buildPath(C)(const(C)[][] paths...) if (isSomeChar!C);

I understand how you feel. When I was learning D, the docs where almost impenetrable because of this. But when I got into some of the more advanced features of D, I found these explicit function signatures invaluable. This essentially tells you that the function takes either a range of strings, or it can take indefinite number of strings as different arguments.

Also, examples underneath the function signature help new comers understand how to call the function without having to parse it.

On Sunday, 30 August 2015 at 02:42:30 UTC, Spacen Jasset wrote:
> immutable(ElementEncodingType!(ElementType!Range))[] buildPath(Range)(Range segments) if (isInputRange!Range && isSomeString!(ElementType!Range));
> pure nothrow @safe immutable(C)[] buildPath(C)(const(C)[][] paths...) if (isSomeChar!C);

this is stodgy, particularly in a console with line wrapping at 80 chars.

On Sunday, 30 August 2015 at 07:36:55 UTC, BBasile wrote:
> On Sunday, 30 August 2015 at 02:42:30 UTC, Spacen Jasset wrote:
>> immutable(ElementEncodingType!(ElementType!Range))[] buildPath(Range)(Range segments) if (isInputRange!Range && isSomeString!(ElementType!Range));
>> pure nothrow @safe immutable(C)[] buildPath(C)(const(C)[][] paths...) if (isSomeChar!C);
>
> this is stodgy, particularly in a console with line wrapping at 80 chars.

Could have been written as

auto buildPath(Range)(Range segments)
if (isInputRange!Range && isSomeString!(ElementType!Range));

but having an explicit return type is super valuable information. But the opportunity to omit it makes implementing a first working version so fast that it is pure joy.

And the constraints you need not read - unless you want to understand why your call to the function failed. C++ is just lacking without them. Having them avoids that you always have to handle ridiculous input within your functions and allows to concentrate on meaningful code.

On Sunday, 30 August 2015 at 09:55:02 UTC, Dominikus Dittes Scherkl wrote:
> And the constraints you need not read - unless you want to understand why your call to the function failed. C++ is just lacking without them. Having them avoids that you always have to handle ridiculous input within your functions and allows to concentrate on meaningful code.

Maybe we should color thoses things, having syntax highlighting for template and functions signatures would be great.

On Sunday, 30 August 2015 at 07:36:55 UTC, BBasile wrote:
> On Sunday, 30 August 2015 at 02:42:30 UTC, Spacen Jasset wrote:
>> immutable(ElementEncodingType!(ElementType!Range))[] buildPath(Range)(Range segments) if (isInputRange!Range && isSomeString!(ElementType!Range));
>> pure nothrow @safe immutable(C)[] buildPath(C)(const(C)[][] paths...) if (isSomeChar!C);
>
> this is stodgy, particularly in a console with line wrapping at 80 chars.


To be fair is was the docs page I was reading not a compiler diagnostic, but I did get something a bit shorter from the compiler once.

It's slighty hard to see that you can give that function a string, and that it can return a string like thing -- although on that score too I've found I have to use char[] in some places instead of string which is to do with immutability, that I've not quite worked that out yet either -- It's just a feeling I have when looking at this now that it is quite complex.

I only mention this as it was something that I think other people may notice too, when starting out, or coming back to D.

Maybe I've just been doing too much python recently.

On Sunday, 30 August 2015 at 10:42:24 UTC, Spacen Jasset wrote:
> On Sunday, 30 August 2015 at 07:36:55 UTC, BBasile wrote:
>> On Sunday, 30 August 2015 at 02:42:30 UTC, Spacen Jasset wrote:
>>> immutable(ElementEncodingType!(ElementType!Range))[] buildPath(Range)(Range segments) if (isInputRange!Range && isSomeString!(ElementType!Range));
>>> pure nothrow @safe immutable(C)[] buildPath(C)(const(C)[][] paths...) if (isSomeChar!C);
>>
>> this is stodgy, particularly in a console with line wrapping at 80 chars.
>
>
> To be fair it was the docs page I was reading not a compiler diagnostic, but I did get something a bit shorter from the compiler once.

Oh i see. Then i don't agree. Doc is very nice. The problem is that you have to know std.traits and std.range to understand the constraints. It's not always obvious but i'd say it's about 30 or 40 functions.

On Sunday, 30 August 2015 at 02:42:30 UTC, Spacen Jasset wrote:
> The following reminds me of the good old C++ template errors the C++ compiler spits out.
>
> Whilst D has fixed that problem, some things have gotten more complex. I just wanted to find a replacement for D1 path join, and found this, but it doesn't seem very easy to wade though this stuff.
>
>
> immutable(ElementEncodingType!(ElementType!Range))[] buildPath(Range)(Range segments) if (isInputRange!Range && isSomeString!(ElementType!Range));
> pure nothrow @safe immutable(C)[] buildPath(C)(const(C)[][] paths...) if (isSomeChar!C);
>
> http://dlang.org/phobos/std_path.html
>
> It would take me a lot of time to appeciate what that all means, although I can imagine what it is for.
>
> ...just and observation. The complexity is building.

With C++ I rarely have trouble finding a good explanation, it's just a really complex language that doesn't get easier when you use it. For D, the documentation is a work in progress, amplifying the learning curve for the things that make life easier for experienced programmers.

The official documentation is going to have to take a better approach when dealing with ranges and generic programming because the current approach doesn't work at all.

On Sun, Aug 30, 2015 at 07:36:53AM +0000, BBasile via Digitalmars-d-learn wrote:
> On Sunday, 30 August 2015 at 02:42:30 UTC, Spacen Jasset wrote:
> >immutable(ElementEncodingType!(ElementType!Range))[]
> >buildPath(Range)(Range segments) if (isInputRange!Range &&
> >isSomeString!(ElementType!Range));
> >pure nothrow @safe immutable(C)[] buildPath(C)(const(C)[][] paths...) if
> >(isSomeChar!C);
> 
> this is stodgy, particularly in a console with line wrapping at 80 chars.

https://issues.dlang.org/show_bug.cgi?id=13676


T

-- 
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth