On Friday, 20 September 2013 at 08:41:34 UTC, QAston wrote:

> Well, I won't argue about naming, for me when a type is a wrapper which provides desired interface to that type is an adapter :P.
>

I can live with that ;)

On 2013-09-20 11:37, Szymon Gatner wrote:

> If only std algorithms took containers (by that I mean things that
> container for accepts too) as arguments (and not iterators)... even in
> the form of new functions like foreach_all, transform_all etc.

Can't a container be a range as well?

-- 
/Jacob Carlborg

On Friday, 20 September 2013 at 10:00:32 UTC, Jacob Carlborg wrote:
> On 2013-09-20 11:37, Szymon Gatner wrote:
>
>> If only std algorithms took containers (by that I mean things that
>> container for accepts too) as arguments (and not iterators)... even in
>> the form of new functions like foreach_all, transform_all etc.
>
> Can't a container be a range as well?

Not sure what you mean but C++ has no concept of a range. Apparent there is now a study group but atm standard algos are crippled compared to "container for".

On 9/20/13, Szymon Gatner <noemail@gmail.com> wrote:
> I had similar thoughts when watching GoingNaive 2013.

Yeah. For example, Andrei's talk was very entertaining, but it was filled with "well I'm using this trick here, but I'll explain this later" bits, which just made following the whole thing really difficult, and it's all because C++ has become a monster.

On Friday, 20 September 2013 at 10:02:58 UTC, Szymon Gatner wrote:
> On Friday, 20 September 2013 at 10:00:32 UTC, Jacob Carlborg wrote:
>> On 2013-09-20 11:37, Szymon Gatner wrote:
>>
>>> If only std algorithms took containers (by that I mean things that
>>> container for accepts too) as arguments (and not iterators)... even in
>>> the form of new functions like foreach_all, transform_all etc.
>>
>> Can't a container be a range as well?
>
> Not sure what you mean but C++ has no concept of a range. Apparent there is now a study group but atm standard algos are crippled compared to "container for".

To clarify what I mean by crippled: standard algorithms were suppose to make code more expressive and one of the ways they would do it was to eliminate tedious iterator-based for loops:

instead of

for (typename Contaniner<T>::const_iterator it = c.begin(), it != c.end() ++it) {..}

you could do:

std::for_each(c.begin(), c.end(), [](T&) {...};)

(of course this all only makes any sense with lambdas, without them it is really hard to argue about expressivenes in the first place)

but now we can do this:

for (auto& v : c) {}

which is even nicer than the for_each version. Algorithms do more than iterating of course, but it is a shame they didn't evolve as basic constructs.

On Friday, 20 September 2013 at 10:02:58 UTC, Szymon Gatner wrote:
> On Friday, 20 September 2013 at 10:00:32 UTC, Jacob Carlborg wrote:
>> On 2013-09-20 11:37, Szymon Gatner wrote:
>>
>>> If only std algorithms took containers (by that I mean things that
>>> container for accepts too) as arguments (and not iterators)... even in
>>> the form of new functions like foreach_all, transform_all etc.
>>
>> Can't a container be a range as well?
>
> Not sure what you mean but C++ has no concept of a range. Apparent there is now a study group but atm standard algos are crippled compared to "container for".

To clarify what I mean by crippled: standard algorithms were
suppose to make code more expressive and one of the ways they
would do it was to eliminate tedious iterator-based for loops:

instead of

for (typename Contaniner<T>::const_iterator it = c.begin(), it !=
c.end() ++it) {..}

you could do:

std::for_each(c.begin(), c.end(), [](T&) {...};)

(of course this all only makes any sense with lambdas, without
them it is really hard to argue about expressivenes in the first
place)

but now we can do this:

for (auto& v : c) {}

which is even nicer than the for_each version. Algorithms do more
than iterating of course, but it is a shame they didn't evolve as
basic constructs.

20-Sep-2013 14:00, Jacob Carlborg пишет:
> On 2013-09-20 11:37, Szymon Gatner wrote:
>
>> If only std algorithms took containers (by that I mean things that
>> container for accepts too) as arguments (and not iterators)... even in
>> the form of new functions like foreach_all, transform_all etc.
>
> Can't a container be a range as well?
>

For Christ sake no, no and no. For starters range skips/drops elements when iterating, and thusly iteration has its own state that is useless for a container otherwise.

The idea of "contange" spreads like virus, no matter how abominable the end result is. The fact that slices sometimes look like containers (BTW ill-suited for anything beyond primitives/PODish stuff )  must be the corner stone of this belief. Strengthened on the motto of trying to make user defined types to mimic behavior of built-ins it leads to a school of thought that it's fine to blend ownership and access.

TL;DR: Suboptimal, unnatural and error prone are keywords.

-- 
Dmitry Olshansky

On Friday, 20 September 2013 at 10:47:52 UTC, Dmitry Olshansky wrote:
> 20-Sep-2013 14:00, Jacob Carlborg пишет:
>> On 2013-09-20 11:37, Szymon Gatner wrote:
>>
>>> If only std algorithms took containers (by that I mean things that
>>> container for accepts too) as arguments (and not iterators)... even in
>>> the form of new functions like foreach_all, transform_all etc.
>>
>> Can't a container be a range as well?
>>
>
> For Christ sake no, no and no. For starters range skips/drops elements when iterating, and thusly iteration has its own state that is useless for a container otherwise.

That would be a filtering range which adds additional logic that costs exactly the same as an if() statement inside a for loop when filtering on condition manually.

>
> TL;DR: Suboptimal, unnatural and error prone are keywords.

Why would it be suboptimal?

On Friday, 20 September 2013 at 10:47:52 UTC, Dmitry Olshansky wrote:
> 20-Sep-2013 14:00, Jacob Carlborg пишет:
>> On 2013-09-20 11:37, Szymon Gatner wrote:
>>
>>> If only std algorithms took containers (by that I mean things that
>>> container for accepts too) as arguments (and not iterators)... even in
>>> the form of new functions like foreach_all, transform_all etc.
>>
>> Can't a container be a range as well?
>>
>
> For Christ sake no, no and no. For starters range skips/drops elements when iterating, and thusly iteration has its own state that is useless for a container otherwise.
>

Iteration is a stateful process, ranges are related to the process of iteration not to containers. As you say state is useless for containers but is necessary to iteration and its context.

On Fri, 20 Sep 2013 14:47:38 +0400
Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
> For Christ sake no, no and no. For starters range skips/drops elements when iterating, and thusly iteration has its own state that is useless for a container otherwise.
> 
> The idea of "contange" spreads like virus, no matter how abominable the end result is. The fact that slices sometimes look like containers (BTW ill-suited for anything beyond primitives/PODish stuff )  must be the corner stone of this belief. Strengthened on the motto of trying to make user defined types to mimic behavior of built-ins it leads to a school of thought that it's fine to blend ownership and access.

I can vouch that ease of conflating array/slice/range, while normally
a wonderful convenience, has indeed led me into confusion when trying to
make a custom type range-compatible.

I felt naturally inclined to add the range primitives to the type itself, but when that led to issues like you described (especially the fact that a range *consumes* its elements while iterating, plus the inability to provide alternate views of the same data - which is a very powerful tool IMO), I finally started to grok that a container needs to *provide* a range, and not actually *be* one.

Well, except maybe for output ranges. (I think?)

> 
> TL;DR: Suboptimal, unnatural and error prone are keywords.
> 

They are? Cool!

auto foo(T)(real a, unnatural b, lazy Suboptimal!T opts) {...}

Looks fun! :)