Thread overview | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
September 17, 2006 Why are opCall's not implicitely assignable? | ||||
---|---|---|---|---|
| ||||
class C{ int opCall(int i){ return 2*i; } } int main(){ auto c= new C; int x=c.opCall=3; // compiles int x=c=3; // does not compile } |
September 17, 2006 Re: Why are opCall's not implicitely assignable? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Karen Lanrap | "Karen Lanrap" <karen@digitaldaemon.com> wrote in message news:Xns98428255B9E6digitaldaemoncom@63.105.9.61... > class C{ > int opCall(int i){ > return 2*i; > } > } > > int main(){ > auto c= new C; > int x=c.opCall=3; // compiles > int x=c=3; // does not compile > } Long story short, the compiler sees "c = 3" first as an assignment, and since assignment can't be overloaded, it complains. |
September 20, 2006 Re: Why are opCall's not implicitely assignable? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Karen Lanrap | Karen Lanrap wrote: > class C{ > int opCall(int i){ > return 2*i; > } > } > > int main(){ > auto c= new C; > int x=c.opCall=3; // compiles > int x=c=3; // does not compile > } Because the expression form has nothing to do with opCall whatsoever. The purpose of opCall is specifically to overload the (...) form to make the class act like a function. There's no reason that the property syntactic sugar should apply to an object of the class being used as a function. If it did, then how would you assign object references of classes that have opCall at all? Similarly, void function(int) qwert; ... qwert(yuiop); // calling the pointed-to function qwert = asfdg; // changing which function is pointed to Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit. |
September 20, 2006 Re: Why are opCall's not implicitely assignable? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon |
Stewart Gordon wrote:
> Karen Lanrap wrote:
>> class C{
>> int opCall(int i){
>> return 2*i;
>> }
>> }
>>
>> int main(){
>> auto c= new C;
>> int x=c.opCall=3; // compiles
>> int x=c=3; // does not compile
>> }
>
> Because the expression form has nothing to do with opCall whatsoever.
>
> The purpose of opCall is specifically to overload the (...) form to make the class act like a function. There's no reason that the property syntactic sugar should apply to an object of the class being used as a function. If it did, then how would you assign object references of classes that have opCall at all?
>
> Similarly,
>
> void function(int) qwert;
> ...
> qwert(yuiop); // calling the pointed-to function
> qwert = asfdg; // changing which function is pointed to
>
> Stewart.
>
Something bugs me here .. there's some level of inconsistency with all the stuff related to property syntax sugar.
|
September 21, 2006 Re: Why are opCall's not implicitely assignable? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | Jarrett Billingsley wrote:
> since assignment can't be overloaded, it complains.
Assignments are overloadable.
import std.stdio;
int f(int p)
{
return 2*p;
}
real f(real p)
{
return 3.0*p;
}
void main()
{
auto i=f=2;
auto r=f=2.0;
writefln( i, r);
}
|
September 21, 2006 Re: Why are opCall's not implicitely assignable? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | Stewart Gordon wrote: > If it did, then how would you > assign object references of classes that have opCall at all? The answer is easy: the opCall for a reference of its own class should be disallowed. By the way: the ._= seems to be a useful shorthand for overloading an assignment :-) > Similarly, > > void function(int) qwert; > ... > qwert(yuiop); // calling the pointed-to function > qwert = asfdg; // changing which function is pointed to That is also easy: no qwert can have its own type as a single parameter. Otherwise show me an example. Therefore its distinguishable whether a "=" is a call or an assignment. |
September 21, 2006 Re: Why are opCall's not implicitely assignable? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Karen Lanrap |
Karen Lanrap wrote:
> Stewart Gordon wrote:
>
>> If it did, then how would you
>> assign object references of classes that have opCall at all?
>
> The answer is easy: the opCall for a reference of its own class should be disallowed.
>
> By the way: the ._= seems to be a useful shorthand for overloading an assignment :-)
>
>
>> Similarly,
>>
>> void function(int) qwert;
>> ...
>> qwert(yuiop); // calling the pointed-to function
>> qwert = asfdg; // changing which function is pointed to
>
> That is also easy: no qwert can have its own type as a single parameter. Otherwise show me an example.
>
> Therefore its distinguishable whether a "=" is a call or an assignment.
Maybe to the compiler .. but to the user?
|
September 21, 2006 Re: Why are opCall's not implicitely assignable? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Karen Lanrap | Karen Lanrap wrote: > Stewart Gordon wrote: > >> If it did, then how would you >> assign object references of classes that have opCall at all? > > The answer is easy: the opCall for a reference of its own class should be disallowed. And thereby lose the ability to use it for lambda-calculus/combinator stuff? > By the way: the ._= seems to be a useful shorthand for overloading an assignment :-) Use it if you like. But the basic question is: Why do you want to overload the assignment operator? http://www.digitalmars.com/d/faq.html#assignmentoverloading >> Similarly, >> >> void function(int) qwert; >> ... >> qwert(yuiop); // calling the pointed-to function >> qwert = asfdg; // changing which function is pointed to > > That is also easy: no qwert can have its own type as a single parameter. Otherwise show me an example. > > Therefore its distinguishable whether a "=" is a call or an assignment. It's distinguishable at the moment by whether the lvalue is a variable or a function. Trying to add a further dependence on the type of the rvalue would make the language more complicated and possibly harder to understand. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit. |
September 22, 2006 Re: Why are opCall's not implicitely assignable? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Karen Lanrap | "Karen Lanrap" <karen@digitaldaemon.com> wrote in message news:Xns9846572EEDA8digitaldaemoncom@63.105.9.61... > Jarrett Billingsley wrote: > >> since assignment can't be overloaded, it complains. > > Assignments are overloadable. Sorry, I meant overloading as in operator overloading. You can't overload opAssign in a class. > import std.stdio; > int f(int p) > { > return 2*p; > } > real f(real p) > { > return 3.0*p; > } > > void main() > { > auto i=f=2; > auto r=f=2.0; > writefln( i, r); > } This is just function overloading - keep in mind that you're not _really_ assigning anything to f, it's just sugar. |
September 22, 2006 Re: Why are opCall's not implicitely assignable? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | Jarrett Billingsley wrote:
> keep in mind that you're not_really_ assigning anything to f, it's just sugar.
Yes, and that is the problem with this sugar. It dilutes what an assignment _really_ is---if there is a definition for a _real_ assignment at all.
Assume there is a definition for what an assignment in D _really_ is.
If you then claim that "f=2" is not a _real_ assignment, you have to define what it is other than a _real_ assignment.
If you then say it is not an overloading of the assignment operator you have to give a reason, why it differs from overloading the assignment operator.
I do not see any difference. So please explain. I am posting in the learn group with the aim to understand the language. If I would have a clear opinion on this matter I would post in the main D group.
|
Copyright © 1999-2021 by the D Language Foundation