www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - UFCS for templates

reply "JS" <js.mdnq gmail.com> writes:
Can we have UFCS for templates?

e.g.,

T New(T, A...)(A args) { }


T t = T.New(args);


Note, in this case, the type parameter is substituted.
Aug 08 2013
next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Thursday, 8 August 2013 at 17:35:02 UTC, JS wrote:

 Can we have UFCS for templates?

 e.g.,

 T New(T, A...)(A args) { }


 T t = T.New(args);


 Note, in this case, the type parameter is substituted.


That would be nice things to have, it would allow the 

way of doing it

Im just not sure if there would ever be a time where this might 
cause ambiguity, like where it was not obvious if the thing 
before the '.' should be the first type in the template or the 
first argument in the function.
Aug 08 2013
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 8 August 2013 at 17:35:02 UTC, JS wrote:

 Can we have UFCS for templates?

 e.g.,

 T New(T, A...)(A args) { }


 T t = T.New(args);


 Note, in this case, the type parameter is substituted.


As always, providing motivating use case and advantage/cost 
comparison is usual requirement to make something happen.

DIP's exist for a reason.
Aug 08 2013
next sibling parent reply "JS" <js.mdnq gmail.com> writes:
On Thursday, 8 August 2013 at 17:55:04 UTC, Dicebot wrote:

 On Thursday, 8 August 2013 at 17:35:02 UTC, JS wrote:

 Can we have UFCS for templates?

 e.g.,

 T New(T, A...)(A args) { }


 T t = T.New(args);


 Note, in this case, the type parameter is substituted.


 As always, providing motivating use case and advantage/cost 
 comparison is usual requirement to make something happen.

 DIP's exist for a reason.


Are you not smart enough to come up with use cases yourself? This 
is not some extremely rare thing that might be used 1 in 10^100.
Aug 08 2013
next sibling parent reply "Mike Parker" <aldacron gmail.com> writes:
On Friday, 9 August 2013 at 00:34:31 UTC, JS wrote:


 Are you not smart enough to come up with use cases yourself? 
 This is not some extremely rare thing that might be used 1 in 
 10^100.


It's not his proposal. The burden of proof is on you.
Aug 08 2013
parent reply "JS" <js.mdnq gmail.com> writes:
On Friday, 9 August 2013 at 00:57:21 UTC, Mike Parker wrote:

 On Friday, 9 August 2013 at 00:34:31 UTC, JS wrote:


 Are you not smart enough to come up with use cases yourself? 
 This is not some extremely rare thing that might be used 1 in 
 10^100.


 It's not his proposal. The burden of proof is on you.


Um, not really... Do you think that god made some law that 
requires me to? If he, you, or anyone else doesn't think such a 
feature is a good idea then so be it... It' not my problem is you 
want the D language to suffer. At some point something better 
will come with better features and D will succumb and all the 
time you invested will be a waste.

I would think that if you really cared about the D lang you would 
want it to be the best it can...

In any case, I know very well that it is quite useless for me to 
make suggestions for D... but I'm definitely not going to sit 
here and type up use cases because you are too lazy, don't have 
the foresight, or don't care to think about the issue. The fact 
is, I'm most likely not going to be able to convince you to 
accept anything I say because:

1. Something only useful to you is acceptable. You don't find 
this useful because you haven't used this construct, hence it is 
not acceptable. (This is generally known as close minded)

2. Generally things I "propose" are simplifications of semantics. 
I like to work efficiently. My proposes can be accomplished long 
hand... and for you, that is good enough... Either because you do 
not use such semantics and hence get tired of the inefficiency or 
don't like simplifications because you inanely feel they take 
away from the language by adding too much "overhead"(in some form 
or another).

So it is what it is. Take it or leave it. I've given the 
proposal, in maybe 10 years D will probably get around to having 
it... if it's still around at all.
Aug 08 2013
next sibling parent reply "barryharris" <slackovsky gmail.com> writes:
So instead of:

