Overloading opEquals(T)(T y)

[spir]

On 02/08/2011 05:17 PM, Steven Schveighoffer wrote:
> On Tue, 08 Feb 2011 10:52:35 -0500, spir <denis.spir at 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