I ran across this blog post on limitations of the C++ range proposal [1] and wrote up a simple D version in virtually no time.

https://run.dlang.io/is/y6uk18

import std.range : isInputRange, ElementType;

auto interspersed(T, U)(T x, U y)
    if (isInputRange!T && is(U : ElementType!T))
{
    import std.range : dropBackOne;
    import std.algorithm.iteration : map, joiner;

    return x.map!(a => [a, y]).joiner.dropBackOne;
}

void main()
{
    import std.range : iota;
    import std.array : array;

    auto x = iota(5);
    auto y = interspersed(x, 5);
    assert(y.array == [0, 5, 1, 5, 2, 5, 3, 5, 4, 5]);
}


[1] https://www.fluentcpp.com/2019/09/13/the-surprising-limitations-of-c-ranges-beyond-trivial-use-cases/

On 09/16/2019 12:53 PM, jmh530 wrote:

> https://www.fluentcpp.com/2019/09/13/the-surprising-limitations-of-c-ranges-beyond-trivial-use-cases/ 
> 

That article is about just one feature of C++ (ranges) and it exposes many common issues with the language and its ecosystem. Four quotes from the article and my comments on each:

1) "having to come up with clever hacks to be able to do something as basic as this is not a good sign"

Amen.

Personally, enable_if is the first thing that I've seen right away as a hack.

2) "We need a reasonably coherent language that can be used by “ordinary programmers” whose main concern is to ship great applications on time. [Bjarne Stroustrup]"

Amen.

3) "It’s as if the issues of limited usability, code complexity, leaky abstractions and completely unreasonable compile-times are of no consequence whatsoever to the committee members?"

Amen.

(Just today I've realized that C++ did not take boost::shared_array; gotta research why that might have happened.)

4) "It seems to me that Bjarne Stroustrup’s plea from Remember the Vasa! fell on deaf ears (again, my subjective opinion)."

Amen!

Given all those important observations about C++ that are on just one subject, C++ is proof how irrational humans can be. Humans continue spending immeasurable amounts of time and money to stick with C++. We should see anthropological, psychological, mass hysterical, whatever research on this human behavior. (Stockholm syndrome has been suggested in the past.)

Ali

On 09/16/2019 12:53 PM, jmh530 wrote:
> I ran across this blog post on limitations of the C++ range proposal [1]
> and wrote up a simple D version in virtually no time.

I had fun implementing the following version, which should not create any array:

import std.stdio;
import std.range;

auto interspersed(R, D)(R r, D delim) {
  struct MyRoundRobin {
    bool doDelim = false;

    auto empty() {
      return r.empty;
    }

    auto front() {
      return (doDelim ? delim : r.front);
    }

    auto popFront() {
      if (!doDelim) {
        r.popFront();
      }
      doDelim = !doDelim;
    }
  }

  return MyRoundRobin();
}

void main(){
  auto r = 10.iota.interspersed(42);
  writefln("%(%s %)", r);
}

std.range.roundRobin came close but it does not support 'StoppingPolicy' like 'zip' and 'lockstep' do.

Ali

P.S. I ran into a checked format string issue and created the following bug report:

 https://issues.dlang.org/show_bug.cgi?id=20218

On 9/16/2019 2:47 PM, Ali Çehreli wrote:
> On 09/16/2019 12:53 PM, jmh530 wrote:
>  > I ran across this blog post on limitations of the C++ range proposal [1]
>  > and wrote up a simple D version in virtually no time.
> 
> I had fun implementing the following version, which should not create any array:

Please post D solutions to the reddit thread!!

https://www.reddit.com/r/programming/comments/d50n4j/the_surprising_limitations_of_c_ranges_beyond/

On Monday, 16 September 2019 at 21:47:08 UTC, Ali Çehreli wrote:
> On 09/16/2019 12:53 PM, jmh530 wrote:
> > I ran across this blog post on limitations of the C++ range
> proposal [1]
> > and wrote up a simple D version in virtually no time.
>
> I had fun implementing the following version, which should not create any array:
> [snip]


