www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why is phobos so wack?

reply FoxyBrown <Foxy Brown.IPT> writes:
import string.

...
return str.join(" ");


gives

Error: template std.array.join cannot deduce function from 
argument types !()(string, string), candidates are:
\..\..\src\phobos\std\array.d(1591):        std.array.join(RoR, 
R)(RoR ror, scope R sep) if (isInputRange!RoR && 
isInputRange!(Unqual!(ElementType!RoR)) && isInputRange!R && 
is(Unqual!(ElementType!(ElementType!RoR)) == 
Unqual!(ElementType!R)))
\..\..\src\phobos\std\array.d(1668):        std.array.join(RoR, 
E)(RoR ror, scope E sep) if (isInputRange!RoR && 
isInputRange!(Unqual!(ElementType!RoR)) && is(E : 
ElementType!(ElementType!RoR)))
\..\..\src\phobos\std\array.d(1754):        
std.array.join(RoR)(RoR ror) if (isInputRange!RoR && 
isInputRange!(Unqual!(ElementType!RoR)))

simply trying to join a string[] with a separator. I tend to get 
these types of errors when doing simple things in D. Virtually 
every other programming language just works as expected. You can 
pretty much just jump in there and pretty much guess at the 
function name, the arguments, and it will work. In Phobos, seems 
like it follows an anti-pattern. You always end up having to look 
at documentation unless you are familiar enough with D and use it 
in a regular basis to remember its quirks and odd behavior. Seems 
that the same functions are defined differently in different 
modules and the modules not always the expected ones. (strip is 
another one that throws me for a loop. I always try trim first... 
that is what everyone else uses, yeah, it's just a name, but then 
why strip?)

Phobos seems to be rather unorganized and not logically put 
together. Any hopes of this ever getting fixed or do I need to 
start putting together my own library?
Jul 09 2017
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
import std.array;
import std.stdio;

void main() {
	string[] strs = ["abc", "def"];
	writeln(strs.join(" "));	
}

Works fine?
Jul 09 2017
prev sibling next sibling parent Anonymouse <asdf asdf.net> writes:
On Sunday, 9 July 2017 at 12:56:55 UTC, FoxyBrown wrote:

 [...]


Your example is incomplete but this literally works for me.

import std.stdio;
import std.string;

void main()
{
     string[] words = [ "hello", "world", "!" ];
     writeln(words.join(" "));
}

You probably passed a string instead of a string[].


 Virtually every other programming language just works as 
 expected. You can pretty much just jump in there and pretty 
 much guess at the function name, the arguments, and it will 
 work.


In my experience this simply isn't true. Error messages could be 
worlds better but no language lets you use it for more than toy 
purposes without ever having to look at some form of 
documentation.
Jul 09 2017
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 9 July 2017 at 12:56:55 UTC, FoxyBrown wrote:

 return str.join(" ");
 [...]
 Error: template std.array.join cannot deduce function from 
 argument types !()(string, string)
 [...]
 simply trying to join a string[] with a separator.


The error message sucks, but you clearly have a string when you 
meant string[]. Even the one line of code you posted gives this 
away `str` is a singular name.


 modules not always the expected ones. (strip is another one 
 that throws me for a loop. I always try trim first... that is 
 what everyone else uses, yeah, it's just a name, but then why 
 strip?)


strip is used by Python and Ruby too... of the languages i know, 
it is about half a half.

BTW if you are ever searching, try my website: 
http://dpldocs.info/trim
Jul 09 2017
next sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
On Sunday, 9 July 2017 at 13:26:31 UTC, Adam D. Ruppe wrote:

 strip is used by Python and Ruby too... of the languages i 
 know, it is about half a half.

 BTW if you are ever searching, try my website: 
 http://dpldocs.info/trim


I find this part of D very annoying as well.

D looks like a C language, with a standard library written by a 
PHP/Python developer. It's a shame for a language with so much 
potential to fall victim to such bad taste =x

I suppose I'm biased, and PHP/Python have a fair following, but 
after a few years of PHP coding (part time as part of a larger 
project) I'm not sure I will ever make a full psychological 
recovery..
Jul 09 2017
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 9 July 2017 at 17:07:16 UTC, bitwise wrote:

 I suppose I'm biased, and PHP/Python have a fair following, but 
 after a few years of PHP coding (part time as part of a larger 
 project) I'm not sure I will ever make a full psychological 
 recovery..


PHP actually is one of the languages that call this `trim`....