T t = New!T(args)

you would like:

T t = T.New(args)

Is that it?
Aug 08 2013
parent "barryharris" <slackovsky gmail.com> writes:
On Friday, 9 August 2013 at 03:41:56 UTC, barryharris wrote:

 So instead of:

 T t = New!T(args)

 you would like:

 T t = T.New(args)

 Is that it?


Never mind, I read your original post again...


 Note, in this case, the type parameter is substituted.
Aug 08 2013
prev sibling next sibling parent "Mike Parker" <aldacron gmail.com> writes:
On Friday, 9 August 2013 at 03:29:20 UTC, JS wrote:


 It's not his proposal. The burden of proof is on you.





 I would think that if you really cared about the D lang you 
 would want it to be the best it can...

 In any case, I know very well that it is quite useless for me 
 to make suggestions for D... but I'm definitely not going to 
 sit here and type up use cases because you are too lazy, don't 
 have the foresight, or don't care to think about the issue. The 
 fact is, I'm most likely not going to be able to convince you 
 to accept anything I say because:

 1. Something only useful to you is acceptable. You don't find 
 this useful because you haven't used this construct, hence it 
 is not acceptable. (This is generally known as close minded)

 2. Generally things I "propose" are simplifications of 
 semantics. I like to work efficiently. My proposes can be 
 accomplished long hand... and for you, that is good enough... 
 Either because you do not use such semantics and hence get 
 tired of the inefficiency or don't like simplifications because 
 you inanely feel they take away from the language by adding too 
 much "overhead"(in some form or another).


I don't have an opinion on this proposal one way or the other. 
I'm merely pointing out the way the process tends to work around 
here. If you have a serious proposal, it's your responsibility to 
present use cases for it. Others quite possibly will do so as 
well if they agree with you. Because it's not me, or Dicebot, or 
any of the other community members you have to convince (though 
it does help to have them championing your cause). It's Walter 
and Andrei who will ultimately give the thumbs up or down.

So if you want your proposals to be seriously considered for 
implementation, back them up with use cases. If not, then let 
them languish.
Aug 09 2013
prev sibling next sibling parent reply "anonymous" <anonymous example.com> writes:
On Friday, 9 August 2013 at 00:34:31 UTC, JS wrote:

 On Thursday, 8 August 2013 at 17:55:04 UTC, Dicebot wrote:


[...]

 As always, providing motivating use case and advantage/cost 
 comparison is usual requirement to make something happen.

 DIP's exist for a reason.


 Are you not smart enough to come up with use cases yourself?


On Friday, 9 August 2013 at 03:29:20 UTC, JS wrote:

 On Friday, 9 August 2013 at 00:57:21 UTC, Mike Parker wrote:


[...]

 It's not his proposal. The burden of proof is on you.




[...]

 Do you think that god made some law that requires me to?


[...]

 It' not my problem is you want the D language to suffer.


[...]

 all the time you invested will be a waste.


[...]

 if you really cared about the D lang


[...]

 you are too lazy, don't have the foresight, or don't care


[...]

 This is generally known as close minded


[...]

 Take it or leave it.


By being so hostile, you make it really hard for others to 
consider/support your suggestions.
Aug 09 2013
parent reply "eles" <eles eles.com> writes:
On Friday, 9 August 2013 at 11:30:54 UTC, anonymous wrote:

 On Friday, 9 August 2013 at 00:34:31 UTC, JS wrote:

 On Thursday, 8 August 2013 at 17:55:04 UTC, Dicebot wrote:


 [...]

 As always, providing motivating use case and advantage/cost 
 comparison is usual requirement to make something happen.

 DIP's exist for a reason.


 Are you not smart enough to come up with use cases yourself?


 On Friday, 9 August 2013 at 03:29:20 UTC, JS wrote:

 On Friday, 9 August 2013 at 00:57:21 UTC, Mike Parker wrote:




C'mon, guys, cool down. Both (or the three) of you are right.

