digitalmars.D - support UFCS with fully qualified function names (was in
- Timothee Cour (18/18) May 20 2013 (I've re-posting here upon request from bearophile, who seems to like it...
- Dicebot (1/1) May 21 2013 I think added syntax complexity is not worth the convenience gain.
- Jonathan M Davis (9/10) May 21 2013 I tend to agree. I don't think that the idea is entirely without merit, ...
- Timothee Cour (15/29) May 21 2013 I must've missed that. Do you mean this will become valid?
- nazriel (5/10) May 21 2013 In overall it is rather rare case but if it happens I just use
- bearophile (9/11) May 21 2013 The added syntax is just a pair of ( ). And the convenience is to
- Dicebot (7/13) May 21 2013 And you can find plenty of comments in property threads about how
- Jonathan M Davis (12/32) May 21 2013 It's not 100% clear what's going to happen with @property, but given the...
- Timon Gehr (7/39) May 21 2013 No, it is the other way round.
- Timothee Cour (4/58) Jun 09 2013 ok I found better:
(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
I think added syntax complexity is not worth the convenience gain.
May 21 2013
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
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 UFCSin 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
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
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
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
On Tuesday, May 21, 2013 01:31:36 Timothee Cour wrote: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 Davisyou 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 UFCSin 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.
May 21 2013
On 05/21/2013 10:37 AM, Jonathan M Davis wrote:On Tuesday, May 21, 2013 01:31:36 Timothee Cour wrote: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.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 Davisyou 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 UFCSin 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.
May 21 2013
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: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.you can use a property function as a normal function if you have to.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 DavisI 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 UFCSin 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.
Jun 09 2013