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

--- Comment #1 from Dragos Carp <dragoscarp@gmail.com> ---
> ////////////////////////////////////
> Observed result (dmd >= 1.104.0)
> Assertion fails.
> 
> Expected result:
> assertion passes (working with dmd 1.103.1)

Of course I meant 2.104.0 and 2.103.1.

--

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

Ate Eskola <Ajieskola@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Ajieskola@gmail.com

--- Comment #2 from Ate Eskola <Ajieskola@gmail.com> ---
I'm a bit on the fence on whether I agree with this being a regression. However, I should declare conflict of interest. I was the one who wrote the optimisation that broke this so potentially I'm just excusing my shortcomings.

The issue here is you're not really depending on what `chain` by itself does. Instead, you're depending on the initial state of it's type, which is undocumented and therefore, arguably implementation-defined. In principle you can expect predictable behaviour from the type only if you initialise it or assign to it with the `chain` function.

On the other hand, in practice we do depend on stuff like this every now and then anyway. The `.init` value for `Chain` type could be calculated at compile time so that it'd agree with the `chain` function call when all the subranges are also at their `.init` value. I think this is would be an improvement, but I'm not sure whether it'd qualify as a real regression fix.

--

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

--- Comment #3 from Dragos Carp <dragoscarp@gmail.com> ---
It broke functioning code. It is a regression!

https://github.com/dcarp/protobuf-d/issues/43


chain(...).init should be consistent. If it reports non-empty, what should be
the result of front?

--

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

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

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

--- Comment #4 from Jonathan M Davis <issues.dlang@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.

--