January 09, 2014
On Thu, 09 Jan 2014 17:15:41 -0000, Regan Heath <regan@netmail.co.nz> wrote:

> In other words, why can't we alias or wrap the generic routines in std.string

What I meant here is why can't we alias or wrap the generic routines (from std.range, std.algo.. into aliases/functions) in std.string.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
January 09, 2014
On 10 January 2014 02:36, Dicebot <public@dicebot.lv> wrote:

> On Thursday, 9 January 2014 at 16:22:08 UTC, Manu wrote:
>
>> It's nice that it's unicode correct, but it's not nice that you have to be familiar with a massive amount of the standard library and you need to search through 4-5 (huge! and often poorly documented) modules to find the functions you need to perform _basic string operations_, like finding the last instance of a character...
>>
>
> That I do agree. One idea is that once everything is split into smaller packages we can start providing meta-packages that do public imports of small sets of commonly used functions.
>
> Still once needed functions are found I do consider end result very robust for what it actually does and don't know any other language that does it better.
>
>
>  My standing opinion is that string manipulation in D is not nice, it is
>> possibly the most difficult and time consuming I have used in any language ever. Am I alone?
>>
>
> Unicode is the doom. If you only keep ASCII in mind you statement is indeed true and D stuff seems ridiculously complicated compared even to plain C. But it has also teached me that _every single_ program I have written before in other languages was broken in regards to Unicode handling. So, yes, it is quite difficult but it is the cost for doing what no one else does - being correct out of the box. Well, at least in most scenarios :)
>

That's great and all, but it's no good if I have to pay for it (time and
money!) even when that's not a requirement. I'm dealing with ascii right
now.
At very least, there needs to be massive assistance. std.string should
probably offer a crap load of aliases and wrappers for common operations.
And I hate how std.algorithm looks in intellisense pop ups, you never have
any idea what types you're dealing with, everything is templates, many
levels deep.
And then it's riddled with these little wrappers around 'Impl' types, which
just adds more layers to the typing confusion.
I want string functions that deal with types like 'string', not
'Unqual!(ElementEncodingType!(ElementType!Range))[]'


January 09, 2014
On Thursday, 9 January 2014 at 17:21:11 UTC, Manu wrote:
> money!) even when that's not a requirement. I'm dealing with ascii right
> now.

Then first (and mandatory) thing to do is stop using `string` type and switch to `ubyte[]` (or wrapper from std.ascii)

Second thing to do then will be to complain about lack of `ubyte[]` specializations/overloads for most string processing functions ;)
January 09, 2014
On 10 January 2014 03:17, Regan Heath <regan@netmail.co.nz> wrote:

> On Thu, 09 Jan 2014 17:15:41 -0000, Regan Heath <regan@netmail.co.nz> wrote:
>
>  In other words, why can't we alias or wrap the generic routines in
>> std.string
>>
>
> What I meant here is why can't we alias or wrap the generic routines (from std.range, std.algo.. into aliases/functions) in std.string.


We can and should. Very liberally.
I'm still very concerned about the magnitude of bloat that gets pulled in
by any of these modules though. They're all intimately connected, none of
them seem to be able to exist without all of the others.
And there are some really huge template functions out there. Massive
functions, which take multiple template arguments (N^2 permutations), where
the template types might only affects one or 2 lines... they need to be
broken down into very small template functions, and a non-templated inner
function.


January 09, 2014
On Thursday, 9 January 2014 at 14:08:02 UTC, Manu wrote:
>   string y = find(retro("Hello"), 'H');

import std.string;
auto idx = lastIndexOf("Hello", 'H');

Wow, that's unbelievable difficult. D sucks.
January 09, 2014
On Thursday, 9 January 2014 at 17:39:00 UTC, Adam D. Ruppe wrote:
> On Thursday, 9 January 2014 at 14:08:02 UTC, Manu wrote:
>>  string y = find(retro("Hello"), 'H');
>
> import std.string;
> auto idx = lastIndexOf("Hello", 'H');
>
> Wow, that's unbelievable difficult. D sucks.

How on earth did I miss that...
January 09, 2014
09-Jan-2014 21:38, Adam D. Ruppe пишет:
> On Thursday, 9 January 2014 at 14:08:02 UTC, Manu wrote:
>>   string y = find(retro("Hello"), 'H');
>
> import std.string;
> auto idx = lastIndexOf("Hello", 'H');
>
> Wow, that's unbelievable difficult. D sucks.

+1 LOL

-- 
Dmitry Olshansky
January 09, 2014
On Thursday, 9 January 2014 at 17:39:00 UTC, Adam D. Ruppe wrote:
> On Thursday, 9 January 2014 at 14:08:02 UTC, Manu wrote:
>>  string y = find(retro("Hello"), 'H');
>
> import std.string;
> auto idx = lastIndexOf("Hello", 'H');
>
> Wow, that's unbelievable difficult. D sucks.

It is not the same thing as sample with byGrapheme though.
January 09, 2014
On Thursday, 9 January 2014 at 17:54:05 UTC, Dicebot wrote:
> It is not the same thing as sample with byGrapheme though.

Right, but it works for ascii (and others) and shows std.string isn't as weak as being said in this thread.
January 09, 2014
On Thursday, 9 January 2014 at 14:08:02 UTC, Manu wrote:
> This works fine:
>   string x = find("Hello", 'H');
>
> This doesn't:
>   string y = find(retro("Hello"), 'H');
>   > Error: cannot implicitly convert expression (find(retro("Hello"), 'H'))
> of type Result!() to string
>
> Is that wrong? That seems to be how the docs suggest it should be used.
>
> On a side note, am I the only one that finds std.algorithm/std.range/etc
> for string processing really obtuse?
> I can rarely understand the error messages, so say it's better than STL is
> optimistic.

I absolutely hate the "does not match any template declaration" error. It's extremely unhelpful for figuring out what you need to do and anytime I try to do something fun with ranges I can expect to see it a dozen times.

> Using std.algorithm and std.range to do string manipulation feels really
> lame to me.
> I hate looking through the docs of 3-4 modules to understand the complete
> set of useful string operations (std.string, std.uni, std.algorithm,
> std.range... at least).

I've finally started to get the hang of what stuff is in what module but it's taken me a couple years.  Things like File being in std.stdio instead of the more intuitive std.file are confusing enough but with strings you end up having to look in std.string, std.array, std.algorithm, std.range, std.format, and std.uni (and there are probably more than that).

> I also find the names of the generic algorithms are often unrelated to the
> name of the string operation.
> My feeling is, everyone is always on about how cool D is at string, but
> other than 'char[]', and the builtin slice operator, I feel really
> unproductive whenever I do any heavy string manipulation in D.

I actually feel a lot more productive in D than in C++ with strings. Boost's string algorithms library helps fill the gap (and at least you only have one place to look for documentation when you are using it) but overall I prefer my experience working in D with pseudo-member chains.