Again, what are the compiler errors you get?

These operators are wrong anyway, because they are mutating the left-hand side when they should be returning a new value. If you want += semantics, you should define a += operator.

9 minutes ago, Kylotan said:

Again, what are the compiler errors you get?

No compile errors, quoting my message above:

Quote

And yet, operator>> and operator<< just work fine with a Number&, how does that make sense?

2 minutes ago, MarcusAseth said:

No compile errors

28 minutes ago, MarcusAseth said:

If I have those operator overloads just taking a plain Number& as argument, then things won't compile.

@Lactose Maybe I didn't explained myself properly, I am not considering that as the error, that's why is not even in my code example, and that makes sense because as I said

Quote

 I need the operator overloads to be templates in case I try to do something like "Number<int>(3) + Number<float>(4.15)" which are two different type.

In that case the compile error is obviously I have no operator overload between the 2 different types, if it was Number&.

The question is another one...and is about the absence of ant kind of compile errors 

Sorry, you're talking in hypotheticals. Can you form a smaller, precise example of the problem? i.e.

1. What are you doing?
2. What do you expect or want to happen?
3. What actually happens?

20 minutes ago, Kylotan said:

Sorry, you're talking in hypotheticals. Can you form a smaller, precise example of the problem? i.e.

1. What are you doing?
2. What do you expect or want to happen?
3. What actually happens?

My fault, I usually go in long winded paths of my thoughts and antefacts before of my real question, so it all get mixed together

I'll try to reformulate the question in a better way and without uneccessary informations in the code:

Given the code below, what is Number& deduced to be when used in a "friend operator overload" argument?

My assumption was that, since the code inside main() works for both instantiation of the class, then it must be the same of me writing Number<T>& inside the class, which is the unique type of Number for a particular instatiation of that template class. Is it the case?

template<typename T>
class Number {
	T val;
public:
	//Constructors
	Number() :val{ 0 } {}
	Number(T v) :val{ v } {}

	//Operators
	friend ostream& operator<<(ostream& stream, Number& rhs) { stream << rhs.val; return stream; }
	friend istream& operator>>(istream& stream, Number& rhs) { stream >> rhs.val; return stream; }
};

int main()
{
	Number<double> myDouble(3.4);
	Number<int> myInt(6);
	cout << myDouble << endl << endl;
	cout << myInt << endl << endl;

	return 0;
}

Why would you think that the meaning of Number is different in that statement to any other statement inside the class definition? Just like the default constructor, it generates different code for each possible type of T. You don't need to write Number<T>() : val { 0 } {} - everything inside Number is considered to be parameterised on T, because that is what the template statement at the start does.

When the code sees cout << myDouble, it looks for an operator<< that takes an ostream on the left and a Number<double> on the right. There is a template that provides such an operator for Number<T> where T includes double, so that gets used. And it compiles correctly because Number<T> contains a friend declaration that allows a correctly-specified operator (which you've not included, but we'll assume is correct) to access the private member.

34 minutes ago, Kylotan said:

(which you've not included, but we'll assume is correct).

Thanks for the reply, makes sense, though not sure about the quote above, I pasted all the code I have right now (only left out the #include of the standard library stuff and using namespace std directive), which compile, nothing is hidden

Oh, I missed the fact that your stream operators were inline. That's a really weird syntax, because the friend keyword is for non-member functions. It's probably getting ignored entirely here.

26 minutes ago, Kylotan said:

It's probably getting ignored entirely here.

I believe it is doing something, because if I remove it then the operator declared inside the class only expects to receive a single argument which would be the "righ-hand side" which is the stream, because the "this" it's passed implicitly or something like that, basically it would end up being:

ostream& operator<<(ostream& stream) { stream << val; return stream; }

and called in this super weird way:

myDouble << cout;

So the friend is there just to have it take 2 arguments so that I can have the stream as left-hand side.

Regarding the weird looking, I don't know,  I see it works so I kind of stick with this pattern 

Though of course if it was a long list of expressions inside of it, I would move the declaration outise the class