On 1/9/14 11:53 PM, Jacob Carlborg wrote:
> Even if you do get how ranges work it can be difficult to figure out
> where a function is located, in std.algorithms, std.string, std.array,
> std.uni or std.range. Like, "is this a string operation or a general
> container algorithm?". Why is there a std.string.indexOf function? Isn't
> that a general array operation or algorithm? Isn't
> std.string.(left|right)Justify a general operation as well?

That's a documentation issue. We've pursued generalization of string algorithms with good result. As such indexOf is susceptible for generalization. However, the justification functions are unlikely to be useful for other data types because most don't have a notion of "filler" object.

Andrei

On 1/10/14 12:17 AM, Dmitry Olshansky wrote:
> 10-Jan-2014 12:15, Jacob Carlborg пишет:
>> On 2014-01-10 03:40, Brad Anderson wrote:
>>
>>> DDox improves on this a bit by giving a table with brief
>>> descriptions right up top:
>>> http://vibed.org/temp/dlang.org/library/std/string.html
>>
>> What's the hold up of making the official documentation use DDox?
>>
>
> Seconded.

Let's set to switch to ddox with 2.065.

Andrei

On 2014-01-10 02:06, Manu wrote:

> Then there's probably a fundamental problem somewhere, and it should be
> re-thought at a lower level.
> Perhaps even something super simple like a can't-go-wrong naming
> convention, that makes it REALLY plain when string related function are
> dealing with bytes, codepoints, or graphemes?

Isn't it with convention that every thing _can_ go wrong.

> It would seem to be that a lot of the confusion and complexity
> surrounding strings is because it tries to be 'correct' (and varying
> levels of correct in different circumstances), but there are no clear
> relationships between different functions that deal with these different
> versions of 'correct'-ness.

I think the confusion comes from strings are just plain arrays, which are also containers. If there's a function that works on containers it will work on arrays and strings as well. Because of that it's put in a general module for containers, in this case std.algorithm. Functions that work on arrays will also work on strings and they're put in the most general location they fit, std.array. Functions that work only work on strings are put in std.string. The we of course have some other modules, like std.uni and std.utf making it a bit more complicated.

> I suspect your effort is not uncommon. Is this not clear evidence of a
> critical problem?

Probably. I find that to be a problem in most standard libraries. They have very general functionality but very few convenient functions, that require calling two or three functions and perhaps creating an object.

-- 
/Jacob Carlborg

On Friday, 10 January 2014 at 08:31:28 UTC, Andrei Alexandrescu wrote:
> On 1/10/14 12:17 AM, Dmitry Olshansky wrote:
>> 10-Jan-2014 12:15, Jacob Carlborg пишет:
>>> On 2014-01-10 03:40, Brad Anderson wrote:
>>>
>>>> DDox improves on this a bit by giving a table with brief
>>>> descriptions right up top:
>>>> http://vibed.org/temp/dlang.org/library/std/string.html
>>>
>>> What's the hold up of making the official documentation use DDox?
>>>
>>
>> Seconded.
>
> Let's set to switch to ddox with 2.065.
>
> Andrei

Let's not put to much stress on release/deployment process (which changing documentation engine will require) and make at least one "simple" release just to get everyone familiar with it.

On 2014-01-10 07:18, Manu wrote:

> Surely it can't be *ptr and ++ptr as you say, otherwise none of it would
> be unicode safe...?

For UTF-8 strings it's an extra if-statement:

immutable c = str[0];
if(c < 0x80)
{
    //ptr is used to avoid unnnecessary bounds checking.
    str = str.ptr[1 .. str.length];
}

-- 
/Jacob Carlborg

On 2014-01-10 09:29, Andrei Alexandrescu wrote:

> That's a documentation issue. We've pursued generalization of string
> algorithms with good result. As such indexOf is susceptible for
> generalization. However, the justification functions are unlikely to be
> useful for other data types because most don't have a notion of "filler"
> object.

They might not have a default "filler" object but you can pass the "filler" as an argument.

-- 
/Jacob Carlborg

On 2014-01-10 09:16, Andrei Alexandrescu wrote:

> I wouldn't want to get to the point where many functions have 2-3 names.

They're aliased in from std.uni, I think that's a different thing. It's not like Ruby which has both "collect" and "map", in the same place, meaning the same thing.

-- 
/Jacob Carlborg

On Thu, 09 Jan 2014 17:25:13 -0000, Manu <turkeyman@gmail.com> wrote:

> 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.

We need, if one does not exist already, a dependency mapper tool.  One which would give some sort of graphical/hierarchical output of modules and their dependencies, ideally drilling right down to the functions, methods, variables etc being used.

Sounds fun, and there is a DMD frontend to build on right?  Anyone got the spare time?

Regan

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Fri, 10 Jan 2014 08:16:53 -0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/9/14 11:56 PM, Jacob Carlborg wrote:
>> On 2014-01-10 02:34, Manu wrote:
>>
>>> Or just alias the functions useful for string processing...
>>
>> I agree. It already has some aliases, converting to lower and uppercase.
>
> I wouldn't want to get to the point where many functions have 2-3 names.

This is only a problem if they are all in the same sphere of concern.. by that I mean if you're looking for string functions and you find 2 names for the same function this would be wrong/confusing/pointless.  But, if you have one name in the string category and one in the range category and they were both the same function underneath I don't see this as the "same" problem, right?

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Friday, 10 January 2014 at 05:28:24 UTC, Andrei Alexandrescu wrote:
> On 1/9/14 6:00 PM, H. S. Teoh wrote:
>> On Fri, Jan 10, 2014 at 01:34:46AM +0000, Adam D. Ruppe wrote:
>> [...]
>>> Some code differences from the old days:
>>>
>>> * before: converting to and from string was in std.string. Functions
>>> like toInt, toString, etc. Nowadays, this is all done with
>>> std.conv.to. The new way is way cool, but a newbie's first place to
>>> look might be for std.string.toString rather than std.conv.to!string.
>>
>> Right, so it should be mentioned in std.string.
>>
>> But probably your idea of more concept-oriented overview pages is
>> better. It doesn't seem like the right solution to just insert
>> hyperlinks to std.conv in every other Phobos module.
>
> A tutorial on string manipulation in D would be awesome.
>
> Andrei

That would be a very useful asset.