On Mon, Aug 31, 2009 at 10:51 AM, OvermindDL1
Yea, I agree that the documentation on this should be cleared, not necessarily by saying that front returns possibly any element, but rather how it internally stores the type so we know what things like front/back/etc. will actually do. :)
Hmmm... But in this way (i.e., tying an high-level behavior to a low-level detail) we (as users) loose any advantage of encapsulation. I think it would be better to fix (and document) the behavior of "front< set >" regardless of the internal representation of a set. That is, the front element of a set is "blah blah blah" regardless of how a set is internally implemented. Another solution is to deprecate and subsequently remove this operation from sets; but probably this impacts on backward compatibility. Ah, obviously the same issue apply to mpl::map (didn't tried yet but conceptually the front of a map has an ambiguos meaning) -- Marco