Some tend to forget that everybody here is a volunteer, so there
is no such such thing as a duty. Others are enthusiastic and
throw in ideas. People are of different kinds, sparks appear
sometime.

The bottom line is that nobody here is doing bad things on
purpose. Mistakes happen.

Let's be constructive and, equally important, forgivingly.
Aug 09 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 9 August 2013 at 11:46:42 UTC, eles wrote:

 C'mon, guys, cool down. Both (or the three) of you are right.

 Some tend to forget that everybody here is a volunteer, so there
 is no such such thing as a duty. Others are enthusiastic and
 throw in ideas. People are of different kinds, sparks appear
 sometime.

 The bottom line is that nobody here is doing bad things on
 purpose. Mistakes happen.

 Let's be constructive and, equally important, forgivingly.


I am just pointing out that right now he is wasting time with all 
his enthusiasm because those proposals have hardly any chance to 
be noticed by Andrei or Walter. Pointing out that despite that my 
personal attitude is "GTFO" and I could have just silently 
ignored it. If it is not constructive, I don't know what is.
Aug 09 2013
prev sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 9 August 2013 at 11:46:42 UTC, eles wrote:

 On Friday, 9 August 2013 at 11:30:54 UTC, anonymous wrote:

 On Friday, 9 August 2013 at 00:34:31 UTC, JS wrote:

 On Thursday, 8 August 2013 at 17:55:04 UTC, Dicebot wrote:


 [...]

 As always, providing motivating use case and advantage/cost 
 comparison is usual requirement to make something happen.

 DIP's exist for a reason.


 Are you not smart enough to come up with use cases yourself?


 On Friday, 9 August 2013 at 03:29:20 UTC, JS wrote:

 On Friday, 9 August 2013 at 00:57:21 UTC, Mike Parker wrote:




 C'mon, guys, cool down. Both (or the three) of you are right.

 Some tend to forget that everybody here is a volunteer, so there
 is no such such thing as a duty. Others are enthusiastic and
 throw in ideas. People are of different kinds, sparks appear
 sometime.


That is *exactly* why a proposal should be backed with a use 
case. The people implementing them are *also* volunteers. Their 
time is just as valuable. Putting in personal effort reduces the 
burden of the implementors, and increases the chances of said 
proposal to go through (or at this point even be considered 
seriously).

Really, all I'm seeing is "I have this proposal; fuck you if you 
don't think it's good, I don't have any time to waste to explain 
it to you"... Well, in that case, OK. I don't have time to 
consider it either. Moving on.
Aug 09 2013
parent "eles" <eles eles.com> writes:
On Friday, 9 August 2013 at 13:36:44 UTC, monarch_dodra wrote:

 On Friday, 9 August 2013 at 11:46:42 UTC, eles wrote:

 On Friday, 9 August 2013 at 11:30:54 UTC, anonymous wrote:

 On Friday, 9 August 2013 at 00:34:31 UTC, JS wrote:

 On Thursday, 8 August 2013 at 17:55:04 UTC, Dicebot wrote:


 [...]

 As always, providing motivating use case and advantage/cost 
 comparison is usual requirement to make something happen.

 DIP's exist for a reason.


 Are you not smart enough to come up with use cases yourself?


 On Friday, 9 August 2013 at 03:29:20 UTC, JS wrote:

 On Friday, 9 August 2013 at 00:57:21 UTC, Mike Parker wrote:






 Really, all I'm seeing is "I have this proposal; fuck you if 
 you don't think it's good, I don't have any time to waste to 
 explain it to you"... Well, in that case, OK. I don't have time 
 to consider it either. Moving on.


Look, sorry to resurrect this thread, but I don't see only that.
I would have replied to such kind of proposal in the following
manner:

"Hey, cool that you were thinking about that! Could you come with
a better example, please? It could be an interesting proposal,
just develop it a bit more."

Let's not forget that sparks on either side are just as harmful.
Aug 12 2013
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 9 August 2013 at 03:29:20 UTC, JS wrote:

 Um, not really... Do you think that god made some law that 
 requires me to?


