On 2014-01-10 01:34, Manu wrote:

> I have to wonder the same thing.
> It's just not anything like anything I've ever called it before I guess.
> I guess I started with find, and then it refers you to retro if you want
> to reverse find, and of course, by this time I'm nowhere near std.string
> anymore. Hard to find something if you're not even looking in the same
> file :/

But "strchr" is a good name? If I wanted the index of a character in a string I would most likely look for something called "indexOf", or "index". In Java and C# it's called "indexOf", in Ruby it's called "index". In Python it's called "index" (and "find"). In PHP it's called "strrpos" and in C++ it's called "find". I think we're in pretty good shape here with D.

-- 
/Jacob Carlborg

On 2014-01-10 02:18, Adam D. Ruppe wrote:
> BTW, I'll say it again: it was a *lot* easier to get started with this
> back in the phobos1 days, where std.string WAS the one-stop location for
> string stuff.

There was std.uni back in the D1 days as well ;)

-- 
/Jacob Carlborg

On 2014-01-10 02:34, 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.

I think it would be good to still have a few alias, like toString and toInt.

> * before: some char type stuff was in std.string (and the rest in
> std.ctype IIRC). Now, it is in std.ascii and std.uni.

std.uni was available in D1 as well.

-- 
/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?

-- 
/Jacob Carlborg

On 2014-01-10 03:40, Jesse Phillips wrote:

> Trying to look over the API pages for C# or Java to find what you need
> isn't fun. But it can be a little better if you know which class you need.

It's easier in a more object oriented language. It's most likely that you will find string operations in the String class in Java, C# and Ruby.

-- 
/Jacob Carlborg

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.

Andrei

On Friday, 10 January 2014 at 08:15:19 UTC, Jacob Carlborg wrote:
> What's the hold up of making the official documentation use DDox?

I’m also interested in this, since the current documentation is not beginner-friendly due to missing overview and this hurts D.

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.

-- 
Dmitry Olshansky

On 2014-01-10 02:13, H. S. Teoh wrote:

> The hand-classified table of functions in std.algorithm and std.range is
> more useful, IMO. At least it lets you use divide-and-conquer to zoom
> down to your area of interest, whereas the order of links in the blob of
> links has no relation whatsoever to the functionality provided.

I'm convinced the both of the tables on in the std.algorithm documentation can automatically be generated with a bit help from the compiler. Add a macro, $(CATEGORY), the compiler knows about. The compiler will the generate the first table by using the symbol (which it already knows about) and the $(CATEGORY) macro. The second table can be generated in a similar way, just take the summary (first paragraph) of the documentation of the symbol.

> The order of docs for each symbol also follows the order in the source
> code, which may not necessarily follow a logical order. This makes
> browsing the docs difficult -- one minute it's describing find()
> overloads, next minute it's talking about set unions, then after that
> it's back to findAfter(), then it jumps to remove(), etc.. Try finding
> what you want when the docs are 50 pages of this random jumping around.
> All the more this makes a hand-classified table of symbols
> indispensable.

I would say that is poorly organized code. Although, if you do have a $(CATEGORY) macro, as described above, it might be a good idea to group the rest of the documentation after this as well.

-- 
/Jacob Carlborg

On 2014-01-09 21:27, H. S. Teoh wrote:

> Yeah, that error drives me up the wall too. I often get screenfuls of
> errors, dumping 25 or so overloads of some obscure Phobos internal
> function (like toImpl) as though an end-user would understand any of it.
> You have to parse all the sig constraints (and boy some of them are
> obscure), *understand* what they mean (which requires understanding how
> Phobos works internally), and *then* try to figure out, by elimination,
> which is the one that you intended to match, and why your code failed to
> match it.
>
> I'm almost tempted to say that using sig constraints to differentiate
> between template overloads is a bad idea. Instead, consider this
> alternative implementation of toImpl:
>
> 	template toImpl(S,T)
> 		// N.B.: no sig constraints here
> 	{
> 		static if (... /* sig constraint conditions for overload #1 */)
> 		{
> 			S toImpl(T t)
> 			{
> 				// implementation here
> 			}
> 		}
> 		else static if (... /* sig constraint conditions for overload #2 */)
> 		{
> 			S toImpl(T t)
> 			{
> 				// implementation here
> 			}
> 		}
> 		...
> 		else // N.B.: user-readable error message
> 		{
> 			static assert(0, "Unable to convert " ~
> 				T.stringof ~ " to " ~ S.stringof);
> 		}
> 	}
>
> By putting all overloads inside a single template, we can give a useful
> default message when no overloads match.

If I recall correctly, Andrei has mentioned that something like the above doesn't works so well with __tratis(compile).

-- 
/Jacob Carlborg