[Issue 24202] std.range.chain ganerated object has wrong .init

[d-bugmail at puremagic.com]

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

Jonathan M Davis <issues.dlang at jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang at jmdavisProg.co
                   |                            |m

--- Comment #4 from Jonathan M Davis <issues.dlang at jmdavisProg.com> ---
The reality of the matter is that D's current range API does not define the
state of a type's init value or even say that it's valid to do anything with
it. And in some cases, using the init value of a range will even result in a
segfault (e.g. with classes, since their init value is going to be null). The
intended behavior is that you actually call the range function and use the
result, not that you do anything with the init value of the range.

So, in the general case, you can't use the init value of ranges, and code
should not be doing anything with the init value of a range unless the
documentation for that specific range type specifies that the init value is
actually valid to use. So, any project depending on the init value of the
result of chain is relying on unspecified behavior, and that's arguably a bug
on the part of that project.

All that being said, it worked before, and if we can make it work again, we
should, since it broke code. And chain does return a struct, not a class (and
has no reason to return a class), so it should be possible to make it work -
especially since it worked before.

And ideally, we _would_ be able to require that the init value of ranges be
valid (and ideally even require that they be empty as long as they're not
infinite), but since we currently allow classes to be ranges, we can't actually
do that. It's certainly something that I'd like to fix with the update to the
range API for Phobos v3 though. Ultimately, this issue highlights one of the
issues with the current range API.

In any case, protobuf-d is relying on behavior that it should not be relying
on, but unless it would be truly problematic to fix it so that their code works
again, we should fix chain so that their code works again.

--