www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Static opCast

reply Andy Friesen <andy ikagames.com> writes:
Arcane Jill (correct me if my memory decieves me) once pointed out that 
static operator overloads were legal, but I hadn't considered opCast 
until just now.

This works:

     import std.stdio;

     class A {
         static int opCast() {
             return 42;
         }
     }

     void main() {
         writefln(cast(int)A);
     }

I have no idea why anyone would ever want to do this, but it's there 
anyway.  I assume this is a consequence of the way overloads are handled.

I suppose this could be added to DStress, but whether or not it is 
supposed to work is unclear. :)

  -- andy
Jan 10 2005
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
I would opine that this should be made illegal for now, until we find 
some good use for it.  That's better than later finding out that there 
is some good use for it, but that we can't change it because of legacy 
code and/or compilers.

This would probably be true for many of the operators - what does a 
static opAddAssign mean?

Unless you're building a singleton, of course...hmmm...

Russ

Andy Friesen wrote:
 Arcane Jill (correct me if my memory decieves me) once pointed out that 
 static operator overloads were legal, but I hadn't considered opCast 
 until just now.
 
 This works:
 
     import std.stdio;
 
     class A {
         static int opCast() {
             return 42;
         }
     }
 
     void main() {
         writefln(cast(int)A);
     }
 
 I have no idea why anyone would ever want to do this, but it's there 
 anyway.  I assume this is a consequence of the way overloads are handled.
 
 I suppose this could be added to DStress, but whether or not it is 
 supposed to work is unclear. :)
 
  -- andy

Jan 10 2005
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <cruhcc$1o6c$1 digitaldaemon.com>, Russ Lewis says...
I would opine that this should be made illegal for now, until we find 
some good use for it.  That's better than later finding out that there 
is some good use for it, but that we can't change it because of legacy 
code and/or compilers.

This would probably be true for many of the operators - what does a 
static opAddAssign mean?

Unless you're building a singleton, of course...hmmm...

I, for one, would advocate that the exact opposite course be taken. It should be kept until there's a strong reason to strike it from the language. The concept described is conscise and unambiguous. Unless it conflicts with other aspects of the language's grammar (ie. makes it impossible to parse), it presents no linguistic problem. It can be easliy documented and defined for new and experienced programmers to understand, so it presents no semantic problems. Although, like yousrself, I cannot find a reason why to keep it. But that's not reason enough, as someone could come along later and use it to good effect. - Pragma (ericanderton at yahoo)
Jan 10 2005
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
pragma wrote:
 In article <cruhcc$1o6c$1 digitaldaemon.com>, Russ Lewis says...
 
I would opine that this should be made illegal for now, until we find 
some good use for it.  That's better than later finding out that there 
is some good use for it, but that we can't change it because of legacy 
code and/or compilers.

This would probably be true for many of the operators - what does a 
static opAddAssign mean?

Unless you're building a singleton, of course...hmmm...

I, for one, would advocate that the exact opposite course be taken. It should be kept until there's a strong reason to strike it from the language. The concept described is conscise and unambiguous. Unless it conflicts with other aspects of the language's grammar (ie. makes it impossible to parse), it presents no linguistic problem. It can be easliy documented and defined for new and experienced programmers to understand, so it presents no semantic problems. Although, like yousrself, I cannot find a reason why to keep it. But that's not reason enough, as someone could come along later and use it to good effect. - Pragma (ericanderton at yahoo)

I would generally agree with your principle. But casting a class seems, to my gut, as something that might mean some sort of really weird but really cool thing. I just can't figure out what it is right now. :) What I'm afraid of is that we will later figure out what that thing is, and decide that it needs to be a special case. It may be that the compiler will work some sort of magic, and static opCast() would not be allowed. But we won't be able to change it, because there will be legacy programs and compilers which support our old, lax design. opCast() is not like opAdd(), where operator overloading saves a lot of typing: cast(int)A vs A.castToInt() So we're not doing major disservice to people by disallowing it. They can work around it easily enough. Anyway, this is just my gut. My gut may well be wrong. I certainly won't gripe if we continue to allow static opCast(). As you have pointed out, it's generally a good idea not to disallow something unless you have a really good reason.
Jan 10 2005
prev sibling parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Russ Lewis wrote:

 I would opine that this should be made illegal for now, until we find
 some good use for it.  That's better than later finding out that there
 is some good use for it, but that we can't change it because of legacy
 code and/or compilers.

Strange reasoning! If there ever exists any legacy code that would collide with changing the current behaviour, that is the clearest signal that the "feature" is not completely useless. And as for compilers: I would guess that forbidding static opCast will only complicate the compiler artificially in the same way it would complicate the documentation. Currently, there is nothing that needs to be documented. Unless stated otherwise, every feature of a class can be declared static. Disallowing static opCast would only add a special case.
Jan 10 2005
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Norbert Nemec wrote:
 Russ Lewis wrote:
 
 
I would opine that this should be made illegal for now, until we find
some good use for it.  That's better than later finding out that there
is some good use for it, but that we can't change it because of legacy
code and/or compilers.

Strange reasoning! If there ever exists any legacy code that would collide with changing the current behaviour, that is the clearest signal that the "feature" is not completely useless. And as for compilers: I would guess that forbidding static opCast will only complicate the compiler artificially in the same way it would complicate the documentation.

(grin) This sounds exactly like the sort of reasoning I would normally use. I normally find it pretty compelling. Perhaps this discomfort with static opCast() is just something I ate? ;) This time, my thought process was that just because there is legacy code which uses it, that doesn't necessarily mean that there is any *good* reason to use it. (Or maybe there was a good reason, but it is not terribly compelling.) Users tend to trickle into the cracks and use obscure features even when there's no really good reason to do so. :)
 Currently, there is nothing that needs to be documented. Unless stated
 otherwise, every feature of a class can be declared static. Disallowing
 static opCast would only add a special case.

True.
Jan 10 2005