Weird const behavior

[Steven Schveighoffer]

On 12/20/18 9:49 AM, Marko wrote:
> On Thursday, 20 December 2018 at 02:05:53 UTC, Adam D. Ruppe wrote:
>> On Thursday, 20 December 2018 at 01:37:59 UTC, Simón Oroño wrote:
>>> The only difference (code-wise) is the `const` keyword. I've tried 
>>> with both `ldc` and `dmd` with same result. Why is the output 
>>> different when the variable is `const`?
>>
>> A const range cannot be iterated by a generic template (without 
>> additional work, at least), so writeln just sees it as a blob instead 
>> of something it can loop over.
> 
> I'm not the OP but I'd like to understand this:
> 
> When he is comparing "a == b" it returns true, but then it diverges on 
> the usability.
> 
> So a == b compares just values without types?
> 
> But is this right? I mean if they are equal shouldn't they have the same 
> behavior?
> 
> Marko.

It's really how opEquals is marked.

opEquals for structs (without a specific implementation), is marked as a 
combination of comparing all the fields, whatever they are marked. Any 
basic types are comparable whether they are const or not. So most likely 
the range struct's opEquals is marked const.

However, popFront is likely not const. In some rare cases it can be 
(i.e. an infinite range of a single value). If the range cannot be 
operated, isInputRange returns false.

-Steve