There's nothing supernatural involved, but there is basic 
scientific method and engineering rigour.  Anyone can throw out 
ideas about how they think things "ought to be", but if you can't 
even provide a shred of evidence in your favour, it's not 
convincing.  Specifically, it makes it look like either a) your 
suggestion doesn't effect any real, tangible change or b) you 
haven't seriously considered your own proposal or addressed 
possible shortcomings.  Moreover, it shows a lack of respect for 
the time of others (which is just as finite as your own).  In 
short: the "shotgun" approach you've been taking with your 
feature requests is not working.


 It' not my problem is you want the D language to suffer.



 I would think that if you really cared about the D lang



 sit here and type up use cases because you are too lazy, don't 
 have the foresight, or don't care to think about the issue. The


/snip
Fallacy doesn't help anything. Please stop that. I sincerely hope 
you don't believe belittling and insulting the community you want 
support from is an endearing trait.


 At some point something better will come with better features
 and D will succumb and all the time you invested will be a
 waste.


Sorry, I don't understand this point at all.  A waste?  Science 
is the incremental march of progress; each advancement building 
on the last. How is being one of those stepping stones a waste?  
I hope we eventually DO have something even better than D2.  Like 
D3 or something. ;)

-Wyatt
Aug 09 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, August 09, 2013 05:29:05 JS wrote:

 On Friday, 9 August 2013 at 00:57:21 UTC, Mike Parker wrote:

 On Friday, 9 August 2013 at 00:34:31 UTC, JS wrote:

 Are you not smart enough to come up with use cases yourself?
 This is not some extremely rare thing that might be used 1 in
 10^100.


 
 It's not his proposal. The burden of proof is on you.


 
 Um, not really..


[snip]

Actually, that is how it works. If you want a change made to the language, you 
have to convince the maintainers of the language that your proposed change is 
worth making. You can throw ideas out there all day if you want to, but 
changes are made because someone convinces the people in charge that they 
should be made. If we implemented every stray idea that was proposed, we'd 
constantly be implementing new ideas and never have a stable language. We 
also likely wouldn't a language that was worth using.

Even if your idea is absolutely fantastic, you have to convince others of 
that, or it's not going anywhere. The attitude of "take it or leave it" when 
presenting an idea will pretty much always result in "leave it." There are 
just too many ideas and too much to do for it to be otherwise.

Also, you're coming across as being very combative and confrontational, and 
whether you mean to do that or not, it's not conducive to having a rational 
discussion or having the sort of collaborative environment that we're looking 
to have here. If you want others to listen to you or to convince anyone of 
anything around here, you may want to consider adjusting how you present 
things so that you and your arguments come across in a more favorable light.

- Jonathan M Davis
Aug 08 2013
parent reply "eles" <eles eles.com> writes:
On Saturday, 10 August 2013 at 18:28:34 UTC, Jonathan M Davis
wrote:

 On Friday, August 09, 2013 05:29:05 JS wrote:

 On Friday, 9 August 2013 at 00:57:21 UTC, Mike Parker wrote:

 On Friday, 9 August 2013 at 00:34:31 UTC, JS wrote:


 Um, not really..


 [snip]

 Actually, that is how it works. If you want a change made to 
 the language, you


That's the wrong POV, sorry about that. He/She does not want a
change to be made in the language, at least not for one's own
good, but for the language's own good.

It is not a contest about which changes are better documented.
Besides, a better documented change is not necessarily the best
one. Better documentation helps, but it is not necessarily the
burden of the first one to say it to do it.

It is the burden of whoever feels like. Not feeling like is OK.
Bashing other for not feeling like is KO. This is not a sect.

OTOH, if one's think that such proposed change is not worthy, he
could assume the role of writing a DIP on why such thing is
undesirable to have it in the language.

