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.

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.

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

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

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.

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.

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.

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

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

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