www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - support UFCS with fully qualified function names (was in

reply Timothee Cour <thelastmammoth gmail.com> writes:
(I've re-posting here upon request from bearophile, who seems to like it :)
)

I'd like to be able to use UFCS with fully qualified function names.

A typical use case is to disambiguate , as in the following case:

import std.path;
import std.string;
void main(){
    //Error: std.path.join()(const(char)[] p1, const(char)[] p2, const(char[
])[] more...) at ... conflicts with std.string.join at ...
    auto a="".join("\n");
    //what I'd like to have:
    auto a="".(std.path.join)("\n");
}

note: the fact that std.path.join!().join is deprecated is irrelevant to
this discussion.

Any chance this could be supported?

benefits:
avoids breaking UFCS chains
May 20 2013
next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
I think added syntax complexity is not worth the convenience gain.
May 21 2013
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, May 21, 2013 09:51:14 Dicebot wrote:
 I think added syntax complexity is not worth the convenience gain.
I tend to agree. I don't think that the idea is entirely without merit, but I don't think that it's really much of a loss to not be able to use UFCS in situations like that. The only situation where it could pose a major problem would be with properties, but if we're not going to have strict properties (and it seems pretty clear at this point that we're not going to), then it doesn't really matter, because you can use a property function as a normal function if you have to. - Jonathan M Davis
May 21 2013
prev sibling next sibling parent reply Timothee Cour <thelastmammoth gmail.com> writes:
 you can use a property function as a normal function if you have to.
I must've missed that. Do you mean this will become valid? struct A{ int x_; property int x(){return x_;} } void main(){ A a; int x1=a.x(); int x2=a.x; }
 I don't think that it's really much of a loss to not be able to use UFCS
in situations like that I keep running into such situations, because phobos reuses function names a lot in different modules, and it's only going to get worse as phobos size increases. On Tue, May 21, 2013 at 1:22 AM, Jonathan M Davis <jmdavisProg gmx.com>wrote:
 On Tuesday, May 21, 2013 09:51:14 Dicebot wrote:
 I think added syntax complexity is not worth the convenience gain.
I tend to agree. I don't think that the idea is entirely without merit, but I don't think that it's really much of a loss to not be able to use UFCS in situations like that. The only situation where it could pose a major problem would be with properties, but if we're not going to have strict properties (and it seems pretty clear at this point that we're not going to), then it doesn't really matter, because you can use a property function as a normal function if you have to. - Jonathan M Davis
May 21 2013
parent "nazriel" <spam dzfl.pl> writes:
On Tuesday, 21 May 2013 at 08:31:45 UTC, Timothee Cour wrote:
 I keep running into such situations, because phobos reuses 
 function names a
 lot in different modules, and it's only going to get worse as 
 phobos size
 increases.
In overall it is rather rare case but if it happens I just use renamed or selective imports. I am neutral on this just giving one of alternative solutions for this.
May 21 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
On Tuesday, 21 May 2013 at 07:51:15 UTC, Dicebot wrote:
 I think added syntax complexity is not worth the convenience 
 gain.
The added syntax is just a pair of ( ). And the convenience is to not break your programming flux, requiring to get out of the flow programming (http://en.wikipedia.org/wiki/Flow-based_programming), and introducing auxiliary variables. So maybe the added syntax is worth the convenience. Bye, bearophile
May 21 2013
parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 21 May 2013 at 08:49:27 UTC, bearophile wrote:
 The added syntax is just a pair of ( ).
And you can find plenty of comments in property threads about how much this single pair of () matters. In fact it is worse, because it redefines meaning of similar syntax pattern ("a.b") within one expression.
 And the convenience is to not break your programming flux, 
 requiring to get out of the flow programming 
 (http://en.wikipedia.org/wiki/Flow-based_programming), and 
 introducing auxiliary variables. So maybe the added syntax is 
 worth the convenience.
You can just use local selective imports and alias problematic symbol to different name : http://dlang.org/module.html
May 21 2013
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, May 21, 2013 01:31:36 Timothee Cour wrote:
 you can use a property function as a normal function if you have to.
I must've missed that. Do you mean this will become valid? struct A{ int x_; property int x(){return x_;} } void main(){ A a; int x1=a.x(); int x2=a.x; }
 I don't think that it's really much of a loss to not be able to use UFCS
in situations like that I keep running into such situations, because phobos reuses function names a lot in different modules, and it's only going to get worse as phobos size increases.
It's not 100% clear what's going to happen with property, but given the last major discussion on it, it's quite clear that we're not going to be strictly enforcing property, and the -property flag is going to get the boot (I thought that it was removed from the Phobos build, but it looks like it's still there). It seems likely that property will have no effect on getters, and it may or may not be required on setters. That matter wasn't settled, but it's very clear that strict property enforcement was not wanted by the majority (too many people want optional parens), so the situation where a symbol conflict with a UFCS property makes it impossible to call will be going away (and it currently only exists when -property is used). - Jonathan M Davis
May 21 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/21/2013 10:37 AM, Jonathan M Davis wrote:
 On Tuesday, May 21, 2013 01:31:36 Timothee Cour wrote:
 you can use a property function as a normal function if you have to.
I must've missed that. Do you mean this will become valid? struct A{ int x_; property int x(){return x_;} } void main(){ A a; int x1=a.x(); int x2=a.x; }
 I don't think that it's really much of a loss to not be able to use UFCS
in situations like that I keep running into such situations, because phobos reuses function names a lot in different modules, and it's only going to get worse as phobos size increases.
It's not 100% clear what's going to happen with property, but given the last major discussion on it, it's quite clear that we're not going to be strictly enforcing property, and the -property flag is going to get the boot (I thought that it was removed from the Phobos build, but it looks like it's still there). It seems likely that property will have no effect on getters, and it may or may not be required on setters. That matter wasn't settled, but it's very clear that strict property enforcement was not wanted by the majority (too many people want optional parens), so the situation where a symbol conflict with a UFCS property makes it impossible to call will be going away (and it currently only exists when -property is used). - Jonathan M Davis
No, it is the other way round. property void foo(int x){ } void main(){ foo(2); } // this compiles with -property. The consensus (modulo details) was that anything that -property implements will not be implemented and anything that -property does not implement will be implemented.
May 21 2013
parent Timothee Cour <thelastmammoth gmail.com> writes:
ok I found better:
see:
http://forum.dlang.org/post/mailman.1002.1370829729.13711.digitalmars-d-learn puremagic.com


On Tue, May 21, 2013 at 2:40 PM, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 05/21/2013 10:37 AM, Jonathan M Davis wrote:

 On Tuesday, May 21, 2013 01:31:36 Timothee Cour wrote:

 you can use a property function as a normal function if you have to.

 I must've missed that. Do you mean this will become valid?
 struct A{
    int x_;
     property int x(){return x_;}
 }
 void main(){
 A a;
 int x1=a.x();
 int x2=a.x;
 }

  I don't think that it's really much of a loss to not be able to use UFCS

 in situations like that

 I keep running into such situations, because phobos reuses function
 names a
 lot in different modules, and it's only going to get worse as phobos size
 increases.
It's not 100% clear what's going to happen with property, but given the last major discussion on it, it's quite clear that we're not going to be strictly enforcing property, and the -property flag is going to get the boot (I thought that it was removed from the Phobos build, but it looks like it's still there). It seems likely that property will have no effect on getters, and it may or may not be required on setters. That matter wasn't settled, but it's very clear that strict property enforcement was not wanted by the majority (too many people want optional parens), so the situation where a symbol conflict with a UFCS property makes it impossible to call will be going away (and it currently only exists when -property is used). - Jonathan M Davis
No, it is the other way round. property void foo(int x){ } void main(){ foo(2); } // this compiles with -property. The consensus (modulo details) was that anything that -property implements will not be implemented and anything that -property does not implement will be implemented.
Jun 09 2013