The question to ask oneself/others is not "You want a change made
to the language?", but "What pro/con reasons I could give for
this change? What manner this change, if implemented, would
impact the language? And that impact would be for the better or
for the worse?".

Yes, I agree, not all stones thrown in here are bricks. But some
are grains of sands of which such bricks are made.
Aug 12 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 12 August 2013 at 12:07:26 UTC, eles wrote:

 ,,,


You seem to miss the key point - burden of proof is one someone 
who does not spend efforts. Idea costs nothing. Proposals costs 
nothing. If JS would have come with done pull request for this -  
it would have been my job to provide convincing objections 
against merging it. But he wants someone else to implement it and 
rages about it as a little kid. This makes his personal value for 
D development a negative value.

And if someone takes neutral query for extra clarification as 
personal abuse, he really needs to solve some issues before ever 
trying to communicate on the Internet again.

No one is valuable enough to care about satisfying his ego in 
scope of overwhelmingly unreasonable behavior.
Aug 12 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 12 August 2013 at 12:53:40 UTC, Dicebot wrote:

 On Monday, 12 August 2013 at 12:07:26 UTC, eles wrote:

 ,,,


 You seem to miss the key point - burden of proof is one someone 
 who does not spend efforts. Idea costs nothing. Proposals costs 
 nothing. If JS would have come with done pull request for this 
 -  it would have been my job to provide convincing objections 
 against merging it. But he wants someone else to implement it 
 and rages about it as a little kid. This makes his personal 
 value for D development a negative value.

 And if someone takes neutral query for extra clarification as 
 personal abuse, he really needs to solve some issues before 
 ever trying to communicate on the Internet again.

 No one is valuable enough to care about satisfying his ego in 
 scope of overwhelmingly unreasonable behavior.


Stop contaminating this thread with BSn you troll :D

http://forum.dlang.org/thread/yirpfddwipouomcbaqeb forum.dlang.org
Aug 12 2013
prev sibling parent "BS" <slackovsky gmail.com> writes:
On Monday, 12 August 2013 at 12:07:26 UTC, eles wrote:

 On Saturday, 10 August 2013 at 18:28:34 UTC, Jonathan M Davis
 wrote:

 On Friday, August 09, 2013 05:29:05 JS wrote:

 On Friday, 9 August 2013 at 00:57:21 UTC, Mike Parker wrote:

 On Friday, 9 August 2013 at 00:34:31 UTC, JS wrote:


 Um, not really..


 [snip]

 Actually, that is how it works. If you want a change made to 
 the language, you


 That's the wrong POV, sorry about that. He/She does not want a
 change to be made in the language, at least not for one's own
 good, but for the language's own good.

 It is not a contest about which changes are better documented.
 Besides, a better documented change is not necessarily the best
 one. Better documentation helps, but it is not necessarily the
 burden of the first one to say it to do it.

 It is the burden of whoever feels like. Not feeling like is OK.
 Bashing other for not feeling like is KO. This is not a sect.

 OTOH, if one's think that such proposed change is not worthy, he
 could assume the role of writing a DIP on why such thing is
 undesirable to have it in the language.

 The question to ask oneself/others is not "You want a change 
 made
 to the language?", but "What pro/con reasons I could give for
 this change? What manner this change, if implemented, would
 impact the language? And that impact would be for the better or
 for the worse?".

 Yes, I agree, not all stones thrown in here are bricks. But some
 are grains of sands of which such bricks are made.


I disagree.

Any change requested is often *a lot* of work for volunteers. 
Volunteers who are already spending a lot of free time developing 
D for people to use at no cost. Expecting them to spend even more 
time coming up with use cases from proposals laid out in a small 
NG post is a bit rich. I can understand some people getting a bit 
frustrated by it (this isn't the only thread like this from the 
OP).

