On 12/19/18 1:30 PM, H. S. Teoh wrote:
On Wed, Dec 19, 2018 at 01:19:28PM -0500, Steven Schveighoffer via
Digitalmars-d-learn wrote:
On 12/19/18 12:20 PM, H. S. Teoh wrote:
[...]
It was originally a simple wrapper when I first submitted it, but
Andrei requested to use RefCounted in order to work around the
subrange traversal problem. I.e., in the original implementation,
the underlying range traversed twice, once when each subrange is
consumed, and once when you call popFront on the outer range. Having
RefCounted allows us to retain a reference to the original range so
that subranges will also advance the underlying range as seen by the
outer range, thereby eliminating calling popFront on the underlying
range twice per element.
I see, that does pose an issue, especially if you aren't traversing it
in order. Communicating back to the "outer" range where the traversal
should stop requires having a reference to it in the subrange.
However, in terms of a random-access range, or even an array, it
should be pretty straightforward to... oh wait, these are narrow
strings. nevermind.
[...]
For CTFE, though, we don't really care about calling popFront twice, so
I surmise that we should be able to just use the original non-RefCounted
implementation. It's not hard, just take out the bits where the
subranges communicate with the outer range, and just have each subrange
carry its own instance of the underlying range. It will incur some CTFE
performance hit, but that's better than not being CTFE-able at all.
There is a problem here though -- CTFE must compile the same
(essentially) as normal runtime. We can make different code paths for
CTFE, but the problem I see in the meantime is that the TYPE must be the
same.
In other words, the CTFE version shouldn't use RefCounted, but the type
already has that in there.
I also see some bad things happening if initialized at compile time via
CTFE, but then used at runtime. But I don't know if that works or not.
-Steve
