char *i = nullptr;
std::copy_n(i, 0, does_not_matter);

GCC 4.8 hat kein Problem damit. VC++ 2013 schmeißt ein Debug Assertion Failed.
Anscheinend wird der nullptr als ungültig befunden bevor die Länge geprüft wird:

template<class _InIt,
	class _Diff,
	class _OutIt> inline
	_OutIt copy_n(_InIt _First, _Diff _Count,
		_OutIt _Dest)
	{	// copy [_First, _First + _Count) to [_Dest, ...)
	_DEBUG_POINTER(_First);
	_DEBUG_POINTER(_Dest);
	if (_Count <= 0)
		return (_Dest);
	else
		return (_Copy_n(_First, _Count,
			_Dest, _Is_checked(_Dest)));
	}

Daniel Krügler <a href= schrieb:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53248#c6">

> By the way - I think we discussed this already, bu now I can't find anything -
> what should we take the begin() == end() == unique value exactly to mean? Don't
> tell me something like an ugly reinterpret_cast<T*>(this), please

My interpretation is that returning nullptr should be OK. I don't see any requirement that a unique value is something that cannot be returned by any other container (In a private communication with Howard he at least agreed with my interpretation). If this interpretation is unsafe, it should also be clarified by revised wording.

(Ist jetzt zwar kein Zitat aus dem Standard, aber wenn Daniel Krügler und Howard Hinnant der gleichen Meinung sind, dürfte man das als ziemlich bindend betrachten.)

InputIterator dürfen auch im past-the-end Zustand sein, also ist das mMn ein Bug in VS.