It would be different if D were commercial. User proposals would 
probably require a DIP draft to be submitted via the web before 
it would even be looked at. Maybe that would avoid all this 
teenageesque whinging...
Aug 12 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 9 August 2013 at 00:34:31 UTC, JS wrote:

 On Thursday, 8 August 2013 at 17:55:04 UTC, Dicebot wrote:

 On Thursday, 8 August 2013 at 17:35:02 UTC, JS wrote:

 Can we have UFCS for templates?

 e.g.,

 T New(T, A...)(A args) { }


 T t = T.New(args);


 Note, in this case, the type parameter is substituted.


 As always, providing motivating use case and advantage/cost 
 comparison is usual requirement to make something happen.

 DIP's exist for a reason.


 Are you not smart enough to come up with use cases yourself? 
 This is not some extremely rare thing that might be used 1 in 
 10^100.


Even while agreeing the proposal is a good you succeed in looking 
bad to me. Dude, the world do not revolve around you. Deal with 
it.
Aug 09 2013
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 8/8/13 2:55 PM, Dicebot wrote:

 On Thursday, 8 August 2013 at 17:35:02 UTC, JS wrote:

 Can we have UFCS for templates?

 e.g.,

 T New(T, A...)(A args) { }


 T t = T.New(args);


 Note, in this case, the type parameter is substituted.


 As always, providing motivating use case and advantage/cost comparison
 is usual requirement to make something happen.

 DIP's exist for a reason.


Come on, in this case I don't think he needs to provide a motivating use 
case.

What's the motivating use case for UFCS in the first place? You can live 
without it just fine, only the syntax is uglier. Being able to call a 
function "foo" whose first argument is of type T as T.foo is nice and 
uniform.

Not having the same for templates is *not* uniform, and code tends to 
get uglier.

That's his use case.

However, it might slow down compilation times because now you have to 
look for every possible template and see if the first argument matches 
that of the "receiver" of the method (but maybe that's how UFCS is done 
in the first place?).
Aug 09 2013
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 9 August 2013 at 12:22:51 UTC, Ary Borenszweig wrote:

 Come on, in this case I don't think he needs to provide a 
 motivating use case.

 What's the motivating use case for UFCS in the first place? You 
 can live without it just fine, only the syntax is uglier. Being 
 able to call a function "foo" whose first argument is of type T 
 as T.foo is nice and uniform.


It wasn't community proposal so same logic does not apply here. 
Walter does what he believes is right - it is up to us to 
convince him if something is proposed that does not get in line 
with his ideas. It is his language after all.

However, if you ask, it does add important design tool similar to 
extension methods and prevent temptation to stockpile dozens of 
utility functions in aggregates. One needs to show that similar 
issue exists with templates.


 Not having the same for templates is *not* uniform, and code 
 tends to get uglier.

 That's his use case.


It is not a use case. Use case is specific code snippet in two 
forms - before the proposal implementation and after. With formal 
analysis of benefits.
Aug 09 2013
prev sibling next sibling parent reply "barryharris" <slackovsky gmail.com> writes:
On Thursday, 8 August 2013 at 17:35:02 UTC, JS wrote:

 Can we have UFCS for templates?

 e.g.,

 T New(T, A...)(A args) { }


 T t = T.New(args);


 Note, in this case, the type parameter is substituted.


Actually, what is wrong with New!T(args)? This works fine for me:

T t = New!T(args) ??

template New(T) if(is(T == class)) {
  T New(A...)(A args) {
     return new T(args);
  }
}


class Test {
     this(in string s, in int i) {
         writefln("s=%s, i=%s", s, i);
     }
}
class AnotherTest {
     this(in int i) {
         writefln("i=%s", i);
     }
}

void main() {
     auto test = New!Test("test", 10);
     auto test2 = New!AnotherTest("test2", 20);
}
Aug 08 2013
parent reply "barryharris" <slackovsky gmail.com> writes:
     auto test2 = New!AnotherTest("test2", 20);


oops, should read:

auto test2 = New!AnotherTest(20);

--------------------
-1 for me anyway for the following reason:

A.function(args)    // I know A is a function value parameter
function!A(args)    // I know A is a template type parameter
function!10(args)   // I know 10 is a template type parameter
10.function(args)   // I know 10 is a function value parameter