Even better!

On Monday, 16 September 2019 at 20:29:02 UTC, Ali Çehreli wrote:
> Given all those important observations about C++ that are on just one subject, C++ is proof how irrational humans can be. Humans continue spending immeasurable amounts of time and money to stick with C++. We should see anthropological, psychological, mass hysterical, whatever research on this human behavior. (Stockholm syndrome has been suggested in the past.)

It's not too irrational to stick with a certain programming language. Is it more irrational for a team to
- continue building out an existing, working, potentially sprawling C++ code base or
- rewrite things in a different language entirely or
- introduce a second programming language for new features with corresponding interop challenges?

The reality is that there is a whole bunch of C++ code out there that you can't easily use from other programming languages. Some of the code is industry standard, a single implementation, and barely bindable to other compiled languages.* All this past investment in C++ codebases that is still paying off today  is what keeps people from moving on. In order to get people to switch away, you have to show them that they can get a larger payoff of some sorts by switching.

--

* A lot of published open source for professional graphics falls into that category.

On 09/17/2019 04:39 AM, Gregor Mückl wrote:
> On Monday, 16 September 2019 at 20:29:02 UTC, Ali Çehreli wrote:
>> Given all those important observations about C++ that are on just one
>> subject, C++ is proof how irrational humans can be. Humans continue
>> spending immeasurable amounts of time and money to stick with C++. We
>> should see anthropological, psychological, mass hysterical, whatever
>> research on this human behavior. (Stockholm syndrome has been
>> suggested in the past.)
>
> It's not too irrational to stick with a certain programming language.

Agreed because it's human to stick with status quo.

> Is
> it more irrational for a team to
> - continue building out an existing, working, potentially sprawling C++
> code base or

Agreed again but most of those teams are hurting every single day on every single line of code.

> - rewrite things in a different language entirely or
> - introduce a second programming language for new features with
> corresponding interop challenges?

Good points but I don't think good amount of thinking is applied to the language choice. It's more like "No CTO will be fired for choosing C++."

> The reality is that there is a whole bunch of C++ code out there that
> you can't easily use from other programming languages. Some of the code
> is industry standard, a single implementation, and barely bindable to
> other compiled languages.* All this past investment in C++ codebases
> that is still paying off today  is what keeps people from moving on. In
> order to get people to switch away, you have to show them that they can
> get a larger payoff of some sorts by switching.

I really don't think CTOs give serious thought on development costs either. From my limited experience it was more like "we will go with C++".

> * A lot of published open source for professional graphics falls into
> that category.

I don't have experience in that domain but I wrote ImageMagick bindings once for an experimental project. (I used the C API; I don't know how hard their C++ API would be to use with D.)

Recently I wrote a D API where alternative C++ API exists (for ROS). Yes, I spent more time writing the API (three months total for the API and the application itself) but in the end we gained expertise on the domain, can make any change orimprovement whenever we want, and our code runs faster. Every situation will be different but I think we gained in that case.

Ali

On 09/16/2019 02:47 PM, Ali Çehreli wrote:

> auto interspersed(R, D)(R r, D delim) {
>    struct MyRoundRobin {
>      bool doDelim = false;
>
>      auto empty() {
>        return r.empty;
>      }
>
>      auto front() {
>        return (doDelim ? delim : r.front);
>      }
>
>      auto popFront() {
>        if (!doDelim) {
>          r.popFront();
>        }
>        doDelim = !doDelim;
>      }
>    }
>
>    return MyRoundRobin();
> }

That function causes an embarrassing closure allocation. Instead,

1) Both 'r' and 'delim' should be copied as members of the struct and
2) The struct should be defined as 'static'

I wrote something longer on the Learn forum:

  https://forum.dlang.org/thread/qm2cni$1ra7$1@digitalmars.com

Ali