[phobos] datetime review

[Jonathan M Davis]

On Sunday 10 October 2010 06:43:59 Andrei Alexandrescu wrote:
> > One issue that would arise from this is one which I'm beginning to think
> > we need to address in the language somehow, and that is template
> > constraint failures. When a template constraint fails, all the compiler
> > tells you is that no version of the template matches the arguments that
> > you're trying to instantiate with. That's highly uninformative. Ideally,
> > it would tell you which portion of the constraint failed. For instance,
> > by using strings instead of TUnit, you have the issue of getting the
> > string exactly right. If the string had to be "year", and someone used
> > "years" or "Year", then the template constraint would fail, and they
> > would have no idea why. At least with the enum, the compiler will
> > complain about the parameter that you're giving the template (though it
> > complains that the mistyped value is not a property of int (e.g. that
> > years is not a property of int if you used TUnit.years instead of
> > TUnit.year), which isn't a very good message either - it's just that
> > it's specific enough that it's easy to figure out). Using a string will
> > result in worse error messages.
> 
> In fact that's not an issue. Template constraints were meant to avoid a
> template biting off more than it can chew. In this case, however, you
> want to cover the total set, so you can simply write:
> 
> long convert(string from, string to)(long) {
>      static if (from == "seconds" && to == "minutes") {
>      } else static if (...) {
>      ...
>      } else {
>          static assert("Invalid duration specifiers. ...");
>      }
> }

Except, what if a template constraint has half a dozen conditions in it? In such 
cases, it's not at all clear which condition was false. And while you can 
combine conditions into eponymous templates or functions or whatnot so that 
there are fewer conditions listed in the template constraint, that just buries 
them as far as tracking down what failed goes. It can be very irritating to have 
to mess around with a template constraint until you figure out which condition is 
failing. And if the templated function or type is in a library as opposed to 
your own code, it's that much harder because you can't comment out portions of 
the condition to see what happens. convert() may not be too bad, but it's not 
hard at all to create template constraints which need to be true but which are 
complicated enough that it's a pain to figure out what's wrong when they fail.

- Jonathan M Davis