(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

I think added syntax complexity is not worth the convenience gain.

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

> 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
>

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

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

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

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.

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.

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.
>
>