View mode: basic / threaded / horizontal-split · Log in · Help
January 10, 2005
Static opCast
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
January 10, 2005
Re: Static opCast
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
January 10, 2005
Re: Static opCast
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)
January 10, 2005
Re: Static opCast
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.
January 10, 2005
Re: Static opCast
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.
January 10, 2005
Re: Static opCast
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.
Top | Discussion index | About this forum | D home