On Friday, 31 January 2014 at 10:31:52 UTC, Namespace wrote:
>> So, if your notation was implemented, it would no longer be easy
>> to know. The compiler would have to be context sensitive, which
>> is more complex and not perfect. I doubt Walter would go for that
>> so you'll never be able to use an explicit templated opCall...
>> but implicit are ok.
>
> I never wanted a new notation. I only want that the bug gets fixed. :)

Wow, that is the point! it's not a bug! You are asking for a new
notation. In your post you did

	F f;
	int i = f(3,4,5);
	float f_ = f!float(6, 7, 8);

f is an object!!! not a template, you are calling opCall on it,
right? (the last line) BUT THAT SYNTAX IS FOR TEMPLATES ONLY!!!


Do you not see that if I add

template f(T)
{
    T f(int x, int y, int z) { return 3.14; }
}

that there is no way the compiler can know what you mean now?


(again, assuming your "bug" was fixed)

PAY ATTENTION!!! The following is your code with the added
template I gave and two lines of yours commented out!

import std.stdio;

struct F {
	T opCall(T = int)(int a, int b, int c) {
		return cast(T)(a * b * c);
	}
}

void main() {
	//F f;
	//int i = f(3,4,5);
	float f_ = f!float(6, 7, 8);
}

template f(T)
{
	T f(int x, int y, int z) { return 3.14; }
}

NOTE TO YOURSELF!! IT COMPILES JUST FINE!!!!

I didn't change a damn thing! I'm not playing tricks or anything.
the float f_ line is exactly what you gave, YET I MADE IT COMPILE
WITH OUT YOUR STRUCT!!!

THIS MEANS IT IS AMBIGUOUS! Your struct or my template would make
it work(again, assume you could actually do what you want). This
means it is impossible for the compiler to know which one you
meant if we uncommented the lines. The only way it would work is
if one couldn't have variables and templates use the same name at
the same time in the same scope.... but this already is possible
and is not ambiguous.

So to fix your "bug" could break the compiler in certain
circumstances. will it do it in all circumstances, no. But I
doubt Walter will go for it. Not only does it look like a
template call(it is in the above example), it might be hard to
parse and is ambiguous in some cases.


Now, maybe there is a trick to make it all work using aliases and
templates but that is not the point. The point is, that the is an
ambiguity because you are using the EXACT same syntax for two
different things. If you can't see that then I can't help you any
further.

On Friday, 31 January 2014 at 11:42:54 UTC, Frustrated wrote:
> On Friday, 31 January 2014 at 10:31:52 UTC, Namespace wrote:
>>> So, if your notation was implemented, it would no longer be easy
>>> to know. The compiler would have to be context sensitive, which
>>> is more complex and not perfect. I doubt Walter would go for that
>>> so you'll never be able to use an explicit templated opCall...
>>> but implicit are ok.
>>
>> I never wanted a new notation. I only want that the bug gets fixed. :)
>
> Wow, that is the point! it's not a bug! You are asking for a new
> notation. In your post you did
>
> 	F f;
> 	int i = f(3,4,5);
> 	float f_ = f!float(6, 7, 8);
>
> f is an object!!! not a template, you are calling opCall on it,
> right? (the last line) BUT THAT SYNTAX IS FOR TEMPLATES ONLY!!!
>
>
> Do you not see that if I add
>
> template f(T)
> {
>     T f(int x, int y, int z) { return 3.14; }
> }
>
> that there is no way the compiler can know what you mean now?
>
>
> (again, assuming your "bug" was fixed)
>
> PAY ATTENTION!!! The following is your code with the added
> template I gave and two lines of yours commented out!
>
> import std.stdio;
>
> struct F {
> 	T opCall(T = int)(int a, int b, int c) {
> 		return cast(T)(a * b * c);
> 	}
> }
>
> void main() {
> 	//F f;
> 	//int i = f(3,4,5);
> 	float f_ = f!float(6, 7, 8);
> }
>
> template f(T)
> {
> 	T f(int x, int y, int z) { return 3.14; }
> }
>
> NOTE TO YOURSELF!! IT COMPILES JUST FINE!!!!
>
> I didn't change a damn thing! I'm not playing tricks or anything.
> the float f_ line is exactly what you gave, YET I MADE IT COMPILE
> WITH OUT YOUR STRUCT!!!
>
> THIS MEANS IT IS AMBIGUOUS! Your struct or my template would make
> it work(again, assume you could actually do what you want). This
> means it is impossible for the compiler to know which one you
> meant if we uncommented the lines. The only way it would work is
> if one couldn't have variables and templates use the same name at
> the same time in the same scope.... but this already is possible
> and is not ambiguous.
>
> So to fix your "bug" could break the compiler in certain
> circumstances. will it do it in all circumstances, no. But I
> doubt Walter will go for it. Not only does it look like a
> template call(it is in the above example), it might be hard to
> parse and is ambiguous in some cases.

Are you always so aggressive? :)

> Are you always so aggressive? :)

Not always ;) Just when I feel like it....