Proposal: prettify template constraints failure messages
Jonathan M Davis
jmdavisProg at gmx.com
Wed Jan 2 14:26:10 PST 2013
On Wednesday, January 02, 2013 23:02:12 monarch_dodra wrote:
> That said, I think another field of improvement we should
> concentrate in phobos is to have a single public entry point, and
> then privately forward to private specialized overloads.
>
> Users really shouldn't have to deal with functions whose
> restraints are things such as "input range, but not random
> access", or "random access with length, but not sliceable" or
> some of our other *6* liners. It gets especially bad when the
> compiler lists all 7 of our (implementation defined) overloads.
> Nobody needs to see that.
>
> As a end user, I'd really want to see a single function with
> "isForwardRange!R". Period. The fact that the implementation
> differs depending on all that *crap* really isn't my problem and
> shouldn't show up in my interface >:(
I think that this is sensible. I think that I haven't been doing it primarily
because of how some of the functions are laid out in the source file
(particularly with regards to the unit tests). Some of them will still need to
be separate though for documentation purposes (or need version(StdDdoc) blocks
which provide documentation if they're merged into a single function or
template). find would be a prime example of this.
There's also the question of how to combine funcitons. There are 3 ways that I
can think of off the top of my head:
1. Put them in a single function with many static ifs (not terribly clean if
the functions were big enough that you split them apart in the first place).
2. Use a public function which calls a private impl function, which
potentially creates unnecessary overhead (especially without -inline) but
allows you to keep the separate functions more or less as they are now
internally.
3. Use a template with the simplified template constraint on it with inner
templated functions for each of the overloads.
I've generally though of doing #3 (as I think that we've done that in some
cases already), but it forces you to place the unit tests farther from the
functions, which I don't like. You seem to be suggesting #2, and that would
probably be a better approach because of that, though it does bug me to create
a useless outer function just for a template constraint.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list