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 parse!type(...) to be turned into type.parse(...) which is the C# 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
parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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
prev sibling next sibling parent "barryharris" <slackovsky gmail.com> writes:
     auto test2 = New!AnotherTest("test2", 20);

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
prev sibling next sibling parent "barryharris" <slackovsky gmail.com> writes:
On Friday, 9 August 2013 at 04:33:52 UTC, barryharris wrote:
    auto test2 = New!AnotherTest("test2", 20);

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
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 "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
prev sibling next sibling parent "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
prev sibling 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 next sibling 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 "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 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 "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

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.

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 next sibling parent "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
prev sibling next sibling 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);

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 "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 next sibling parent "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..

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
prev sibling next sibling 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:



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


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
prev sibling next sibling parent "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
prev sibling next 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:


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 next sibling 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 "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