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)

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.

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.

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.

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.

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

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.

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.

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 ?

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