But I've never had the kind of problems with D's names that I 
have with PHP's assorted weirdness.
Jul 09 2017
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 07/09/2017 06:12 PM, Adam D. Ruppe wrote:

 On Sunday, 9 July 2017 at 17:07:16 UTC, bitwise wrote:

 I suppose I'm biased, and PHP/Python have a fair following, but after 
 a few years of PHP coding (part time as part of a larger project) I'm 
 not sure I will ever make a full psychological recovery..


 
 PHP actually is one of the languages that call this `trim`....
 
 But I've never had the kind of problems with D's names that I have with 
 PHP's assorted weirdness.


It's nowhere remotely as bad as PHP (frankly, nothing else is), but D's 
growth over the years *has* left Phobos with a bit of a..."temporal 
inconsistancy" issue. Some things have been ironed out a bit (like how 
there was a module or two that used to use very unix CLI'ish naming 
conventions instead of D-ish namings), but there's still more to be 
done. And more will continue to be needed, with (ex.) allocators getting 
more and more finalized.
Jul 09 2017
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Sunday, 9 July 2017 at 13:26:31 UTC, Adam D. Ruppe wrote:

 The error message sucks, but you clearly have a string when you 
 meant string[].


To answer the part "why" about them sucking, is that they are 
generic.

Were join() just a regular function taking two strings, or two 
interfaces which string would implement, the messages would be 
better. I my experience D compiler is excellent at error messages 
when you don't go generic. Of course, that does not help much 
because the standard library is templated, not object-oriented.

Generics, and metaprogramming in general, is extremely hard to 
implement so that the error messages are even close to as good as 
elsewhere. No matter the language. Or rather, it can be made to 


to C++ and D.

About C++ from what I've heard, generic error messages there are 
not only much worse than others, they are much worse than even D 
template errors!
Jul 09 2017
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 9 July 2017 at 17:13:11 UTC, Dukc wrote:

 To answer the part "why" about them sucking, is that they are 
 generic.


Eh, that's not really why... this is just a crappy 
implementation. We can do a lot better with the library and a lot 
better with the compiler without losing any of the genericness.


 Were join() just a regular function taking two strings, or two 
 interfaces which string would implement, the messages would be 
 better.


Better yes, but still actually a bit crappy. I have one step of 
an improvement in the works: 
https://github.com/dlang/dmd/pull/6806

Consider something similar to that for the constraints too. It 
could highlight that you passed a string instead of a "range of 
ranges" and you'd have a pretty good idea at a glance, even with 
the generic templates.


 About C++ from what I've heard, generic error messages there 
 are not only much worse than others, they are much worse than 
 even D template errors!


Indeed.
Jul 09 2017
parent Dukc <ajieskola gmail.com> writes:
On Sunday, 9 July 2017 at 22:20:02 UTC, Adam D. Ruppe wrote:

 Eh, that's not really why... this is just a crappy 
 implementation. We can do a lot better with the library and a 
 lot better with the compiler without losing any of the 
 genericness.


But the more powerful the generics are, the harder it is to make 
good messages, that's what I'm saying. And that compared to the 
power of our metaprogramming, the messages aren't that bad after 
all.

But I agree D can, and I believe will, imporove there regardless.
Jul 10 2017
prev sibling parent Olivier FAURE <olivier.faure epitech.eu> writes:
On Sunday, 9 July 2017 at 17:13:11 UTC, Dukc wrote:

 About C++ from what I've heard, generic error messages there 
 are not only much worse than others, they are much worse than 
 even D template errors!


Yeah. You don't want to try reading the GCC message for a 
std::cout error. It's like 80 lines of different template 
overloads of the '<<' operator.
Jul 10 2017
prev sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Sunday, 9 July 2017 at 12:56:55 UTC, FoxyBrown wrote:

 import string.

 ...
 return str.join(" ");


 gives

 Error: template std.array.join cannot deduce function from 
 argument types !()(string, string)


Well there's your mistake? There is no function `join` that takes 
(string, string). Everything after that is more detail that may 
or may not be useful, but reading the error message carefully, in 
order, is generally good enough. That said, it would be nice if 
the errors were less daunting somehow.
Jul 09 2017
parent Martin Nowak <code dawg.eu> writes:
On Sunday, 9 July 2017 at 14:22:45 UTC, John Colvin wrote:

 That said, it would be nice if the errors were less daunting 
 somehow.


Better template constraint errors are on our Agenda for later 
this year.
https://wiki.dlang.org/Vision/2017H2_draft
Jul 10 2017