On 02/08/2011 05:17 PM, Steven Schveighoffer wrote:
On Tue, 08 Feb 2011 10:52:35 -0500, spir <denis.s...@gmail.com> wrote:
On 02/08/2011 12:16 AM, bearophile wrote:
Charles McAnany:
Hi, all. So I'm trying to make a BigRational struct, to get more comfortable
with D.
I just thought at this alternative between a constraint and a static if a few
hours ago. In which case, and according to which reasoning, would one choose
one or the other? (I chose static if only for the very bad reason I can
hardly stand is().)
The point of constraints are to intercept the compilation earlier. For the
discussed example, it's not as important. Let's try a smaller example.
What is the difference between:
bool opEquals(T)(T y) if (is(T == BigRational)) {...}
and
bool opEquals(T)(T y)
{
static if(is(T == BigRational)) {...}
else static assert(0, "invalid type");
}
Thank you very much, Steven.
I'd say: in the first case, there are as many functions as constraints variants
(provided other variants are implemented, indeed) triggered by actual calls to
opEquals.
Tell me if i'm right on this: In the second case, there is a single function
generated, and branches of static if are inserted according to actual calls. Is
that right? If yes then I don't really care of this use of static f (I'm aware
there are other, maybe more relevant, use cases).
With an example like myBigRational == 5?
The difference is, with the first, the compiler simply skips compiling that
function due to the constraint. With the second, the compiler still tries to
compile the opEquals. The difference is really in the error the compiler
generates. With the first, the error is "no function found", the second is
"function doesn't compile". This is all pretty much equivalent, until you want
to overload the template. Perhaps you want to overload it in different modules.
With the second method, this is impossible, all overloads must be in the single
definition. This also makes it somewhat less readable.
Plus, with the second, its really easy to forget that "else static assert",
meaning the function will compile, and simply do nothing (actually, it won't
compile because it doesn't return a value, but still, that error message is
going to be way more confusing than "no function found").
Right.
I'd say a rule of thumb is, if the entire function is going to be different
based on the types, you should use a constraint. If there is one small
difference in the function, then using the static if might be a better
approach, but you still might want to use the constraints to restrict to what
you expect.
Right again, makes full sense now.
Denis
--
_________________
vita es estrany
spir.wikidot.com
