Yet another const problem...

H. S. Teoh hsteoh at quickfur.ath.cx
Tue May 22 11:50:52 PDT 2012


On Tue, May 22, 2012 at 02:21:17PM -0400, Steven Schveighoffer wrote:
> On Sun, 20 May 2012 20:07:04 -0400, Mehrdad <wfunction at hotmail.com> wrote:
> 
> >struct Foo
> >{
> >	@property bool empty() const { return p == null; }
> >	@property auto front() inout { return p; }
> >	void popFront() { p--; }
> >
> >
> >	// So far so good? okay, let's define save()..
> >
> >	auto save() inout { return typeof(this)(this.tupleof); }
> >
> >
> >	// Now let's implement opApply() using the above ^^
> >
> >	int opApply(void delegate(size_t, typeof(p)) dg) const
> >	{
> >		size_t i = 0;
> >		int r = 0;
> >
> >		// So far so good...
> >		for (auto me = this.save(); !r && !me.empty; me.popFront())
> >		{
> >			// Whoops, won't work -- 'me' is const! :(
> >			r = dg(me);
> >		}
> >
> >		return r;
> >	}
> >}
> >
> >
> >
> >How do you fix this without duplicating your code?
> 
> This is yet another cry for tail-const.

+1. I badly need it for the new AA implementation too. Otherwise I have
to resort to a bunch of incomplete deeply-nested template hacks to
create a type with the necessary qualifiers.


> It's very obvious we need a clean solution for tail-const before the
> const story is finished.
[...]

We also need to sort out the mess that is inout. Currently it works
great -- if you only have a single const qualifier to pass through to
the return type. It becomes a hairy mess when you have delegate
parameters, esp. more than one of them (the delegates have their own
"inout scope" which may or may not be tied to the function's inout --
this is inexpressible with the current language).


T

-- 
Without geometry, life would be pointless.


More information about the Digitalmars-d mailing list