Small Buffer Optimization for string and friends

[H. S. Teoh]

On Sun, Apr 08, 2012 at 04:11:10PM +0200, Tove wrote:
> On Sunday, 8 April 2012 at 13:53:07 UTC, H. S. Teoh wrote:
> >On Sun, Apr 08, 2012 at 12:56:38AM -0500, Andrei Alexandrescu
> >wrote:
> >[...]
> >>1. What happened to the new hash project? We need to take that to
> >>completion.
> >[...]
[...]
> >The major outstanding issues are:
> >
> >- Qualified keys not fully working: the current code has a few corner
> >  cases that don't work with shared/immutable/inout keys. One major
> >  roadblock is how to implement this:
> >
> >	alias someType T;
> >	inout(T) myFunc(inout(T) arg, ...) {
> >		int[inout(T)] aa;
> >		...
> >	}
> >
> >  The problem is that inout gets carried over into the AA template,
> >  which breaks because it instantiates into something that has:
> >
> >	struct Slot {
> >		hash_t hash;
> >		inout(T) key;	// <-- this causes a compile error
> >		Value value;
> >	}
[...]
> doesn't this work?
> immutable std.traits.Unqual!(inout(T)) key;

I suppose so, but the problem is more with the return type of various AA
functions. If the user writes int[inout(T)] aa, then he would expect
that aa.keys should return inout(T)[]. But the problem here is that this
is impossible to express in the current system, because inout has a
different meaning when you write it in the AA method, than its meaning
in the context of the calling function. For example, this doesn't quite
work:

	struct AA {
		...
		inout(Key) keys() {
			...
			// Problem: inout here doesn't mean what it
			// means in the context of the caller
		}
	}


T

-- 
Tech-savvy: euphemism for nerdy.