Hello, I have a problem with using std.range.choose():

When using std.range.choose() on a range R, for which hasElaborateCopyConstructor!R is true, then a postblit for the result of std.range.choose() is created, which includes a call to R.__postblit(). However, hasElaborateCopyConstructor!R may be true, even if R does not define this(this), for example in the case that one of the members of R does so.

The example that I encountered (reduced to a minimum) was the the following:

import std.stdio : stdin;
import std.range: choose;

void main()
{
    ubyte[1][] secondRange;
    choose(true, stdin.byChunk(1), secondRange);
}

In this case File defines this(this), but ByChunk does not, so the above code does not compile.

I think what std.range.choose() does here is completely unnecessary: When the result of std.range.choose() gets copied, the underyling range gets copied, and if it implements postblit, it is automatically called. No need to call it explicitly, right?.

On Wednesday, 17 February 2016 at 01:35:34 UTC, Johannes Loher wrote:
> Hello, I have a problem with using std.range.choose():
>
> When using std.range.choose() on a range R, for which hasElaborateCopyConstructor!R is true, then a postblit for the result of std.range.choose() is created, which includes a call to R.__postblit(). However, hasElaborateCopyConstructor!R may be true, even if R does not define this(this), for example in the case that one of the members of R does so.
>
> [...]

Well, has anybody got an idea if this behaviour is intended? Is it a bug?

On 02/20/2016 02:18 AM, Johannes Loher wrote:
> On Wednesday, 17 February 2016 at 01:35:34 UTC, Johannes Loher wrote:
>> Hello, I have a problem with using std.range.choose():
>>
>> When using std.range.choose() on a range R, for which
>> hasElaborateCopyConstructor!R is true, then a postblit for the result
>> of std.range.choose() is created, which includes a call to
>> R.__postblit(). However, hasElaborateCopyConstructor!R may be true,
>> even if R does not define this(this), for example in the case that one
>> of the members of R does so.
>>
>> [...]
>
> Well, has anybody got an idea if this behaviour is intended? Is it a bug?

Filed:

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

Ali