What type does byGrapheme() return?

H. S. Teoh hsteoh at quickfur.ath.cx
Tue Dec 31 19:58:52 UTC 2019

On Tue, Dec 31, 2019 at 09:33:14AM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote:
> On 12/30/19 6:31 PM, H. S. Teoh wrote:
> > On Mon, Dec 30, 2019 at 03:09:58PM -0800, H. S. Teoh via Digitalmars-d-learn wrote:
> > Haha, it's actually right there in the Grapheme docs for the opSlice
> > overloads:
> > 
> >          Random-access range over Grapheme's $(CHARACTERS).
> > 
> >          Warning: Invalidates when this Grapheme leaves the scope,
> >          attempts to use it then would lead to memory corruption.
> > 
> > Looks like when you use .map over the Grapheme, it gets copied into
> > a temporary, which gets invalidated when map.front returns.
> > Somewhere we're missing a 'scope' qualifier...
> Then the original example should be fixable by putting "ref" in for
> all the lambdas.
> But this is kind of disturbing. Why does the grapheme do this? The
> original data is not scoped.

Honestly I have no idea, but glancing at the code in std.uni reveals
that the returned slice is actually a wrapper object that contains a
pointer to the parent Grapheme object.  So if the parent was a
temporary and goes out of scope before the wrapper does, we're left with
a dangling pointer.

> e.g.:
> writeln(" Text = ", gr1.map!((ref g) => g[]).joiner.to!string);

Unfortunately this doesn't work. Somehow the ref parameter doesn't match
whatever it is std.algorithm.map is trying to pass to it.


They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill

More information about the Digitalmars-d-learn mailing list