Should this work?

[H. S. Teoh]

On Thu, Jan 09, 2014 at 06:25:33PM +0000, Brad Anderson wrote:
> On Thursday, 9 January 2014 at 14:08:02 UTC, Manu wrote:
[...]
> >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.

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.

Alternatively, maybe sig constraints can have an additional string
parameter that specifies a message that explains why that particular
overload was rejected. These messages are not displayed if at least one
overload matches; only if no overload matches, they will be displayed
(so that the user can at least see why each of the overloads didn't
match).


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

Really?? I find myself much more productive, because I only have to
learn one set of generic algorithms, and I can use them not just for
strings but for all sorts of other stuff that implement the range API.
Whereas in languages like C, sure you get familiar with string-specific
functions, but then when you need a similar-operating function for an
array of ints, you have to name it something else, and then basically
the same algorithm reimplemented for linked lists, called by yet another
name, etc.. Added together, it's many times more mental load than just
learning a single set of generic algorithms that work on (almost)
everything.

The composability of generic algorithms also allow me to think on a more
abstract level -- instead of thinking about manipulating individual
chars, I can figure out OK, if I split the string by "," then I can
filter for the strings I'm looking for, then join them back again with
another delimiter. Since the same set of algorithms work with other
ranges too, I can apply exactly the same thought process for working
with arrays, linked lists, and other containers, without having to
remember 5 different names of essentially the same algorithm but applied
to 5 different types.


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

I found that what I got out of taking the time to learn std.algorithm
and std.range was worth far more than the effort invested.


T

-- 
Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world. -- Carl B. Constantine