On Mon, Aug 31, 2009 at 2:37 AM, Marco Guazzone wrote:

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

...

I do not know of set being ordered or any implementation I use (considering that runtime sets are generally hash maps), so I would not expect that to be ordered personally.  I would use vector if I want something ordered.

You're right and in fact the runtime std::set does not provide a "front" operation.

I think you've got the problem: since sets are usually unordered a "front" operation may introduce ambiguities.

Since mpl::set provides this operation I think its behavior should be made more explicit in order to avoid any ambiguities (like the ones I've described in the previous email)

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. :)

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.

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

On Tue, Sep 1, 2009 at 10:39 AM, OvermindDL1 wrote:

...

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.

Well,  as I said previously, I completely agree with you. I've used front just for trying all mpl::set operations.

But the point is that "front" is defined for sets (and maps) so we and possible future users need a clear definition of its behavior on these data structures, or at least a big-note beside it saying   "Please don't use this operation for XXX since it is implementation dependent" where XXX in {"mpl::set", "mpl::map"}

I'm curious what MPL authors think about this.

I am curious too, wonder where they are... ;-)