Should the "front" range primitive be "const" ?

H. S. Teoh hsteoh at
Tue Jan 30 15:49:28 UTC 2018

On Tue, Jan 30, 2018 at 08:54:00AM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote:
> On 1/29/18 8:20 PM, Jonathan M Davis wrote:
> > If you want to put an attribute on it, inout is better, because then
> > it will work with any constness, but in general, I'd suggest just
> > avoiding the use of const or immutable altogether when dealing with
> > ranges. front can return a const element, and that will happen if
> > you use auto and whatever you're wrapping is const, but const ranges
> > are utterly useless, because they can't be mutated and thus can't be
> > iterated. As such, almost no code is ever going to have a range that
> > is anything but mutable, which means that having front be anything
> > but mutable is generally pointless.

I think you're conflating a const range, which *is* pretty useless since
you can't iterate it, and a const .front, which only means "calling
.front will not change the state of the range".  The latter is very
possible, and potentially useful.  Well, there's also a .front that
returns a const element, which means "you can't change the current
element of the range". That's also possible, and useful.

> Not necessarily. A main reason for const is to advertise "I'm not
> going to change your mutable data" on a function. So reading that
> front is const (or inout more appropriately) can assure you front
> makes this guarantee.
> Yes, it also allows you to call on an immutable or const range, both
> of which are for the most part useless.
> So I would say const ranges are useless, but const members of ranges
> provide some value.
> That being said, const is viral, as is inout. So unfortunately if you
> *don't* mark your functions const or inout, then wrappers need to take
> this into account.

Simen has had some ideas recently about "head mutable" aka tail-const,
which could be a first step towards making const ranges, or rather
tail-const ranges, actually usable:

tl;dr summary:

(1) Ranges implement a standard method, tentatively called
    opHeadMutable, that returns a head-mutable version of themselves.
    For example, const(MyRange!T).opHeadMutable would return

(2) Standard library functions would recognize opHeadMutable and use it
    where needed, e.g., when you hand them a const range.

(3) Profit. :-P


In a world without fences, who needs Windows and Gates? -- Christian Surchi

More information about the Digitalmars-d-learn mailing list