So I don't like it...
Aug 08 2013
parent reply "barryharris" <slackovsky gmail.com> writes:
On Friday, 9 August 2013 at 04:33:52 UTC, barryharris wrote:

    auto test2 = New!AnotherTest("test2", 20);


 oops, should read:

 auto test2 = New!AnotherTest(20);

 --------------------
 -1 for me anyway for the following reason:

 A.function(args)    // I know A is a function value parameter
 function!A(args)    // I know A is a template type parameter
 function!10(args)   // I know 10 is a template type parameter
 10.function(args)   // I know 10 is a function value parameter

 So I don't like it...


To clarify, that above is what we have now but with the OP 
suggestion

A.function(args)

becomes too ambiguous as to whether A is a template parameter or 
function parameter (i.e. refers to type or value)
Aug 09 2013
parent "Tyler Jameson Little" <beatgammit gmail.com> writes:
On Friday, 9 August 2013 at 07:22:12 UTC, barryharris wrote:

 On Friday, 9 August 2013 at 04:33:52 UTC, barryharris wrote:

   auto test2 = New!AnotherTest("test2", 20);


 oops, should read:

 auto test2 = New!AnotherTest(20);

 --------------------
 -1 for me anyway for the following reason:

 A.function(args)    // I know A is a function value parameter
 function!A(args)    // I know A is a template type parameter
 function!10(args)   // I know 10 is a template type parameter
 10.function(args)   // I know 10 is a function value parameter

 So I don't like it...


 To clarify, that above is what we have now but with the OP 
 suggestion

 A.function(args)

 becomes too ambiguous as to whether A is a template parameter 
 or function parameter (i.e. refers to type or value)


I agree. I briefly considered the following syntax to help 
disambiguate it:

     A!function(args)

But then this code would be confusing:

     void func(alias pred)(int x) {}
     func!(func)(3);

Which function is the template argument? The same goes for the 
dot operator, if A happens to be an alias to a function.

I don't think this is inline (sorry for the pun...) with the 
intent of UFCS, which IMHO was to make methods less special:

     class A {
         void foo();
     }
     void bar(A a);

     A a;
     a.foo();
     a.bar();

This way you can make a function call look like a method call. 
This is what the compiler does internally anyway (if I'm not 
mistaken), so it makes sense to allow the programmer to do this, 
which can be very useful in extending types.
Aug 09 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 8 August 2013 at 17:35:02 UTC, JS wrote:

 Can we have UFCS for templates?

 e.g.,

 T New(T, A...)(A args) { }


 T t = T.New(args);


 Note, in this case, the type parameter is substituted.


What happen if the first template parameter is an alias parameter 
?
Aug 09 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, August 08, 2013 19:35:01 JS wrote:

 Can we have UFCS for templates?
 
 e.g.,
 
 T New(T, A...)(A args) { }
 
 
 T t = T.New(args);
 
 
 Note, in this case, the type parameter is substituted.


And how is the compiler supposed to know whether T is being passed as a 
template argument or a function argument? In some cases, it'll be clear. In 
others (such as with alias parameters), the compiler will have no way of 
knowing.

Also, I think that allowing it would increase confusion for little benefit 
anyway. The primary benefit of UFCS is making it so that generic code can call 
functions without caring about whether they're member functions or free 
functions. There is no such benefit with template arguments.

- Jonathan M Davis
Aug 08 2013
prev sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Thursday, 8 August 2013 at 17:35:02 UTC, JS wrote:

 Can we have UFCS for templates?

 e.g.,

 T New(T, A...)(A args) { }


 T t = T.New(args);


 Note, in this case, the type parameter is substituted.


A while back I made this enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=8381

It might be similar to what you're proposing (although it's not 
clear what it is that you're proposing).

I'd be interested in hearing some actual use cases for this 
feature though (I can't think of any even though I made that 
feature request).
Aug 13 2013