Hi, I totally agree, returning a boost::optional is a better solution than what I proposed. Is there any way around this right now, or does the range accessors require a non-empty range not to result in undefined behavior\crash? I'm very much looking forward to having range extensions included in boost. /Viktor On Wed, Jun 5, 2013 at 3:09 PM, Akira Takahashi wrote:

Hi Viktor,

2013/6/5 Viktor Sehr

...

I'd like to suggest the addition of a default value to the range access adaptors. Either by adding it as an extra, non-necessary parameter for the functions, or by duplicating the functions as "front_or_default(T default value)".

For example it would be useful for finding objects which I am not sure exists in a range.

std::vector<int> vec = boost::assign::list_of(2)(4)(6); auto first_odd = vec | filtered(is_odd) | front(); // undefined? auto first_odd = vec | filtered(is_odd) | front_or_default(-1); // everything is fine!

Another option would be a function which returns the adress, or nullptr if the value does not exist?

/Viktor

My Boost.Range Extension has `front` accessor.

http://dl.dropboxusercontent.com/u/1682460/git/OvenToBoost/libs/range/doc/ht... https://github.com/faithandbrave/OvenToBoost/tree/master/boost/range/access

This is now proposing to Boost.Range.

However, I don't have `front_or_default` feature. I think better way is add `optional_front` feature (return boost::optional). Because `front` return `T&` but default value is not reference.

Thanks, Akira

...

...

======================== Akira Takahashi mailto:faithandbrave@gmail.com https://sites.google.com/site/faithandbrave/about/en

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Michel: Why would you want a single range? (assuming a range of size one) /Viktor On Wed, Jun 5, 2013 at 5:09 PM, Michel Morin wrote:

Akira Takahashi wrote:

...

My Boost.Range Extension has `front` accessor.

"Range Access" adaptors in your extensions are interesting. For the consistency of range adaptors, shouldn't `front` adaptor return `single` range?

Regards, Michel

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi Michel, 2013/6/6 Michel Morin

Akira Takahashi wrote:

...

My Boost.Range Extension has `front` accessor.

"Range Access" adaptors in your extensions are interesting. For the consistency of range adaptors, shouldn't `front` adaptor return `single` range?

I see. `optional_front` usage is following: if (optional<T> x = r | optional_front()) { std::cout << x.get() << std::endl; } If `front` return signle range, the usage is following: for (T x : x | front) { std::cout << x << std::endl; } If `front` is error, the return value is empty range. I think single range approach is better. However, I think now `front` and `optional_front` is useful. I would like to add `optional_front` and `front_range`. Thanks! Akira

I implemented `optional_front`, `optional_back`, and `optional_at`.

https://github.com/faithandbrave/OvenToBoost/commit/3c828848be96de1c7d5d17a9... Great, I hope this all makes it into boost soon. /Viktor

2013年6月6日木曜日 Robert Jones robertgbjones@gmail.com:

On 6 June 2013 09:17, Akira Takahashi javascript:;> wrote:

...

I implemented `optional_front`, `optional_back`, and `optional_at`.

https://github.com/faithandbrave/OvenToBoost/commit/3c828848be96de1c7d5d17a9...

...

Why have you dropped 'BOOST_DEDUCED_TYPENAME' in favour of 'typename'?

This macro is unneccesary for now Boost support platform. --

...

========================

高橋 晶(Akira Takahashi) mailto:faithandbrave@gmail.com ブログ「Faith and Brave - C++で遊ぼう」 http://d.hatena.ne.jp/faith_and_brave/

Hi Yusuke, 2013/6/8 Yusuke Ichinohe

Hi Michel, Akira,

I think simpler solution would be to add range support for boost::optional in additional header (e.g. ). i.e. boost::optional will become random access range.

// OK #include for (T x : r | optional_front()) { std::cout << x << std::endl }

// also OK if (optional<T> x = r | optional_front()) { std::cout << x.get() << std::endl; }

// another example: #include optional<int> x = 100; assert(boost::size(x) == 1); optional<int> y = boost::none; assert(boost::size(y) == 0);

Thanks.

Thank you for your comment. That's good idea! I agree first design. But I think need more vote. Thanks, Akira

...

======================== Akira Takahashi mailto:faithandbrave@gmail.com https://sites.google.com/site/faithandbrave/about/en

Akira Takahashi wrote:

If `front` return signle range, the usage is following:

for (T x : x | front) { std::cout << x << std::endl; }

If `front` is error, the return value is empty range.

This looks like `taken(1)`. Considering the fact that `container.front()` assumes `rng` is not empty, I came up with another idea: implementing `front` as a range-unchecking version of `taken` (`front(n)` requires that the range has length at least n), and `front` defaults to `front(1)`. (BTW, the documentation says that `taken` returns BidirectionalRange, but I believe `taken` returns ForwardRange.)

I think single range approach is better. However, I think now `front` and `optional_front` is useful.

I would like to add `optional_front` and `front_range`.

IMO, your `front` and `optional_front` are not range adaptors; they're range functions that use a pipe operator. Because they introduce a new syntax to Boost.Range, it would be better to make discussions about this syntax in a new thread. If this new syntax is accepted, then it is natural to expect that other range functions (size, all_of, etc.) are also supported. Regards, Michel