bearophile wrote:
Steven Schveighoffer:
Thank you for this post, that gives me a chance to talk about this topic.
What I meant was, opEquals could forward to opBinary, but if it's disallowed by
the compiler, then that's not possible.<
I just think it's overkill to restrict what functions are
On Tue, 16 Mar 2010 14:03:37 -0400, bearophile
wrote:
Steven Schveighoffer:
Thank you for this post, that gives me a chance to talk about this topic.
What I meant was, opEquals could forward to opBinary, but if it's
disallowed by the compiler, then that's not possible.<
I just think it's
Steven Schveighoffer:
Thank you for this post, that gives me a chance to talk about this topic.
>What I meant was, opEquals could forward to opBinary, but if it's disallowed
>by the compiler, then that's not possible.<
>I just think it's overkill to restrict what functions are valid arbitrarily.
On Mon, 15 Mar 2010 16:59:53 -0400, Trass3r wrote:
I can see one potential reason to use opBinary("==") and that is to
collect binary operator code in one place.
Currently dmd checks that and turns == into opEquals, should never
become opBinary!("==")
What I meant was, opEquals could for
On Mon, Mar 15, 2010 at 16:12, Steven Schveighoffer wrote:
(On alias this)
> Yeah, I tried to get it to work too, but it doesn't. Even something like
> this doesn't work:
>
> struct Foo {
> uint x;
> uint castToUint() { return x; }
> alias castToUint this;
> }
>
> This should work. The te
I can see one potential reason to use opBinary("==") and that is to
collect binary operator code in one place.
Currently dmd checks that and turns == into opEquals, should never become
opBinary!("==")
On Mon, 15 Mar 2010 10:46:01 -0400, bearophile
wrote:
Steven Schveighoffer:
I think there is no restriction on what opEquals in structs.<
I think this is a hole in the specification that needs to be filled,
because I think you must be sure opEquals returns a bool.
Oh, I thought you me
Steven Schveighoffer:
>I think there is no restriction on what opEquals in structs.<
I think this is a hole in the specification that needs to be filled, because I
think you must be sure opEquals returns a bool.
>These kinds of errors are appropriate for a lint tool.<
Have you seen any good l
But that can cause bugs: it's easy for programmers to forget to use
opEquals instead of opBinary("==").
Again, opBinary and opEquals are simply functions. There is nothing
special about their existence, just about how the compiler rewrites the
operators into calling those functions. The f
On Sun, 14 Mar 2010 10:55:41 -0400, bearophile
wrote:
In the following little programs can you help me tell apart my errors
from bugs in dmd?
I'll preface my comments with a general comment.
operator functions themselves are not, and should not be, treated
specially by the compiler. Yo
In the following little programs can you help me tell apart my errors from bugs
in dmd?
(This post shows only part of the problems I have found with operator
overloading).
---
1) Error in the documentation in this page:
http://www.digitalmars.com/d/2.0/operatoroverl
11 matches
Mail list logo
