www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: disable all member function calls for rvalues?

reply Kagamin <spam here.lot> writes:
Andrei Alexandrescu Wrote:

 Andrei Alexandrescu Wrote:
 
 In contrast with the original example this is not a bug.

equivalent code involving fields does something. It's an egregious breakage of consistency because properties were meant to be generalizations of fields in the first place.



 foo().obj.unlink();
 foo().obj2().unlink();

File does not have an unlink member but I get your point. As I said, refusing to bind ref to rvalues disables a few valid uses. I am willing to renounce those few uses.

So you deliberately want to break consistency between fields and properties? As I understnd, .obj will be allowed and .obj2 will be disallowed?
Dec 25 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Kagamin wrote:
 Andrei Alexandrescu Wrote:
 
 Andrei Alexandrescu Wrote:
 
 In contrast with the original example this is not a bug.

syntactic equivalent code involving fields does something. It's an egregious breakage of consistency because properties were meant to be generalizations of fields in the first place.



 foo().obj.unlink(); foo().obj2().unlink();

said, refusing to bind ref to rvalues disables a few valid uses. I am willing to renounce those few uses.

So you deliberately want to break consistency between fields and properties? As I understnd, .obj will be allowed and .obj2 will be disallowed?

Properties that return rvalues cannot be fully consistent with fields anyway. By the change I suggested, false friends that look syntactically the same but do different things are avoided. Anyway, I dropped the suggestion due to the array slice example, but I still think this is a serious problem with D. Andrei
Dec 25 2009
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-12-25 09:13:13 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Anyway, I dropped the suggestion due to the array slice example, but I 
 still think this is a serious problem with D.

If you could pass "this" by value instead of ref, it'd solve the problem nicely: struct MyRange { MyRange opSlice(int, int) byvalue; void length(int) property; } Here you can call opSlice on a lvalue since it takes the "this" argument by value, but you can't call length(int) because it takes it by ref. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Dec 25 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2009-12-25 09:13:13 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 Anyway, I dropped the suggestion due to the array slice example, but I 
 still think this is a serious problem with D.

If you could pass "this" by value instead of ref, it'd solve the problem nicely: struct MyRange { MyRange opSlice(int, int) byvalue; void length(int) property; } Here you can call opSlice on a lvalue since it takes the "this" argument by value, but you can't call length(int) because it takes it by ref.

I've seen that. The only problem I see with that is that it complicates the language. Ideally some sort of inference could be applicable. Andrei
Dec 25 2009
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-12-25 11:13:10 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 If you could pass "this" by value instead of ref, it'd solve the 
 problem nicely:
 
     struct MyRange {
         MyRange opSlice(int, int)  byvalue;
         void length(int)  property;
     }
 
 Here you can call opSlice on a lvalue since it takes the "this" 
 argument by value, but you can't call length(int) because it takes it 
 by ref.
 

I've seen that. The only problem I see with that is that it complicates the language. Ideally some sort of inference could be applicable.

If we ever get that "universal calling syntax" thing, where any function can be called as if it were a member function, it would be super simple: void MyRange opSlice(MyRange this, int, int) {...} Just don't put "ref" in front of the first argument. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Dec 25 2009