Re: [Boost-users] [MPL] Front of a set of types

On Tue, Sep 1, 2009 at 2:18 AM, Marco Guazzone wrote:

On Mon, Aug 31, 2009 at 10:51 AM, OvermindDL1 wrote:

...

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)

I just think of it this way, front() will get the first element in a container, now sometime those containers are linear, like vector or list or cons, but other times they are not linear, then who knows what I may get first, like with set and map. Besides, is it not more proper to use an iterator? I have never personally used front, always use an iterator since I need all elements to test with when using a set/map, only ever used it with vector/list/cons, where it makes sense.