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

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

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)

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.

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.

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.